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

111–120 of 143 posts

Re: Microfrontends should be a last resort

#111

Post by dasil003 »

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.

Org charts tend to change faster than services can possibly be re-architected in a large scale system that is growing quickly. Honestly you need a critical mass of engineers who can think end-to-end with a product and business-first mentality, they should decide what tradeoffs make the most sense taking into account a broad range of hypothetical future requirements and what makes sense given current domain knowledge. They must do this with real expertise and ownership, not basing it purely on a 3-year roadmap from non-technical PM. Then teams should be organized around the design of these systems (not the other way around). This overall process should be repeated iteratively as the product and business scales.

Re: Microfrontends should be a last resort

#112

Post by danielvaughn »

gaoshan wrote: post #65
Aurornis wrote: post #17

> Microfrontends are very popular on the conference circuit, so I am probably about to make future job interviews awkward by criticisng them. This has been my experience with conferences lately: Way too much emphasis on the next big trend, to the point of being counterproductive for actually getting work done Certain teams and companies live and die by conference trends. If you can't also show interest in those trend…

>They hired a lot of "smart" developers, but they also took forever to ship anything. Oh man does this resonate with me. Some of the "smartest" people we've hired have also been the slowest to deliver as they waffle and perfect and theorize and play with the tasks they have.

My go-to line is "I don't like working with geniuses, they're idiots."

Of course I don't actually think that, but there does seem to be a kind of parochial navel-gazing that comes with the high intellect territory, and in tech that manifests itself in absurdly over-engineered solutions.

Re: Microfrontends should be a last resort

#113

Post by mrinterweb »

klysm wrote: post #104
mrinterweb wrote: post #96

I think people forget that code in monoliths can be written in a way to set boundaries with namespaces and thinking through class-level API design. Most of the time you can accomplish the same outcome of what a microfrontend might provide inside a monolith. Same is often the case for the backend.

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.

Re: Microfrontends should be a last resort

#114

Post by shadowgovt »

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.

In that sense, when the UI is a browser client UI, I'm immediately suspicious of such isolation plans.

When you're building server architectures, it's fine... You have more storage than every book ever published in the 1800s on each machine you're deploying to, you can afford to have microservice A depend on library set Q and microservice B depend on library set R and as long as the public-facing contract doesn't change, nobody cares. Your deployment infrastructure does something to get all those dependencies in place (possibly even something hugely inefficient) and you're happy.

Efficiency of deployment still matters for the client. It is not okay to be shipping four different date libraries because your client is an MFE and the different departments in your company can't agree on what core library to use. That scales in the reverse direction: you're paying for bandwidth (and your users for time waiting for your site to load) per user. It's waste you can feel.

Re: Microfrontends should be a last resort

#115

Post by downWidOutaFite »

mjr00 wrote: post #63
downWidOutaFite wrote: post #56

Earlier quoted context omitted.

I'm a fan of libraries, not modules, for hard API boundaries. A library, developed and compiled separately and published with versioning, gives you a lot of the clean separation of services without the networking and system overhead. Dependencies should always point from the app to the library as much as possible, so the library should bring it's own dependencies instead of trying to reuse the app's framework/librari…

Libraries sort of help but not really. In the end, if the main app is on Python 3.10, all libraries it uses must be capable of running on Python 3.10. And if you want to upgrade the app to 3.11, first you have to upgrade all libraries to support 3.11 (in addition to 3.10, since you'll likely have to do it piecemeal and not a single big-bang). This is to say nothing of the classic dependency hell[0] where the main app…

Python and any other popular language will try hard to stay backward compatible, so that shouldn't be a problem. I have encountered in the other direction where a library wants to use new language features but the app's runtime doesn't support it yet. That can be considered a downside.

Re: Microfrontends should be a last resort

#116

Post by 10000truths »

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.

Why does a monolith imply one massive build? Pretty much every compiled language has some concept of pre-compiled modules. Java has class files, C/C++ has shared/static object files, Rust has rlibs, Golang has internal object files, and so on. Caching them in a CI/CD pipeline is one of the first steps in the DevOps checklist for reducing build times.

Re: Microfrontends should be a last resort

#117

Post by gratitoad »

FlorianRappl wrote: post #38

Personally, I wouldn't call it a "last resort", but I definitely agree that keeping a functioning monolith is preferred. Nevertheless, one thing to keep in mind (and I do consulting on MF for the last 5 years) is that most projects / teams are not well prepared and actually not at all suited for MF. MF solutions are usually just done from a technology POV, which is already a problem. Next thing is that the used techn…

We’re about to embark on the MFE journey and I’m concerned about pulling it off in a way that will have justified the effort. Our motivations are pure, we have many feature teams, we’re driving toward team independence, already breaking up the monolith into Microservices, etc. But on the FE we have the standard requirement to maintain eventual (definition tbd) UI consistency and so intend to continue to maintain a large number of build-time dependencies between MFEs and shared libraries. So I’m not sure exactly how to pull this off.

Are any of these “many success stories” talked about online? Case studies we can get pumped on?

Re: Microfrontends should be a last resort

#118

Post by phyrex »

mjr00 wrote: post #6
anotherhue wrote: post #2

Micro-anything tends to cause engineering orgs to spend more time drawing boxes and fantasising about what tech would be 'just-perfect' for that particular box than actually considering their users needs. The killer truth is, the connections between your components start to become more important than the components, and the work to maintain this system is only really justifiable if the components can be worked on in…

Separate services helps a lot with bigger teams. No matter how much you modularize code -- which will gradually fall apart anyway unless you have custom tooling that enforces API boundaries programmatically -- you're still tying people to the same runtime environment, which means you're tying people to the same libraries and underlying framework/operating system. Which means major library upgrades become nonstarters…

You say that like it’s a fact but Facebook has a humongous monolith and it works fine with tens of thousands of engineers working on it at the same time

Re: Microfrontends should be a last resort

#119

Post by phyrex »

downWidOutaFite wrote: post #56
mjr00 wrote: post #6

Earlier quoted context omitted.

Separate services helps a lot with bigger teams. No matter how much you modularize code -- which will gradually fall apart anyway unless you have custom tooling that enforces API boundaries programmatically -- you're still tying people to the same runtime environment, which means you're tying people to the same libraries and underlying framework/operating system. Which means major library upgrades become nonstarters…

I'm a fan of libraries, not modules, for hard API boundaries. A library, developed and compiled separately and published with versioning, gives you a lot of the clean separation of services without the networking and system overhead. Dependencies should always point from the app to the library as much as possible, so the library should bring it's own dependencies instead of trying to reuse the app's framework/librari…

I’ve tried this but did not find it worthwhile in practice. Either you end up running multiple versions of the same library, which sucks terribly unless your library doesn’t have side effects, or you end up doing a huge versioning dance at every change for no benefit

Re: Microfrontends should be a last resort

#120

Post by strken »

10000truths wrote: post #116
strken wrote: post #107

Earlier quoted context omitted.

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.

Why does a monolith imply one massive build? Pretty much every compiled language has some concept of pre-compiled modules. Java has class files, C/C++ has shared/static object files, Rust has rlibs, Golang has internal object files, and so on. Caching them in a CI/CD pipeline is one of the first steps in the DevOps checklist for reducing build times.

Massive in terms of the changes going into it rather than the time required. Commits will be batched together while the previous CI/CD job runs, then each deploy will have a bunch of stuff on it. A single failure will halt the deploy for every change, and someone will need to go find and revert whatever caused it. Microservices split up the management across services, which ideally means each team only has to fix its own broken builds.

I want to be clear that I don't think microservices are a good idea for most companies. I just disagree with "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 not about the walls, it's about the independence of development and deployment. There are easier ways to enforce walls without such ridiculous operational and technological overhead.

Post reply on HN