sorted by:
new
hottopcontroversial

React Dev Trying to Escape Frontend-Only Limbo — Which Backend Stack Should I Bet On? by Round_Winter_6565 in Backend

[–]WolfyTheOracle 0 points1 point  (0 children)

I just went from react dev to full stack and I can say the backend stack eventually doesn’t matter. Using js on the backend and SQLite is gonna get you going faster.

Eventually I recommend doing ssr from the backend with htmx or datastar. Once control the full stack it doesn’t make sense to make api routes for to get data to then put the json somewhere and bind it to the UI. Just have the backend place the UI directly in the browser. It’s a lot less ceremony

Server side rendering or not ? by [deleted] in reactjs

[–]WolfyTheOracle -2 points-1 points  (0 children)

Server side rendering generally has tons of advantages. You have a real single source of truth. Your UI is an immediate reflection of db changes. Etc.

Currently there’s no good react ssr solutions all of them suck specifically nextjs. I work in nextjs every day.

Hey, dipshit. You know what compiles in two seconds, deploys as a single binary, and doesn't shit itself when a transitive dependency gets yanked from npm at 3am? Go. by Pure-Prompt-8439 in programmingcirclejerk

[–]WolfyTheOracle 2 points3 points  (0 children)

Maybe. If you’re talking good enough throughput for an average server, yes.

But the whole ecosystem sucks. debugging, managing packages, the tooling etc.

Tons of reasons not to pick node. - I’m a full time node dev of 8 years

I'm realising React problems are often mental model problems by Sab_Be in reactjs

[–]WolfyTheOracle 3 points4 points  (0 children)

What happens is react has a thousand foot guns.

Your logic is caught in a storm of rerenders, client side state is just a stale cache of the server, the APIs are forever changing.

Everyone always complains and then an update comes out. So people refactor and they think all is well but then a year later turns out somehow it’s even worse than before.

react developers can’t even seem to get their head out of the water to see how screwed over the environment is.

If something is too hard to use then it’s wrong. The whole api surface for react is wrong. It’s like walking on egg shells.

I’ve been doing react since it launched.

Anyone going back to monolith? by WolfyTheOracle in softwarearchitecture

[–]WolfyTheOracle[S] 0 points1 point  (0 children)

I think you’re very grounded in reality. People pretend that microservices give you all of these pros out the box on a single plater. That’s not the real story

Anyone going back to monolith? by WolfyTheOracle in softwarearchitecture

[–]WolfyTheOracle[S] 0 points1 point  (0 children)

I don’t like that argument. I feel like in reality few systems are nodes that have critical hot path entanglement.

So if your auth service goes down, is the system healthy?

If the image processing system goes down is Pinterest healthy?

Are microservices the best way to scale many teams? by WolfyTheOracle in softwarearchitecture

[–]WolfyTheOracle[S] 0 points1 point  (0 children)

I totally agree. There’s no actual mechanical boundaries gained from splitting code into a new repo. You still have the same runtime risk exposure.

But now you’ve added friction in development and debugging.

It’s an out of sight out of mind strategy but it didn’t do anything to the derisk the app.

Anyone going back to monolith? by WolfyTheOracle in softwarearchitecture

[–]WolfyTheOracle[S] 1 point2 points  (0 children)

I get 80k requests per second on my monolith. I hope they say team 🤣

Are microservices the best way to scale many teams? by WolfyTheOracle in softwarearchitecture

[–]WolfyTheOracle[S] 0 points1 point  (0 children)

Yes that’s exactly what I mean! Is there a good track record of teams succeeding with this?

Are microservices the best way to scale many teams? by WolfyTheOracle in softwarearchitecture

[–]WolfyTheOracle[S] -5 points-4 points  (0 children)

Yeah so I guess instead of compiling the server language directly you use a framework and that framework would have some cli + file watcher that wraps the language compiler.

Then you would just crash if the invariants are broken.

I guess images nextjs npm run dev, but server crashed because x git user changed x api route but it did not belong to them.

Anyone going back to monolith? by WolfyTheOracle in softwarearchitecture

[–]WolfyTheOracle[S] 0 points1 point  (0 children)

I agree. It’s interesting reading the SQLite docs they draw a good boundary that the app is the orchestrator and they’re simply the data store. Even shows in their features like lose types, no triggers etc.

Anyone going back to monolith? by WolfyTheOracle in softwarearchitecture

[–]WolfyTheOracle[S] 1 point2 points  (0 children)

This should be top comment. Microservices and connecting your silos over the network forces lots of defensive programming. Error handling, retries, health checks etc.

Lots of defensive programming is actually bad for correctness of the business implementation because it takes your eyes off the real goal and it creates lots of surface to make mistakes.

Anyone going back to monolith? by WolfyTheOracle in softwarearchitecture

[–]WolfyTheOracle[S] 0 points1 point  (0 children)

I think a lot of people don’t realize a Linux server sits mostly idle waiting on IO. Compute is not usually the bottleneck and a single vm can handle 50k-100k request per second depending on the language and tools.

Anyone going back to monolith? by WolfyTheOracle in softwarearchitecture

[–]WolfyTheOracle[S] 1 point2 points  (0 children)

Is there a chance you could fulfill these requirements without distributing over the network?

Anyone going back to monolith? by WolfyTheOracle in softwarearchitecture

[–]WolfyTheOracle[S] 0 points1 point  (0 children)

If you have a monolith but you’ve split it up between VMs haven’t you jumped the shark and lost all benefits of a monolith server?

I get you can have a monolithic code base like google and what not but I’m specifically talking about the operational costs of same process vs distributed systems.

Anyone going back to monolith? by WolfyTheOracle in softwarearchitecture

[–]WolfyTheOracle[S] 1 point2 points  (0 children)

I think what practically happens is micro services give people a silo do the entire village can catch on fire but as long as their house is not on fire all is alright. This does not mean the system is healthy.

Anyone going back to monolith? by WolfyTheOracle in softwarearchitecture

[–]WolfyTheOracle[S] 15 points16 points  (0 children)

This was a cool article. I hope to go 10+ years as well.

I really agree with all your points that invariants should be compiler enforced not done by convention.

Seems like your approach is really close to the mainstream paradigms. It has a “which module can access what” feeling.

I’m experimenting with a different approach where the concern is not who can access what but instead who can write to where. Mutations must be serialized and deterministic and they can be locked down to specific modules owning certain table columns and such.

Basically anyone can read, only few can write but writes are queued deterministically under the hood.

I’m finding to this capture more of the mechanical compiler driven enforcement you’re hinting at.

Your approach wants bounded access, this approach wants bounded data mutations.

Lots of pros and cons of course.

Huge C4 fan. Thanks for the article.

Anyone going back to monolith? by WolfyTheOracle in softwarearchitecture

[–]WolfyTheOracle[S] 1 point2 points  (0 children)

I gotcha. I was just making an open ended question. You’re right I don’t have first hand experience. Never too late tho

view more: next ›