Today, we are aware that we should normally not have our whole enterprise in one service, and so we split up the enterprise architecture in smaller services, for example, microservices. However, we are also starting to realize that we have the same problems with the frontend monolith as we had with the backend monolith, Gustaf Nilsson Kotte explained in a recent interview hosted by Stefan Tilkov. Using a micro frontend architecture, he breaks the frontend into smaller parts to allow for teams to deploy autonomously, thus enabling continuous delivery for web frontends.
Kotte, IT consultant at Jayway and currently working as a web architect for IKEA, prefers splitting a system vertically to create self-contained systems with both backend and frontend built by the same team. He believes that teams up to around 10 – 12 people works well, above that the team gets less effective. He also thinks that a team can have more than one service if they are small, although this puts a pressure on the architecture since both teams and services should be autonomous.
When asked by Tilkov how he would set up a group of 24 people, Kotte is not in favour of creating one frontend team and two backend teams, arguing that a backend team being able to deliver value to the end user will likely need a change by the frontend team. Two backend teams may also create an increasing queue of frontend stories. Instead he prefers two separate teams of 12 people, each working with their own backend and frontend services and able to deploy in their own pace, although this brings a new set of problems you must deal with, like collaboration and reuse of components.
For Kotte, microservices is about diverse and heterogeneous architectures, allowing for different technologies, and he believes this should also be true for the frontend. The frontend landscape is still changing a lot and he has seen a few large rewrite projects of frontends and notes that we tend to underestimate the cost of these rewrites. A 2-4 years cycle of rewrites is not good for business, instead we should have support for a diverse technology stack in the frontend from the start.
Not being able to rely on one single framework like React or Vue, and not writing your own framework, which he sees as a trap, the only solution Kotte has found that enables the same benefits in the frontend that we expect from backend microservices is to use some form of transclusion mechanism – a way to include one electronic document into another document. On the client side one example of transclusion is the image tag. The tag has a source attribute referring to an URL and the browser will replace the tag with the actual image during rendering – the browser transcludes the HTML document with the image document.
On the server side Edge Side Includes (ESI) corresponds to the image tag but for HTML. It has a source attribute and the URL points to a resource that must be fetched and included in the resulting document. ESI is the fundamental technology at IKEA for the micro frontends concept. They have the notion of pages and fragments, and a team will have responsibility for a set of pages and fragments. Pages can then have ESI references to fragments, and those references can cross team boundaries. One example is a product team which has fragments for product thumbnails. Other teams can then refer to these product thumbnails instead of creating something themselves.
Since pages are assembled by fragments produced by different teams, and possibly using different technologies, all these fragments need to fit together somehow. To solve this, the teams at IKEA are using a technique called self-contained fragments, allowing for everything a fragment needs, like CSS and JavaScript, to be included. You shouldn’t have to think about the dependencies for a fragment, just include one ESI for styles, and one ESI for scripts, and you should be done. Kotte notes that the technique itself is a bit complicated but for the teams using it it’s quite simple.
To get pages and fragments to work together they have only setup a few rules. Instead of trying to deal with everything that can go bad beforehand, they have a general approach of fixing errors fast, favouring mean-time-to-recovery over mean-time-between-failures.
Kotte concludes by emphasizing that the architecture he describes isn’t necessarily the right architecture for everyone. You must look at the trade-offs at an organizational level and from the pros and cons of different designs find the best solution.
To learn more about micro frontends Kotte recommends an article he wrote earlier, and his presentation about Microservice Websites at Øredev 2018. There is also a website dedicated to micro frontends.