Micro-frontends with SSI/ESI/Ajax: multiple Astro fragments from multiple Astro servers on one page #713
Replies: 8 comments 22 replies
-
|
For some people, astro has already been the solution to what they call micro frontends. https://github.com/sasoria/astro-microfrontends-ssr It would help if you could share the specifics of your use case because it's a fairly new term and definitions vary. |
Beta Was this translation helpful? Give feedback.
-
If I'm understanding correctly (see example below), this is well-supported Right. I mentioned that above: "A number of techniques can be easily combined with Astro. For example:"
You can create a page that you only intend to access via fetch calls instead of direct browser navigation. It's possible already, and better ergonomics are being considered in #697. With Ajax, I already have some doubts. I know the goal to better support partials.
Not sure I understand this one. If you can compose markdown, MDX, SVG, plain HTML, framework, and web components into a single page, maybe you wouldn't need SSI in the first place. And this composability is the foundation of Astro. Yes, you can compose a page using multiple technologies and when that is sufficient, you can save yourself the trouble of using micro-frontends. But at what point do you have two many teams working on the same application and how do you deal with it? My goal is not to throw as many technologies as possible on one page. My current goal: I want to divide an ecommerce site into a few frontend applications: one for the checkout, one for searching and browsing the product catalog, and one for your account. In each of these applications, you might have a handful of teams working on them. But you would also need to use the same header and footer across these few applications. So may the header and footer could be separate micro-frontends. That means that on any given page, I would have the main content of the page from only one frontend but then also use the common header and footer from separate micro-frontends. And SSI could include header/footer on the page. My ideal goal: ideally, I would use a bit more composition. In addition to header and footer, there may be some fragments in the content of the page that belong to a different domain/team. That domain/team could have their own frontend. Maybe using Astro, maybe using some Java templating.
I think this could be reiterated. I don't see it as a problem, but a preconceived solution. I would like to have 20+ teams working on a website pursuits Astro's goals: 1) modern DevEx without building separate server and JavaScript bundle, 2) server-rendered pages 3) little JavaScript and mainly for the "islands of interactivity". |
Beta Was this translation helpful? Give feedback.
-
Yes, thanks, these are exactly the things I'm interested in. The approach with the subpaths is pretty much my current goal. I would split the application into like three pieces with a handful of teams working on each piece. But what about the header and footer? How do I share those across the three pieces? In a way that does not cause JavaScript clashes when the pieces don't upgrade their Astro version at exactly the same time. And in a way that does not impact the loading behavior (layout should not jump) and performance should stay high. About the fragment servers: that would be great: I would love to load header/footer from a fragment server into an Astro application. But that brings me to my Ajax doubts from above: if I load a fragment from a different Astro instance, I could run into clashes between the two Astros. |
Beta Was this translation helpful? Give feedback.
-
Using a module federation approach like in https://github.com/sasoria/astro-microfrontends-ssr would technically allow us to compose a page from multiple frontends, but my impression of this approach is that it does not quite match the Astro way. Wouldn't you forego the idea of islands and minimal JavaScript and get larger amounts of client-side JavaScript and hydration?
It very much does ;) I'm not fully opposed to the approach. I think it could be interesting to get my header and footer onto the page (if the SSR works). But generally: I believe that goes into the client-side direction where some (potentially large and complex) fragments on a page are are pure React/Angular/Vue (in my case Vue) applications even when only small parts of the fragment are interactive. You can probably still treat the whole fragment as an island and decide whether to hydrate it, but the code and hydration will cover the whole fragment and not just the interactive islands within the fragment. For our micro-frontend journey I read some books on the topic: Micro-Frontends in Action by Michael Geers and Building Micro Frontends by Luca Mezzalira. Both feature a chapter to help you decide on the architecture / technical approach for micro-frontends. In short: approaches with SSI and/or Ajax are a good, recommended approach for the composition on "MPA" style pages. In less short: For linked pages (one or multiple "MPAs"), Michael Geers decision tree shows "Server-side integration and/or Ajax" as the recommended approach for composition (one one page). For websites that use composition of micro-frontends on one page, Luca Mezzalira shows a path from server-side composition to server-side routing, to server-side includes (SSI) and server-side rendering. |
Beta Was this translation helpful? Give feedback.
-
|
To clarify further, the ES-Module approach that's mentioned here would be completely SSR-ed with the possibility to opt-in to client side hydration on a per-component basis with something like SolidJS or Preact's hydrate() function. It is however true that an Astro-in-Astro solution would make this easier for other frameworks. |
Beta Was this translation helpful? Give feedback.
-
Shared components can go in an npm package imported by each subpath-project. |
Beta Was this translation helpful? Give feedback.
-
|
For reference, here's an example with client-side composition. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks – I had already seen your prototype as well as the two that @lilnasy linked (https://github.com/sasoria/astro-microfrontends-ssr and https://github.com/ec965/micro-frontends-astro) in the Discord. It's good to have them here, too, so that people looking for micro-frontend options get a good overview. The thing is that the micro-frontend approaches that I associate the most with Astro's goals and concepts – server-side integration and Ajax – don't appear to allow multiple Astro applications. That would be valuable in my context. |
Beta Was this translation helpful? Give feedback.
-
|
@ematipico, I take it (based on the thumbs-down emoji) you don't like the idea of supporting server-side integration or Ajax integration of multiple Astro frontends? Why is that? |
Beta Was this translation helpful? Give feedback.
-
|
It's not that I don't like it. As @lukastaegert mentioned, the micro-frontend architecture is the byproduct of teams and organisations, and that's a fact. The micro-frontend is essentially a way to have multiple frontend libraries in the same application/website. We can go into specifics in a separate thread, but I believe we agree that everything boils down to that. I put the thumb-down emoji mainly because the proposal needs to change to fit the Astro framework, and Astro is not a frontend framework, Astro is a backend framework first and foremost. While it's true that we have a runtime and it's possible to ship JS code to the client, we only provide a few features that frontend libraries/frameworks do, and if we do, our approach uses the backend. For example, nowadays, Astro doesn't provide a way to share state clientside, because Astro let you choose what client-side library you want. So I believe we should make a proposal tailored to Astro.
I believe it's possible: https://docs.astro.build/en/reference/configuration-reference/#srcdir |
Beta Was this translation helpful? Give feedback.
-
essentially a way to have multiple frontend libraries in the same application/website. Depending on what you mean, we can possibly agree :) If all my teams were using Astro and Vue.js with a small number of Astro instances, I would be happy.
Maybe I can reword some aspects of the post to frame Astro less as a frontend. But I don't understand how you would tailor the solution to the Astro framework. In my case, Astro is not competing frameworks like React, but with frameworks like Spring / Spring MVC. In the ideal world, when a page includes a fragment from another server via SSI or Ajax, the team should not have to know what technology the server is using to deliver HTML, CSS, and JS. The fragment that is being included should avoid using global state/elements/events so it does not clash with other fragments. |
Beta Was this translation helpful? Give feedback.
-
|
I reworded parts of the proposal including the title and summary. |
Beta Was this translation helpful? Give feedback.
-
|
Genuinely I don't get these modern trends. First we create serverless and micro services, then, a few years later, we complain about the complexity of our systems and the skyrocketing costs of running it on scale. Now the same thing is happening to the frontend. |
Beta Was this translation helpful? Give feedback.
-
|
The "micro" can be misleading in both frontend and backend. You are right that the industry has learned that splitting any system into many tiny services/functions is not a great idea. In my context, we are aiming for roughly one-service-per-team or small-ish modular services that a few teams work on. My goal for the frontend is the same. Just like you can go too small, you can also go to big. |
Beta Was this translation helpful? Give feedback.
-
|
You see, that one of the problems with buzzwords. Like, is having subdomains with different apps deployed on them counts as a micro frontend? Or if redirects are set up in such a way that some sections of a website are in fact loaded from different domains and are powered by different builds/apps? |
Beta Was this translation helpful? Give feedback.
-
|
To be completely honest, from the messages I've read and the examples of these micro frontends, to me it all boils down to code organization. |
Beta Was this translation helpful? Give feedback.
-
These areas are where some people see the term "micro-frontend" differently. |
Beta Was this translation helpful? Give feedback.
-
|
For me, the main reason to have micro-frontends despite the obvious additional overhead with regard to deployed JavaScript size and the additional infrastructure cost is team autonomy.
can be a huge time-saver. The teams can make their own technology decisions, code style and organization decisions, maintain their own pipelines and processes and perform independent releases. It allows teams to make important decisions independently, greatly improving time-to-market. I do not think we need a discussion whether this is a good idea. For some projects it is the right approach while for most projects it certainly isn't. It is a question of measuring how much the inter-team friction costs you. The obvious downside of such an approach is that frameworks and dependencies are duplicated, and while there are ways of resolving that duplication e.g. via module federation techniques, this again creates additional overhead and threatens to eat up the independence advantage we already gained. This is where Astro comes in as it has many features that both reduce deployed JavaScript as well as it allows features to be easily lazy-loaded on demand. So I would see it as a match made in heaven if this was possible, and I am quite sure that it would drive adoption for large business websites. However, there were some issues we identified, which is why this issue was brought forward to create some interest on your side. Maybe solving them is as simple as allowing some names to be configured so that astro applications do not clash? |
Beta Was this translation helpful? Give feedback.
-
|
I think this is an interesting proposal, but it might be useful to break it down to two pieces.
Maybe this would make it easier for the Astro maintainers to decide how to evaluate this proposal. This also brings up other questions: if (1) is possible, then why would you want to adopt (2)? Is it because ESI supports fallbacks and caching mechanisms are easy to implement? Would (2) require anything from Astro? |
Beta Was this translation helpful? Give feedback.
-
|
There is now some progress on the feature to support partials with this RFC: #721 The proposal does not aim to solve Astro-in-Astro apps. |
Beta Was this translation helpful? Give feedback.
-
|
@ematipico @lilnasy, since you probably have a good overview of Astro: are you aware of more things that happen client-side in a way that two Astro instances could clash? We know of the...
You might also have a better feel for how problematic those things could be. The custom element might not be a big deal (unless a future Astro version changes it). The element would only be registered once and if the Astro fragments on the page would use the same Astro (major?) version, it probably just works. The astro:only event may be more interesting, since you might dispatch it twice (from both Astro pieces). If we had an idea, what things could cause issues, then we could also judge how simple it might be to work around the issues. If in the end it's just a small number of element/event names that could get something like a configurable suffix, this may be some "low-hanging fruit", and require little design effort. An interested party might even be able to contribute to make it happen. |
Beta Was this translation helpful? Give feedback.
-
|
Their existence means you can't call your own custom element I don't see how either of those could interfere in another way. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
You're right, you will have to sync the Astro version bump when prop serialization changes. I don't think there's a way around it. The events only come into the play when you use view transitions. They could be problematic for your use case, but they are not there by default. Edit: ...when you use view transitions in SPA mode. The other events in the codebase are internal. |
Beta Was this translation helpful? Give feedback.
-
|
Could you provide a (mono)repo with 2 or more astro apps and a meta one making SSIs or at least a schematic of it and show/describe the pain points in comments? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, probably (in a week or two). I believe a colleague has a PoC with two Astros that may be suitable. Based on the thread above I don't think there would be any immediate issues but as soon as a new Astro version would change the astro-island custom element and the fragments would upgrade at different times, something would break: one of the fragments would register their astro-island custom element and it would act on the whole page. In a larger micro-frontend context it would be a problem to upgrade all Astros as the same time: multiple teams owning multiple fragments on various pages – you want them to be able to upgrade their dependencies autonomously at their own pace. |
Beta Was this translation helpful? Give feedback.
-
|
Can you also add some react or vue app as the third one? |
Beta Was this translation helpful? Give feedback.
-
Body
Summary
A classic micro-frontend approach for server-rendered pages uses Server-Side Includes (SSI), Edge-Side Includes (ESI), and/or Ajax to compose a page from multiple different servers. Astro does not support this well: multiple instances could clash on the client side because of global state/elements/events. I propose to find a way to avoid these clashes – maybe some configurable names for global things would do the trick.
Background & Motivation
Micro-frontends are gaining traction.
The latest InfoQ trend report shows them in the early adopters column (see https://www.infoq.com/articles/architecture-trends-2023/ ) and there are many well-known large companies that have adopted micro-frontends.
Micro-frontends are a great fit for current architecture trends in general.
When organizing teams "for fast flow" – aligned with value streams (see Team Topologies) and using Domain-Driven Design, the idea is that teams can work autonomously in their domains. Ideally, a team could make changes to the backend and frontend within their domain without hand-offs to other teams.
In the backend, we have long moved towards independent services.
It would be unusual to see 20 teams working on one (backend) monolith.
It would be inconsistent if we stick with monolithic frontends.
Composing multiple fragments from different applications on a single page is relatively simple with MPA-style frontends. Where SPAs require complex solutions with application shells like single-spa or piral, some techniques for the "MPA" world are simple, battle-tested and widely available: classic approaches like Server-Side Includes or Edge-Side Includes.
The problem: Astro is not designed to support two or more Astro fragments on one page. It uses global pieces like the astro-island custom element and global events. The dev and preview modes rely on fix paths like
/srcthat cannot be changed.While Astro is not designed for that use case, there is some interest in it.
Some comments on #266 refer to micro-frontends.
Goals
Note: the dev/preview mode has lower priority; with micro-frontends it is a good pattern to test fragments in isolation.
Questions
Might there be a relatively lightweight way to "retro-fit" Astro with that capability?
What aspects of Astro use global state/elements/events? Might it be possible to introduce hashes in the names of these state/elements/events so they don't interfere with another instance?
Relates to
Beta Was this translation helpful? Give feedback.
All reactions