Live data from Hacker News

Denial of service and source code exposure in React Server Components

react.dev

191–200 of 232 posts

Re: Denial of service and source code exposure in React Server Components

#191
post #81

I remember when the point of an SPA was to not have all these elaborate conversations with the server. Just "here's the whole app, now only ask me for raw data."

It's funny (in a "wtf" sort of way) how in C# right now, the new hotness Microsoft is pushing is Blazor Server, which is basically old-school .aspx Web Forms but with websockets instead of full page reloads. Every action, every button click, basically every input is sent to the server, and the changed dom is sent back to the client. And we're all just supposed to act like this isn't absolutely insane.

This is how client-server applications have been done for decades, it's basically only the browser that does the whole "big ole requests" thing.

The problem with API + frontend is:

1. You have two applications you have to ensure are always in sync and consistent.

2. Code is duplicated.

3. Velocity decreases because in order to implement almost anything, you need buy-in from the backend AND frontend team(s).

The idea of Blazor Server or Phoenix live view is "the server runs the show". There's now one source of truth, and you don't have to spend time making sure it's consistent.

I would say, really, 80% of bugs in web applications come from the client and server being out of sync. Even if you think about vulnerability like unauthorized access, it's usually just this. If you can eliminate those 80% or mitigate them, then that's huge.

Oh, and thats not even touching on the performance implications. APIs can be performant, but they usually aren't. Usually adding or editing an API is treated as such a high risk activity that people just don't do it - so instead they contort, like, 10 API calls together and discard 99% of the data to get the thing they want on the frontend.

Re: Denial of service and source code exposure in React Server Components

#192

I remember when the point of an SPA was to not have all these elaborate conversations with the server. Just "here's the whole app, now only ask me for raw data."

Yeah, but then people started building bloated static websites with those libraries instead of using a saner template engine + javascript approach which is fast, easy to cache, debug, and has stellar performance and SEO.

Little it helped that even React developers were saying that it was the wrong tool for plenty use cases.

Worst of all?

The entire nuance of choosing the right tool for the job has been long lost on most developers. Even the comments I read on HN make me question where the engineering part of the job starts.

Re: Denial of service and source code exposure in React Server Components

#193
post #178

I'm not going to let go my argument with Dan Abramov on x 3 years ago where he held up rsc as an amazing feature and i told him over and over he was making a foot gun. tahdah! I'm a nobody PHP dev. He's a brilliant developer. I can't understand why he couldn't see this coming.

I never saw brilliance in his contributions. Specially as React keeps being duct-taped. Making complex things complex is easy. Vue on the other hand is just brilliant. No wonder it's creator, Evan You went on to also create Vite. A creation so superior that it couldn't be confined to Vue and React community adopted it. https://evanyou.me

There's no need to take down and diminish other's contributions, especially in open source where everybody's free to bring a better solution to the table.

Or just fork if the maintainers want to go their way. If your solution has its merits it will find its fans.

Re: Denial of service and source code exposure in React Server Components

#194
react server components is something that should've never existed anyway.

are people shipping faster due to them ? or it's all complexity, security vulnerabilities like this. you're not facebook. render html the classic way if you need server rendered html. if you really do need an SPA - which is 5% of the apps out there - then yeah use client side react, vue, svelte etc - none of those RPC server actions etc

Re: Denial of service and source code exposure in React Server Components

#195

I remember when the point of an SPA was to not have all these elaborate conversations with the server. Just "here's the whole app, now only ask me for raw data."

Yeah, but then people started building bloated static websites with those libraries instead of using a saner template engine + javascript approach which is fast, easy to cache, debug, and has stellar performance and SEO. Little it helped that even React developers were saying that it was the wrong tool for plenty use cases. Worst of all? The entire nuance of choosing the right tool for the job has been long lost on m…

It also doesn't help that non-technical stakeholders sometimes want a say in a tech stack conversation as well. I've been at more than one company where either the product team or the acquiring firm wanted us to migrate away from a tried and true Rails setup to a fullstack JS platform simply because they either wanted the UI development flexibility or to not have to hire Ruby devs.

Non-technical MBA's seem to have a hard time grasping that a JS-only platform is not a panacea and comes with serious tradeoffs.

Re: Denial of service and source code exposure in React Server Components

#196
post #194

react server components is something that should've never existed anyway. are people shipping faster due to them ? or it's all complexity, security vulnerabilities like this. you're not facebook. render html the classic way if you need server rendered html. if you really do need an SPA - which is 5% of the apps out there - then yeah use client side react, vue, svelte etc - none of those RPC server actions etc

Agreed. Unfortunately, there's an entire content/bootcamp ecosystem pushing this stuff that came of age largely during the tech boom, as well as a bunch of early and mid-career devs and companies that are deeply tied to it. With major VC funding backing projects like Bun, Vercel, etc., I don't think this deeply flawed approach to development is going anywhere because the utopian JS fantasy of "it just works and runs everywhere flawlessly" is the ultimate myth of building for the web.

Re: Denial of service and source code exposure in React Server Components

#197

Earlier quoted context omitted.

If I control both the backend and the frontend, yes. Server-only async components on top of layout/page component hierarchy, components -> DTO layer -> Prisma. Similar to this: https://nextjs.org/blog/security-nextjs-server-components-ac... You still need API routes for stuff like data-heavy async dropdowns, or anything else that's hard to express as a pure URL -> HTML, but it cuts down the number of routes you need…

You’re just shifting the problem from HTTP to an adhoc protocol on top of it.

Yes but they’re also shifting the problem from one they explicitly have to deal with themselves to one the framework handles for them.

Personally I don’t like it but I do understand the appeal.

Re: Denial of service and source code exposure in React Server Components

#198

Earlier quoted context omitted.

You’re just shifting the problem from HTTP to an adhoc protocol on top of it.

Yes but they’re also shifting the problem from one they explicitly have to deal with themselves to one the framework handles for them. Personally I don’t like it but I do understand the appeal.

Maybe, but you go from one of the most tested protocol with a lot of tooling to another with not even a specification.

Re: Denial of service and source code exposure in React Server Components

#199

I'm not going to let go my argument with Dan Abramov on x 3 years ago where he held up rsc as an amazing feature and i told him over and over he was making a foot gun. tahdah! I'm a nobody PHP dev. He's a brilliant developer. I can't understand why he couldn't see this coming.

I'm not defending React and this feature, and I also don't use it, but when making a statement like that the odds are stacked in your favor. It's much more likely that something's a bad idea than a good idea, just as a baseball player will at best fail just 65-70% of the time at the plate. Saying for every little thing that it's a bad idea will make you right most of the time. But sometimes, occasionally, a moonshot…

You're probably right. This one just felt like Groundhog Day, but I can't argue with "nothing ventured nothing gained".

Re: Denial of service and source code exposure in React Server Components

#200
post #81

Earlier quoted context omitted.

It's funny (in a "wtf" sort of way) how in C# right now, the new hotness Microsoft is pushing is Blazor Server, which is basically old-school .aspx Web Forms but with websockets instead of full page reloads. Every action, every button click, basically every input is sent to the server, and the changed dom is sent back to the client. And we're all just supposed to act like this isn't absolutely insane.

This is how client-server applications have been done for decades, it's basically only the browser that does the whole "big ole requests" thing. The problem with API + frontend is: 1. You have two applications you have to ensure are always in sync and consistent. 2. Code is duplicated. 3. Velocity decreases because in order to implement almost anything, you need buy-in from the backend AND frontend team(s). The idea…

The problem with all-backend is that to change the order of a couple buttons, you now need buy-in from the backend team. There's definitely a happy medium or several between these extremes: one of them is that you have full-stack devs and don't rigidly separate teams by the implementation technology. Some devs will of course specialize in one area more than others, but that's the point of having a diverse team. There's no good reason that communicating over http has to come with an automatic political boundary.
Post reply on HN