I would rather see articles about "How to do Microfrontends right" rather than all these "X sucks" articles.
Microfrontends should be a last resort
41–50 of 143 posts
Re: Microfrontends should be a last resort
#42Earlier quoted context omitted.
> modularise the code You mean… spend more time drawing boxes and fantasising about what tech would be 'just-perfect' for that particular box? Won’t that mean the connections between your modules start to become more important than the modules, and the work to maintain this system would only really be justifiable if the modules can be worked on in parallel?
It means the interfaces become important and you can work on the internals in parallel.
Interfaces are hard. If you can avoid doing them that is a good thing (that is the interface is whatever someone who writes both sides of it wants it to be, and it changes as that person feels free). However on large projects you cannot do that, you can try but eventually some interface is used by so much that changes becomes difficult just because of the other code you need to change. (additions are easy, but if you want to change something like the arguments to an existing function that is hard just because of all the users who need to change)
Re: Microfrontends should be a last resort
#43> 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 think certain companies / people tend to dominate conference topics.
Most developers / teams / companies are just working rather than doing conferences. There's a whole world of development that is sort of opaque / assumed to be backwards.
Re: Microfrontends should be a last resort
#44Earlier quoted context omitted.
These blanket statements on Hackernews are so frustrating to read. Every one of these articles is bait for these type of comments. The comments fill up with people saying microservices suck, then it fills up with comments saying those comments suck. Please understand that every environment, company, and project is different.
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.
Re: Microfrontends should be a last resort
#45This is mostly skill issues.
There's not much magic or difficulty with MFE.
It's the same as when you break your program into multiple libraries, and you just do it all the time.
The moment you do npm install, pip install, cargo install,... you're basically doing the Micro-program already.
Re: Microfrontends should be a last resort
#46Earlier quoted context omitted.
It means the interfaces become important and you can work on the internals in parallel.
Just like in a microfrontend or microservice architecture
A function boundary in a compiler is a lot easier to work with than a network boundary for a service in another repo in another language on another kernel. Those false equivalencies are what drive the cost.
Re: Microfrontends should be a last resort
#47Earlier quoted context omitted.
It means the interfaces become important and you can work on the internals in parallel.
Interfaces are hard. If you can avoid doing them that is a good thing (that is the interface is whatever someone who writes both sides of it wants it to be, and it changes as that person feels free). However on large projects you cannot do that, you can try but eventually some interface is used by so much that changes becomes difficult just because of the other code you need to change. (additions are easy, but if you…
Version your API, and talk to your consumers before building it so you can design an API that meets their needs. Run a pilot with at least two consumers before even announcing it.
Re: Microfrontends should be a last resort
#48Re: Microfrontends should be a last resort
#49Micro anything is only useful if your company is big and has a lot of separate departments. It solves a real organizational issues.
If your company is small, don't bother with any of these micro trends. The overhead of micro architecture is non-trivial: telemetry, tracing, test infra, build infra, non-prod environment setup, etc.
Re: Microfrontends should be a last resort
#50Isn’t a “micro front-end” just like a Turbo Frame in Rails now? Except, easier to manage within a monolith?