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

91–100 of 143 posts

Re: Microfrontends should be a last resort

#91

Post by slotrans »

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…

> lately

always has been dot jpeg

I remember GlueCon 2012, just wall-to-wall NoSQL hype, with a dash of microservices on top. Anyone who ran home and implemented stuff from those talks was absolutely wasting their time (me included).

Re: Microfrontends should be a last resort

#92

Post by yakshaving_jgt »

SkyBelow wrote: post #58
nogridbag wrote: post #35

Earlier quoted context omitted.

> 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 o…

> 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

Awesome. There are plenty of programmers who aren’t magpies distracted by shiny trinkets. I hope they get jobs. They can take the seats of those people who can’t bear not wasting time on the next new fad.

Re: Microfrontends should be a last resort

#93

Post by bluGill »

bdougherty wrote: post #75
bluGill wrote: post #44

Earlier quoted context omitted.

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.

Until the org chart is reorganized, then what?

Then you reorg the system. Note that this can go either direction - you can also change your system to how you want the org chart to look. Generally it goes one way because engineers rarely have the power to change the org chart, but sometimes we are consulted and can suggest 'improvements'.

Re: Microfrontends should be a last resort

#94

Post by bluGill »

esafak wrote: post #47
bluGill wrote: post #42

Earlier quoted context omitted.

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.

Those are good best practices, but they don't solve the problem. If nothing else you end up supporting a V1 API that is now very unlike how you want people to use your system.

Often the pain of supporting this is so high you will just refuse to ask if the API can be improved despite the pain of the bad API.

Re: Microfrontends should be a last resort

#95

Post by lioeters »

nickpeterson wrote: post #26
js8 wrote: post #24

Earlier quoted context omitted.

> God help us. Good luck, I think God is too busy refactoring his Perl code.

I think we both know it’s all lisp.

> "Truly, this was the language from which the Gods wrought the universe."

> "I mean, ostensibly, yes. Honestly, we hacked most of it together with Perl."

Re: Microfrontends should be a last resort

#96

Post by mrinterweb »

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.

Re: Microfrontends should be a last resort

#97

Post by mirekrusin »

flakes wrote: post #48
js8 wrote: post #24

Earlier quoted context omitted.

> God help us. Good luck, I think God is too busy refactoring his Perl code.

Does God write in Perl 5 or 6?

Black holes look like million dollar mistakes so probably something else, but the rest keeps working so probably not a monolith.

Re: Microfrontends should be a last resort

#98

Post by 29decibel »

I think Microfrontends could really work pretty well if you have end to end vertical tooling support, like organization unified package management, authentication, logging, error tracking, testing, CI/CD etc. If any team can bootstrap all of these vertically supporting any major frameworks, then it might be a good idea. But let's face it, most of us don't have that luxury.
Post reply on HN