Close this search box.

Personal takeaways from the WeAreDevelopers Conference June 2022

Entrance to the conference venue

Entrance to the conference venue

In the world of software development, it is always good - or recommended - that we remain up-to-date with tech trends and pick up something we don\’t know; read, learn and experiment, then connect with the community to share our newfound knowledge, and what better place than a global tech conference to do just that!

Outside the venue, you could spot this soon after exiting the train station

Outside the venue, you could spot this soon after exiting the train station

The opening ceremony

Mainstage during the opening ceremony (apologies for the poor quality photo. I'm not the best photographer!)

Mainstage during the opening ceremony (apologies for the poor quality photo. I’m not the best photographer!)

Upon entering the Mainstage which seated thousands of attendees, it was really exciting to see people from different nationalities, backgrounds, and gender all participating in this global conference. We were accompanied by some music as we all shuffled and settled down into our seats. Ready, set, go!

The MC (who is also a developer) welcomed everyone and introduced some people from the leadership team of WeAreDevelopers - who also gave their own introductions, one also offered a Pikachu Tamagotchi as a prize to whoever can guess the closest number of steps he’ll make during the 2-day conference (quite random but funny in a way). We were then informed about where to find food, drinks, and the restrooms - all the important stuff - and now the conference begins!

Build. Deploy. Emerge. Connect. - WeAreDevelopers

Build. Deploy. Emerge. Connect. - WeAreDevelopers

Just a side note, it will be near impossible (well, in the sense that this will become too long) to write about all the talks that I managed to attend, therefore I will just briefly mention 2 of the talks I found informative and interesting which are also applicable to my current projects: Micro-Frontend Anti-Patterns and 101 Typical Security Pitfalls

Micro-Frontend Anti-Patterns (By Luca Mezzalira, Principal Solutions Architect AWS):

I found this talk enlightening. Most of us have heard of the Micro-Frontend Architecture (MFA) approach and the benefits thereof such as scalability, stack-agnostic implementation, maintainability, among other benefits, etc but we may not be aware of the other side of the coin where if MFA is implemented incorrectly, could void all the benefits this architecture would have otherwise provided.

This talk by Luca, addresses the Micro-Frontend Architecture and the observed Anti-Patterns that are associated with them, the potential solutions, and how we can adopt this type of architecture in a way that is correct and maintainable. Here are some of the anti-patterns categorized by Luca that stood out to me and my understanding of them.

  • Yin & Yang:
    "Are you designing a micro-frontend or a component" - Luca. How do we differentiate the two?

    • Component – Exposes a large API for its containers but does not own the subdomain itself, only the container knows how the component should behave. Eg. A button that defines its behaviour based on parameter API passed in by its container
    • Micro-Frontend – It should be a "technical representation of a business subdomain". It should be domain aware, independently implementable regardless of the tech stack, and should promote minimal code share between the subdomains. Eg. The same button but its behaviour is defined by which subdomain it is being used.

  • Hydra of Lerna:
    Although using multiple frameworks is possible in MFA, it doesn’t always mean that we should. The best practice is to stick to a single UI framework/library for your application. Only in specific use-cases would using multiple frameworks in MFA make sense. Such as:

    • Having a Micro-Frontend system running parallel with a legacy system with the goal to eventually replace the legacy system
    • Iterative migration of the UI library/framework of an application

  • Swiss Army Knife:
    When you have a legacy system and you want to use that system within an MFA, the best approach to do so is by utilizing the anti-corruption layer pattern between the legacy system and the MFA system in order to sanitize the communication between the systems. Using this approach, we can avoid messy/hacky non-reusable code that would otherwise be created, especially if there are multiple legacy systems you need to interact with.

  • Dependencies Hell:
    Dependency management in an application could be a real pain at times. This is especially true with extended libraries when there are breaking changes to the core library, even more so if you have many of these. The recommended approach is to use as little inheritance as possible and more composition. More in-depth comparison of these patterns here.

101 Typical Security Pitfalls (By Alex Pirker, Senior Security Consultant RootSys):

This talk brings up a topic that we as developers could easily overlook when developing an application: Security. He describes what security means from the perspective of an application and why it is so important to make sure your application is as secure as possible and points out common security issues and relatively simple ways that we could address them.

There are 4 common security issues that make an application insecure. Let us have a look:

  • Cross-site scripting from the frontend:
    Having only frontend sanitization of data may not be enough as malicious could be injected using a cURL command into the application without going via the frontend, which stores the code as is in the database. When the frontend is loaded, the script also gets loaded with the application and the malicious script can now access all the user’s sensitive data.
    A simple solution to this problem is to sanitize the data on the backend service to ensure that if it detects tags in the payload, it would simply remove them before storing them.

  • RCE due to insufficient input validation:
    You have a system that takes in a payload, uses the value of the payload as a bash command, and executes. An attacker could attach a malicious bash script within the payload as part of the value to open up a certain port and then send another payload to redirect all traffic to that port to a new shell. Now they have access to the data on the host.
    The solution is to sanitize your input data. If you know the type of data you expect, you could validate it against a set of enums or prevent the opening of a shell.

  • DoS by crashing the application:
    There could be a situation where errors are not being handled gracefully within your application causing it to crash when certain validations do not pass. Eg when you store data without validating it against certain criteria such as byte size for a public key.
    The solution would be to validate the data before having it stored in the database ensuring that it meets the criteria and also make sure to handle your validations in a way that won’t crash the application if an error occurs using some form of a global recovery handler

  • Information leak due to out-of-bound reads:
    There could be much information stored in the memory stack that a malicious attacker can use by forcing the system to read something in the memory stack that is out of bounds. One solution around this would be to check what the max bound is and if any access to a bound greater than the max bound, simply return an error and handle it gracefully.

All in all, the main takeaway from this talk is to always sanitize your data before you store or execute it, pay close attention to what is stored in memory, and always try to handle the unexpected. Most of the time, the solution is a simple one once you figure out the problem. “It’s better to recover from unknown errors somehow than risking outages” - Alex

And of course, the food, drinks, SWAG, and other goodies for developers

Some of the swag and goodies

Some of the swag and goodies

Gotta have those! There were many stalls set up by sponsors and companies outside Stages 1–5 where you can meet with the representatives to find out more about what they do. Some were recruiting, doing product demos, interacting with developers, hosting interactive competitions and raffle draws, serving free ice cream and coffee, and a myriad of other activities, most of which also had swag such as stickers, apparel, tech gadgets, hoverboards & electric scooters (competition prize), etc that they were handing out.

The food and drinks courts were always packed and lively and some of the talks were done there too. On the evening of the first day of the conference, there was also an after-party featuring some popular DJs such as Tiësto, which was apparently a blast too!

People gathering in the hopes of winning the Nintendo OLED Switch raffle (I didn't win…)

People gathering in the hopes of winning the Nintendo OLED Switch raffle (I didn’t win…)

Would I go again? Should you go?

Definitely! This was my first time attending an international tech conference and it was awesome. From the journey to the venue (we’d often come across many fellow attendees - identified by the entry wristbands we all had - on public transport and in restaurants. You could get a feel of how large the community is), the informative talks, the friendly people, the whole event was just very well organized.

Of course, that’s not to say there weren’t some hiccups here and there; rooms being filled to the brim preventing the attendance of a talk, and of course, technical difficulties (because what is a tech conference without technical difficulties!), however, I’d say even that is part of the experience which was well worth it. Luckily there were recordings of all the talks.

Technical difficulties (Technician to the rescue!)

Technical difficulties (Technician to the rescue!)

You also get to meet some really interesting people, we actually met with one of the speakers whilst queuing for a competition - cool guy - and discussed different views and approaches to tech/work/life which were fascinating and insightful. I’d highly recommend going with your team or a bunch of friends, it will make the experience even better!

Oh, and who is this guy?

I’m Chieh Ger, a full-stack developer at Techspire Netherlands with just over 7 years of developer experience. I consider myself leaning more towards the frontend side of things and specializing in React with proficient knowledge of backend technologies. Outside of my professional life, I am a gamer at heart, enjoy board games, manga, and anime, having a braai with friends, and the great outdoors…when it’s not raining!