Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microfrontends should be a last resort

breck-mckye.com

Post reply on HN
Print view View original

121–130 of 143 posts

Re: Microfrontends should be a last resort

#121

Post by williamcotton »

The more state that gets shared, the more dependencies that exist, the further away you are from actual isolation.

It’s not just state. It is the kind of state. Think about the difference between aggregate and combined software systems, and I’m using the GNU and FSF definitions here. Loosely coupled systems with pipes? Aggregate. API interface? Combined.

Every step away from something as generic as a stdin/stdout pipeline brings you more and more coupling.

You want to know the real problem with contemporary software development? We don’t actually compose our tools together beyond some meatheaded level of “specialized database”, “specialized frontend”, “specialized backend”.

Cat, awk, grep, sed, and most importantly | and and you can compose any number of specialized tools.

The inclusions of libraries of code into a single executable environment that exposes an HTTP API is a non-generic data interface to another software system. Only generic interfaces are truly composable.

I’m still long on void *…

Re: Microfrontends should be a last resort

#122

Post by klysm »

mrinterweb wrote: post #113
klysm wrote: post #104

Earlier quoted context omitted.

They can, but the walls are not strong enough to perturb those programmers who do not know any better, don’t care, or are under sufficient pressure to sweep aside good practice. Micro-anything is the philosophy based in the presumption that your engineers will not respect softer walls and modules and therefore strong ones must be constructed. It’s obvious that strong walls have immense cost, but perhaps for a large e…

I agree that the boundaries are not naturally enforced and need to be put in place by the developers. It is a team culture thing to enforce these types of boundaries in code review.

Agreed. Doing micro-anything is accepting that your team can’t keep good walls

Re: Microfrontends should be a last resort

#123

Post by zubairq »

tsss wrote: post #79
andy_ppp wrote: post #33

I think microfrontends are the ultimate extension of what I call "the myth of code reuse". Everyone thinks because they can create "small reusable slices" of full frontend code that this comes for free without a load of problems that get in the way of the mythical land. The only issue is everyone who has tried microfrontends is universally full of regret. Other attempts at this are: 1) having an enforced centralised…

Microfrontends are about independent development, not code reuse. They work fine if you understand their purpose.

Yes, I agree. Microfrontends can be very useful if a small team needs an app quickly the same day, but can't wait for 2 years for the central IT department to deliver the tool.

Re: Microfrontends should be a last resort

#124

Post by morbicer »

no_wizard wrote: post #39

Most of the implementations of MFEs I've seen are reliant on webpack or Single-SPA (which by default uses webpack under the hood). vite, esbuild, parcel etc. have not adopted anything around this. To me, that says that those putting out the nuts and bolts work that having been leading this space for several years either haven't spent alot of time evaluating them, or have found them overly complex for what they are, o…

Víte has a Module Federation plugin that's interoperable with webpack with some effort

And according to some folks on Vite conf it will be soon supported natively

Re: Microfrontends should be a last resort

#125

Post by lelanthran »

bluGill wrote: post #44
vilunov wrote: post #14

Earlier quoted context omitted.

After years of working with various microservice-based systems, I got the impression that the whole idea of "microservices" means ignoring various nuances of particular products and organizations and just splitting your system in a pinky-sized codebases and services. You are completely right, every project is different, and that's why the general idea of microservices is bad. Split your services where there are techn…

Your code structure should match your org chart is the best advice I've seen for splitting code. Each team in the org maintains their own micro service. They do whatever they want within it, but when going to a different one they go to an interface. It isn't perfect, but it seems to work the best.

> Your code structure should match your org chart is the best advice I've seen for splitting code.

I've seen that so often it now feels like a sarcastic meme to me.

The org structure changes much faster than your code structure does. Good luck getting those two to stay in sync longer than the CTO stays in their role.

Re: Microfrontends should be a last resort

#126

Post by ktsangop »

I am currently investigating the use of microfrontends in our company.

We have multiple web apps (Angular, but also some legacy JSP ones) that are currently hosted on different domains. Some of them are part of a product suite (see JSP), and some of them are separate products themselves. However all of them target the same users :

1. Our Customers

2. Our employees (dev, service, support teams)

Those products have a complex way of authenticating and storing user data, since we haven't got a centralized auth server. So we keep multiple copies of user data, and authentication mechanisms, which leads to duplication, trouble in syncinc changes etc.

Also, our customers, need to log in to different systems each time they need to work on 2 separate products, let alone that the UI/UX might be quite different. This leads to frustration, confusion and bad UX in general.

At the moment, we are implementing a centralized authentication service, which means that we can finally integrate users across systems. However we are trying to re-architect our frontend applications also, that's why I've been exploring microfrontends.

My first attempt, will be to integrate the Angular apps under a single login page which leads to a host app that will only handle :

1. Users (login/logout/manage)

2. Navigation (Send me to the required web app)

I have already used module federation (webpack) to integrate a new web app (module), into an existing product and it has been working fine for some time. So I am exploring integrating all of the Angular apps under a single host (new webapp), and using module federation (or whatever else works) to fetch and run the other modules, with routing (lazy loaded, remote modules)

It's worth noticing that our 2 main products I am trying to integrate, are Angular SPAs that use the same UI framework, and similar UI/UX. There are 2 (currently) small-sized teams that work in these projects, and they have their own release cycles. Each project has its own backend service.

The issues I have identified so far are :

1. Angular/package upgrades must be done simulatneously (if we care about performance, and don't want multiple copies of the framework downloaded and running in the same page)

2. JWT token sharing/refreshing (Since everyone will live under the same domain, we can share auth tokens in cookies/headers, but we require a mechanism for all apps/modules to request a token refresh, and a way to communicate user status changes : user logs out, permissions have changed etc) (p.s. Backend services - hosted in separate domains - will of course have to integrate the new Auth service, and inspect/validate the shared JWTs)

3. ALthough module federation might work for Angular SPAs, we will have to implement a separate mechanism for importing JSP apps (iframes probably?) and the way we share JWTs with them.

Since I've read a lot of constructive critisism on the issue here, I would love any feedback regarding my approach. Is there anything else I should explore? I've thought about NX monorepos, with separete CI/CD pipelines for each project, but that looks more complicated from where I stand.

Thanks in advance.

Re: Microfrontends should be a last resort

#127

Post by _uhdj »

My friend works at a company on an internal product where they are using MFEs, and it is a sisyphean marathon of pain.

They're only 2.5 developers -- .5 because one of their juniors is practically useless. The reason they went with it is because the "senior" in charge wanted to experiment, which can be all well and good in certain contexts, but they've had nothing but trouble. Instead of doing the reasonable thing and stepping back and thinking "Okay, solving shouldn't be this hard. Maybe we should rethink this MFE approach", the "senior" just keeps piling more turds on top of their already huge, steaming pile of turds.

Examples: The MFEs(which live in iframes) need to be able to tell the umbrella that a certain keyboard shortcut was pressed. Normally this would just be an `addEventListener` call by whatever component is interested.. but with iframes it's not that simple. Solution? Capture every keystroke in the application in all the MFEs and send them, as JSON, over your custom messagebus.

Because they use graphql(with apollo client), every graphql request should be cached and you can set up "rules" to do optimistic mutations and whatnot. You should be able to show a lot of UI instantly to the users because you already have data cached. But the caching obviously doesn't work across iframes.. so they tack on yet another hacky solution to transport the cache across iframes sometimes when it's necessary.

Anyway, the point isn't to rant about this specific scenario forever, but rather explain how fucking awful MFEs can be when you make the wrong decision. They are very obviously building a monolith and MFEs should never have been considered, even if you don't look at the team size of 2(which is enough to make the decision ridiculous on its own). I honestly don't think there are any real use cases for MFEs outside absolutely massive organizations working on very specific kinds of products.. maybe stuff like cloud platform management UIs.

Re: Microfrontends should be a last resort

#128

Post by tusharmath »

_uhdj wrote: post #127

My friend works at a company on an internal product where they are using MFEs, and it is a sisyphean marathon of pain. They're only 2.5 developers -- .5 because one of their juniors is practically useless. The reason they went with it is because the "senior" in charge wanted to experiment, which can be all well and good in certain contexts, but they've had nothing but trouble. Instead of doing the reasonable thing an…

The iframes can share service workers if they are all on the same origin. I would recommend using a service-worker which intercepts every graphQL request and caches on that layer. You can do a lot more on that layer once it's setup. For example — Enable batching, Rate limiting etc.

Re: Microfrontends should be a last resort

#129

Post by Sankozi »

strken wrote: post #107
klysm wrote: post #104

Earlier quoted context omitted.

They can, but the walls are not strong enough to perturb those programmers who do not know any better, don’t care, or are under sufficient pressure to sweep aside good practice. Micro-anything is the philosophy based in the presumption that your engineers will not respect softer walls and modules and therefore strong ones must be constructed. It’s obvious that strong walls have immense cost, but perhaps for a large e…

I thought it was more about independence. Got a bug in your service? Instead of one massive build deployed once an hour/day/week/etc. that gets rolled back if any commit was bad, you deploy your service when it changes and don't worry too much about the unrelated pieces.

Got a feature that touches several modules? Instead of one massive build deployed once, you deploy each service. With dependencies you need to wait after each deployment to check if everything is ok. Instead of one big build and one deployment, you get quick build, deployment, check, quick build deployment, check...

So in case of microservices/microfrontends you gain minutes on build time but lose hours/days on deployment and verification.

Post reply on HN