Microfrontend

[brillout]

Description

There is interest in using vps for a microfrontend archtiecture.

CC @wheerd @j0weiss

[lampewebdev]

I'm also looking into vite/vue/ssr/microfrontends

[brillout]

I care about team scalability. But I'm sceptical microfrontends to be the right approach.

I'm happy to be shown wrong. The best would probably be to provide a concrete example (or even better a real life example) where I can see and understand how a microfrontend architecture helps.

[lampewebdev]

I can describe our use case and why we are investigating micro front ends right now.

• We want to have vertical teams or domain specific teams. This means that Team Search has the Domain knowledge about everything related to search. Team Product (e-commerce) know everything about products. These teams are responsible for these domains.
• Also they should not depend on each other and they should not wait. So Feature Team A should not Block Feature Team B.
• This also means that deployment should not depend on each other.

Basically Micro services for the front end with the added problem that in the end its on website or one container were everything needs to come together.

Now Imagine you have an e-commerce shop were you have a header part, a content part and a footer part. These 3 parts are maintained and developed by 3 Teams. Now the header has a search input with a preview while searching. This search component is provided by Team Search. The Team for the Header has no knowledge about the search and should not have it since Team Search is responsible.

So the Search could be a Micro Front end and the header itself too.

Someone could now argue why not have a mono repo or why not use npm packages.
Npm packages have the problem that teams need to inform the other teams that there is a new version and they need to do some work to update.
A mono repo can be limiting if you have a lot of teams and a lot of different tooling which then limits the teams. Also keeping a mono repo clean and deployable can be hard.

With Micro front ends would only need to include a specific comment and thats it. Team Header should not care about what Team Search is doing. Team Search does not need to inform Team Header and so Team Header has no work to do. Also Team Search can have there one small clean repo with the tools they see fit.

This also would ensure that everybody is using the same version of the header. So a new header could be deployed by Team Header and no planing needs to be done to have the same header everywhere.

Sure this also comes with down sides: Complexity, possibly more QA, possibly bigger network load.

I sadly can not share any code because of Legal.

[brillout]

The way I would tackle this is to have the frontend to be continuously CI'd, deployed, and eventually staged. So that all teams can re-deploy it at any time with confidence.

Then it's about properly structuring the frontend repository so that each team owns specific parts of that repository.

Would that work or am I missing something?

[lampewebdev]

The way I would tackle this is to have the frontend to be continuously CI'd, deployed, and eventually staged. So that all teams can re-deploy it at any time with confidence.

This would work but this means that this eventually staged deploy must be somehow orchestrated with all the teams. With Microfrontends this is not really needed since one team can just deploy when its ready so the teams do not need to re-deploy. The biggest win here is 1 team needs to deploy not N teams.

Then it's about properly structuring the frontend repository so that each team owns specific parts of that repository.

Sure you can have both a mono-repo and microfrontends.

Would that work or am I missing something? This in general would work but its hard to A/B test in a quick way without a big investment in all teams.

[brillout]

I'd use a platform like Vercel and Netlify that allow to preview the deploy of each commit.

As for A/B testing I'd then use Git branches for that.

Continous integration, staging, and deploy has the momentum; it seems to be the future.

Whereas microfrontend seems to be a losing proposition.

That's why I'm reluctant to invest in that direction. That said, if there is a microfrontend architecture that would require only little changes on vps's side, I'd be open for it.

Feel free to dig and come back with a concrete proposition of how vps would need to change.

And feel free to object to any of my arguments.

I'm closing this ticket in the meantime. I'll re-open it if someone can convince me.

[leonmondria]

I agree with both :)

So I think it depends on the ambitions of the project: if you expect to grow and split into multiple teams the best approach is to go for microservices.

A lot of problems can be tackled with structuring processes, CI/CD, canary releases and a lot of discipline, but there's a tipping point where that wont be enough anymore.

But I think the question should be: what is the "responsibility" of VPS in this?

If you go for either a horizontal or vertical split in microservices, the way you integrate microservices should be the responsibility of the composer, not the microservice that uses VPS.

If the composer has trouble integrating the microservice because it uses VPS, we should identify the actual problem and try to fix that.

As we speak I'm trying out some proof of concepts on this subject, if I come up with a problem I'll come back here but for now I think it should not be the responsibility of VPS.

Anyways, great discussion and keep up the good work!

[brillout]

That makes sense to me.

Also, just to be clear, if someone comes up with a specific feature request and explains how it helps scaling, then I'll definitely consider it. So feel free to propose feature requests here, regardless of my initial reservations.

A lot of companies use VPS for its flexibility/scalability — I care about this.