u/WolfyTheOracle

▲ 5 r/microservices+1 crossposts

Are microservices the best way to scale many teams?

I hear scaling operations between teams on the same project is one of the strongest incentives for going into a microservice architecture.

I was wondering what everyone’s experience was on how true this was? Did you find that you started microservices but you still had to orchestrate deployments with consumers?

What other strategies are out there for solving for team operations without distributed systems.

I was even playing with an idea of the server compiler crashing when someone changed an api route that doesn’t belong to them, and a separate mechanism to lock down what api route can write data to a specific table and would also crash when others violated this.

Anyone ever explored programmatically enforced guard rails that might not be split up the project? Or is that really the most sound way to go about this.

EDIT: server compiler meaning a framework as the server or such. Imagine nextjs npm run dev, but it crashes with an error you’re not allowed to change this api route.

reddit.com
u/WolfyTheOracle — 6 days ago
▲ 234 r/EnterpriseArchitect+1 crossposts

Anyone going back to monolith?

I know there’s been a lot of companies online publicly consolidating back to a monolith. Makes sense. Centralized logging, no network hop, single process.

I think people realized there’s a lot more issues with distributed systems than originally pitched. So you need to make the cost analysis very carefully if that’s something you want to live with.

Wondering who here went back to a monolith or who here was quietly productive this whole time in a single server.

reddit.com
u/WolfyTheOracle — 7 days ago
▲ 8 r/react+1 crossposts

I see a lot of conversations about spa vs ssr in the react community and they almost always end up being about seo or load speed.

After building a few ssr apps i feel like we are majoring in minor things. ssr is not mainly about speed. it is about having a singular source of truth

in a lot of spa architectures the server returns json and then the client catches that json validates it stores it in memory updates shared state and finally renders react from that client side copy, at that point you have effectively created an in memory replica of your server state inside the browser

that replica becomes a cache

A huge amount of frontend complexity comes from managing the gap between server truth and client truth.

“There are only two hard things in computer science: cache invalidation and naming things.”

with server driven ui i have been able to write much simpler and more correct code

instead of

call api route
receive json
update client state
rerender react
the flow becomes

creatething() updates the db on the server and returns ui that gets morphed directly into the dom

the browser stops acting like a mini database and becomes mostly a rendering target again

to me that is the real value of ssr not seo

Sorry for formatting on phone

reddit.com
u/WolfyTheOracle — 8 days ago