Tiers of frontend development

For frontend development, there are 3 tiers of setup that will help you achieve your goals. Higher tiers are not inherently better and what you should aim for right away; it simply depends on your product and organization size as they each come with a different set of trade-offs and investment efforts.

Tier 1: the “traditional” approach

Often referred to as the monolithic approach, it’s the default starting point for most frontend setups, and it will get you much further than you think. In this setup, often supported by a framework, all of your source code is in a shared repository that is bundled and deployed all at once.

As your app starts to grow, you organize your code by feature or domain folders to keep things manageable, and you spend time optimizing your bundler setup to keep build and deployment time from skyrocketing.

This can get you extremely far, but what will likely to slow you down is the lack of alignment between your code and your organizational setup. As you grew, so did your features, capabilities, as well as opportunities, and you now have multiple teams responsible for different parts of the product, or even different products altogether. They all want to be successful and ship fast, but the centralized development setup is now slow and does not give them the autonomy their product leaders crave, so you have to resort to moving to Tier 2.

Tier 2: Frontend Microservices / Micro-Frontends

Teams autonomy as well as independent, easy-to-deploy releases are what you strive for, and you look with envy at your backend teams organized around microservices, so you set out to do the same. There are now a lot of resources on frontend microservices architecture, or micro-frontends. The basic idea is to break your frontend into smaller pieces that now have their own repositories and are managed by individual teams.

An early downside is that you now have to maintain a layer to compose your frontend microservices together at runtime, but this can be very lightweight in the beginning. You also quickly realize that patterns repeat themselves across these different micro-frontends, so you flesh out best practices and top-notch documentation to handle cross-cutting concerns in your frontend applications such as authorization, localization, A/B testing, and so on.

It works extremely well for a while, and your business is still successful after multiple years (congrats!) but now you start to see ugly cracks in your frontend setup. In fact, about 40% of your frontend teams’s capacity is spent on infrastructure, either maintenance (updating dependencies, fixing vulnerabilities) or writing code that is duplicated in most micro-frontends to handle those cross-cutting capabilities. You are now ready to move to Tier 3.

Tier 3: Frontend platform

What if all your frontend product teams didn’t have to worry about upgrading their version of Node.JS, implementing internationalization, or integrating with your latest observability vendor? Enter frontend platform as a runtime. Remember all those guidelines developers had to read and keep in mind? Now you can codify them and automate them right into your platform.

This does not come for free and requires an investment in platform infrastructure and a team to maintain and evolve it, but if you had dozens or more frontend microservices, it will quickly pay for itself. The Wix.com team has reported development velocity improvements in the 50% to 80% range with their platform runtime initiative (which was not limited to the frontend), and I have to link Aviran Mordo’s insightful article Platform as a Runtime - the Next Step in Platform Engineering.

When I was at Zalando, we saw similar productivity gains with our micro-frontend approach, Interface Framework, by giving developers a golden path with an in-house, highly opinionated framework. It takes time to get there, but the reward is well worth it.