Ruben Casas once said “something that is really hard with micro-frontends is server-side rendering” and Luca Mezzalira recently stated that “server-side rendering is the real challenge”. I tend to agree, but luckily there are always ways to mitigate complexity. In order to server-side render micro-frontends I’ve used server-side composition, that is, composing micro-frontends in the server. Meaning that “the page is already fully assembled when it reaches the customers browsers”. This allows us to achieve “incredibly good first page load speeds that are hard to match using pure client-side integration techniques”. Astro, EcmaScript Modules and React provides a straightforward interface to set it up. Deno is a simple, modern runtime for JavaScript and TypeScript, “a runtime that resembles the web, using browser APIs that work on the server”. One benefit of using Deno in this solution is that remote modules are cacheable. By default, “a module in the cache will be reused without fetching or re-compiling it”. Contracts are hosted by each micro-frontend to tell the Shell application where to locate assets. Unique names to asset files are going to bust Deno’s cache, maintaining independent deployment of micro-frontends. Service discovery is usually implemented with a Load Balancer for backend applications, but a micro-frontend Composer (i.e Shell app) needs a unified manifest with entry points for assets. Frontend service discovery is not needed to SSR micro-frontends with Astro (a manifest generated by Vite might be adequate), but for large organisations it can simplify the architecture, improve performance and reduce design time coupling between teams.
