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

51–60 of 143 posts

Re: Microfrontends should be a last resort

#51

Post by btilly »

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…

I would argue that you should do the opposite.

Ask, "Pick a popular buzzword that you think is often a bad idea. Name it, explain what it was, explain why people like it, then explain why it is often a bad idea."

If they hesitate, reassure them, "It will be fine even if I disagree with you. I just want to see that you can think for yourself."

Re: Microfrontends should be a last resort

#52

Post by wiremine »

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…

> 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

I've been going to tech conferences for 25 years. This isn't a new new trend. :-)

Re: Microfrontends should be a last resort

#54

Post by vilunov »

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.

There are interfaces besides RPCs

Re: Microfrontends should be a last resort

#55

Post by ChicagoDave »

Microfrontends require modularized behaviors with zero cross grained abstractions.

It’s often referred to as Packaged Business Capabilities.

The MFE is an adapter pattern that hosts discrete modules deployed from their own repositories and configuration should be automatically integrated.

But as the OP states, there are many ways to do this badly. A strict non-abstraction discipline is required. No shared utility libraries between modules.

Re: Microfrontends should be a last resort

#56

Post by downWidOutaFite »

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…

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/libraries.

Re: Microfrontends should be a last resort

#57

Post by eezing »

If reusable frontend code for your within a single organization or business unit is important, then having separate repos is crazy.

A monorepo with separate build pipelines is better, but still unnecessarily complex.

A framework like Next.js can do the heavy lifting for you. One build pipeline where components are shareable, and pages/routes ans entry are isolated during development and can be deployed independently if required.

Re: Microfrontends should be a last resort

#58

Post by SkyBelow »

nogridbag wrote: post #35
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…

> knowing about them was his primary signal for someone's overall competence I don't know if it's the primary signal, but I think you need a balanced team. It's a good idea to have at least one person on your team who's staying on top of what's going on in the front-end community. But you have to be careful that person isn't blindly trying to apply every trend in your product, e.g. resume driven development.

This is a double edged sword unless you plan to allow them room to experiment. If all the work is in older technologies with no short term or middle term plan to upgrade, you will be hiring people who aren't going to be satisfied with the day to day duties and looking to change teams to a team who is using new things or leave. I think teams being honest and self critical about what their actual needs and day to day operations include is an important part of figuring out what skill sets should be on the team. Too much optimism leads to constant turn over.

Re: Microfrontends should be a last resort

#59

Post by JCharante »

davepeck wrote: post #34

"Microfrontends" is a new term for me. Are there specific frameworks that embody the concept (and if so, where on GitHub would I look)? Is it more of a broad architectural pattern?

It’s not really a framework. I mean that’s the whole point of not being so tightly knit.

Imagine you have a website with some kind of router for different paths. You might also have a unique domain per market (e.g. amazon.co.uk or amazon.jp)

/ -> home page repo

/search -> search repo

/products/xyz -> products repo

/products/xyz/review -> product review repo

It might seem crazy to have so many repos, but each of these pages already imports so many different components from different teams, and separating them is an easy way to make sure you don’t accidentally separate something else.

You could use Gatsby to prebuild all the products pages when there’s a change in the CMS and serve them on S3, and you could use a Next.js project to handle the /search page. You could use Vue to do the reviews page, or just have a normal create react app SPA. It gives you flexibility to experiment and lets teams not stop all over each ofher.

If your build step results in 20 * 300 product pages, then you’ll be glad to not have other stuff in that repo.

Of course you could accomplish this in a monorepo, but I’m just using project & repo to mean the same thing (a micro frontend)

It gets easier to A/B test and you could deploy a different site version for different markets (e.g rollout a new search result layout in Ireland and see if there’s a difference in click through rates). It’s just easier to deploy a MFE to serve that route in that market and have the old MFE still deploy to other markets.

Re: Microfrontends should be a last resort

#60

Post by marcosdumay »

jameshart wrote: post #22
marcosdumay wrote: post #13

Earlier quoted context omitted.

> but now you call it a service What is a problem in itself. On every sane place, most of the "services" aren't providing any on-demand service, instead they are just thematic monoliths doing all of a part of a task. I'm settling on the opinion that a service-based architecture is always wrong. But people keep calling the good architectures by that name.

Well, you’re almost at the moment of enlightenment. Yes, all the good architectures are service based. And all service based architectures are wrong. Because all architectures are wrong . In the sense that there’s always another way you could have architected it that would be better for where you think you want to go next, than the way it is architected. Learn to accept that an evolving software system is always goin…

Hum... No.

You are misinterpreting my words here. I'm saying that I now strongly suspect that biasing the way you divide your software on a direction that gives you services will always make your life worse (probably by a lot). There's no philosophical allegory about perfect things not existing.

There are a few things that really want to be services. You'll settle those on services whatever way you decide to architecture your software. But those are very few, and any push into doing it for more than the absolute minimum is harmful.

Post reply on HN