Hacker News Reader

Comment by PedroBatista | Hacker News Reader

Similarly with frontend devs thinking a "modern web-app" can only be built with frontend frameworks/libs like React/Vue/Svelte, etc, lately I feel there's an idea floating around that "monolith" equals running that scary big black ball of tar as a single instance and therefore "it doesn't scale", which is insane.

Another observation is the overall amount of code is much bigger and most of these services are ~20% business/domain code and ~80% having to deal with sending and receiving messages from other process over the network. You can hide it all you want, but at the end of the day it's there and you'll have to deal with the network in one way of another.

Just like the frontend madness, this microservice cult will only end once the economy goes to crap and there's no money to support all these Babel Towers of Doom.

PS: microservices have a place, which is inside a select few of companies that get something out of it more than the cost they pay.

View on HN

I think the thing people normally miss about microservices is that the goal of microservices is usually to solve organization and people problems and not technological ones. There's some tech benefits like allowing services to scale independently, but the biggest benefit is clear ownership boundaries and preventing code from becoming overly coupled where it doesn't need to be.

If you're a team small team working on a single product you probably don't need microservices since you likely don't have the type of organizational problems that microservices solve. Microservices are likely premature optimization and you're paying the price to solve problems you don't yet have.

Yep.

There are situations where microservices genuinely add net value. In discussions like this one, people make valid points for microservices and for monoliths. Often, words like “large” and “many” are used without providing a sense of scale.

Hers is a heuristic. It’s not a hard rule. There are likely good counter examples. It does sketch a boundary for the for/against equation for microservices. Would love to hear feedback about whether “100” is that number or a different heuristic would be more accurate.

Engineering departments with fewer than 100 engineers should favor monoliths and seriously question efforts to embrace microservices. Above that, there’s an increasing chance the microservices could provide value, but teams should stick to a monolith as long as possible.

> Similarly with frontend devs thinking a "modern web-app" can only be built with frontend frameworks/libs like React/Vue/Svelte

Those aren’t frameworks, they are view libraries and I’ll die on that hill.

Further, front end complexity is all in your head: https://bower.sh/front-end-complexity

That's why I included "/libs", for people like you :)

To be clear, for me they are libraries, but realistically people use them as frameworks, as in "standard" ways to think, "frame" and implement something.

But because I'm not dying on any hill specially front-end ones, I'll take a right then a left and go on my way.

While I agree with you that a lot of websites overuse javascript and frameworks. Can you tell me what else I'm supposed to use if I'm going to build a desktop class web app without it becoming a huge mess or I having to end up up inventing the same concepts already existing in these frameworks?

"desktop class web app" is a subset of "modern web-app". If you need frameworks, use them.

The meaning behind these is pretty blurry between whats considered a website vs an app, it's a spectrum. I consider a web app something that has a similar UI experience to a desktop app, as the word "application" came derived from the desktop.

Reply on news.ycombinator.com