Why full-stack developers should become lesser-stack developers
With Full Stack Europe, Antwerp has a new diamond in its midst. I had the pleasure of attending the conference, in the exquisite setting of the Hilton hotel in Antwerp.
The talks were diverse, ranging from hard technical stuff to more philosophical reflections on software development (thank you Indu Alagarsamy for pointing out the parallels between rock climbing and software design).
In this blog post, I will shed some light on the main architectural trends at Full Stack Europe.
First of all, there is a clear push towards serverless architectures. It entails the absence of permanent servers. Instances are created whenever they are needed and destroyed after use. So, you pay for what you use and nothing more.
Serverless architectures hold many benefits. Besides allowing you to scale to 0, it takes away time spent on infrastructure. This is very interesting for startups who look to release as quickly as possible.
Gabi D’Ávila Ferrara gave us an overview of the different solutions Google provides in this realm (Cloud Functions, App Engine, Cloud Run) but the message was universal: keep your setup simple and quick.
This point was also driven home by Konstantin Kudryashov. Since he urged businesses, developers, and startups to never reinvent things that already exist. If what you require a webshop, use something like Shopify. If you need a website, use something like Squarespace. You get the point: use the services that are provided already. Only write your implementation if you can’t already find it.
As a developer, you should use strictly what you need. It’s every full-stack developer’s responsibility to reduce the stack. For this, he coined the phrase ‘lesser stack developer’. I thought this was an interesting view.
Matthias Noback gave an interesting talk about another model for designing software applications: Hexagon Architecture. It had great synergy with the workshop on Domain-Driven Design (DDD) by Mathias Verraes. Both concepts remind me of each other and if they are aren’t brothers they would be best friends.
Hexagonal Architecture proposes projects to be split up into three parts, namely:
- Application: All the possible ways actors interact with the domain.
- Domain: The meat of the program. This part defines the business rules and logic.
- Infrastructure: All the parts where the domain acts as an actor itself.
The interface between these parts are dubbed ‘ports’ and ‘adapters’. Ports are the interfaces that live within the domain and adapters implement them. The name ‘Hexagon’ is derived from this. Like the many sides of a hexagon, the application has many ports and adapters attached to them. The domain resides inside the hexagon.
The big advantage of this system is that it allows the domain to be isolated and reasoned about without having to consider the entire application. This reduces the cognitive load required to modify or test it. Again, they are trying to allow developers to have a complete understanding of the different parts of an application.
Together with the workshop on Domain-Driven Design (DDD), these were some of the key points to take away.
About the author
Ruven Salamon (27) is a Full Stack Developer with a passion for electronic music, hi-bit games, and software architecture and design.
Right now Rombit is looking for Full Stack Developers! Check out the vacancy.