Nobody:

Senior frontend Dev at my company: "microservices best thing ever"

Also him: "Relational databases gonna die"

Also him (talking to the DB team): "You're gonna dissapear, Mongo is the future"

Me: "Eh... Dude, Mongo is still a database.."

Him: "Microservices"

Send help...

I can send you a shovel, tape and some plastic bags.
Its essentially the same as help.

And this is why he stays at the front end!

Kill him. It's like the people who says that SQL DB outperform NoSQL DB...
Or that a language is the best...

@C0D4 He was researching how to also separate our frontend into "micro-builds" lol

@meseguer1998 well... that could be a whole new way of doing frontend.

Templates as a Service anyone... TaaS for short!

@meseguer1998 if needed, it possible and cool stuff. But microservices should mostly be used when you have a high rate mutation inside your services.

We do that.

Please don’t be rude, maybe he got some microservice problem in his pants.

Just start saying that he's wrong and macro services are the future. Either refuse to explain or make up some bs about what a macro service is.

Also claim that sequential files are going to make a comeback for data storage.

NO! You keep up!!

Start throwing buzzwords around yourself. I’d recommend pitching in to the conversation with the latest advances in AI driven cloud based blockchain analytics.

You know where to take it from there!

Microservices are going to disappear. YOU are going to disappear!

[B]-[L]-[O]-[C]-[K]-[C]-[H]-[A]-[I]-[N]~[!]

@netikras your blockchain can be made by microserices. Then you use nlp for auto interface contract and you an hypeful stack

@jotamontecino

BLOCKCHAIN!!!!!

I see that @netikras has mastered the art of buzzword-driven argumentation.

This is not ok from your side really, just don't disrupt this type of specie, let them live with their ideology for god sake.. shms..

@flocke [Eggs at Lee]!!! <- [that was a pun, figure it out or just ignore it]

Tell him JSP is the next big thing and frameworks are gonna end : /

Another guy following the "trend" I hate it when I have people like that at work, it causes chaos and nothing more

Microservices are great for things like document conversion, but the last place I worked at tried to make a microservice/API server for every little object (with their own databases). That was the dumbest thing ever. Data integrity becomes a massive problem for the application to handle since each API works independently and you don't have foreign keys. You can't perform joins without pulling from separate services and merging manually. It adds a billion new breaking points. It's confusing to dig into at first (new hires were lost). It's overly complicated to make a change (have to push to the API repo, update the SDK, pull the updated SDK into the website repo, push that repo, and finally deploy all at the same time with rollbacks if any one of them fails. Ugh. This structure works fine for a single API and satellite servers, but it sucks when there's a users API, a companies API, etc.

Microservices

Well, microservices is the way forward tho

@Froot nice bait!

@grumpyoldaf not at all. I was dead serious. Nobody writes huge monolithic systems anymore

Tell him about micro-frontends!

Dev used *Distraction*!

@Stebner55 This is an interesting comment. Since you seem very familiar with the thematics could you explain to me for what microservices work and for what they don't?

I.e. how did Netflix model their things to make it work for them?

Or in other words what would you consider to be the concerns of microservices?

@beggarboy Complexity doesn't disappear. In a monolith, you have a simple infrastructure and data integrity, but it's not made to change stuff. Too much coupling.

If you need to ease change for real, then microservices/service oriented is a good thing. But then the complexity goes to the infrastructure. You need to monitor it, having open tracing is a necessity and you'll need to create a continuous deployment pipeline.

@Stebner55 My infra it's 40% microservices and 60% services.
And the data integrity problem came with the services. You need to have a way to get the user data (authorization/id) as each service is stateless (most of the time)

And for our new dev, it's easier to modify a microservice than a service (a microservice been at most 200 lines).

Then come the services SDK and at last the microservices SDK.

And that's why his position is Frontend Developer.

Sending help...

404 Help Not Found.