Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Denial of service and source code exposure in React Server Components

react.dev

Post reply on HN
Print view View original

211–220 of 232 posts

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

#211

Post by procaryote »

sakesun wrote: post #159
jaredklewis wrote: post #122

Earlier quoted context omitted.

I do think RSC and server side rendering in general was over adopted. Have a Landing/marketing page? Then, yes, by all means render on the server (or better yet statically render to html files) so you squeeze every last millisecond you can out of that FCP. Also easy to see the appeal for ecommerce or social media sites like facebook, medium, and so on. Though these are also use cases that probably benefit the least f…

Deeply agree.

I've been at an embarassing number of places where turning off server side rendering improved performance as the number of browsers rendering content scales with the number of users, but the server-side rendering provisioning doesn't

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

#212

Post by acdha »

chuckadams wrote: post #201
ricardobeat wrote: post #99

Earlier quoted context omitted.

+1 to this. I seriously believe frontend was more productive in the 2010-2015 era than now, despite the flaws in legacy tech. Projects today have longer timelines, are more complex, slower, harder to deploy, and a maintenance nightmare.

I remember maintaining webpack-based projects, and those were not exactly a model of simplicity. Nor was managing a fleet of pet dev instances with Puppet.

Puppet isn’t a front end problem, but I do agree on Webpack - which is one reason it wasn’t super common. A lot of sites either didn’t try to bundle things or had simple Make-level workflows which were at least very simple, and at the time I noted that these often performed similarly: people did, and still do, want to believe there’s a magic go-faster switch for their front end which obviates the need to reconsider their architectural choices but anyone who actually measured it knew that bundlers just didn’t deliver savings on that scale.

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

#213

Post by procaryote »

array_key_first wrote: post #191
_jzlw wrote: 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…

Stop having backend and frontend teams. Start having crossfunctional teams. Problem solved.

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

#214

Post by fatbird »

array_key_first wrote: post #191
_jzlw wrote: 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…

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

No, the point of the API is to loosely couple the frontend and backend with a contract. The frontend doesn't need to model the backend, and the backend doesn't need to know what's happening on the frontend, it just needs to respect the API output. Changes/additions in the API are handled by API versioning, allowing overlap between old and new.

Code is duplicated.

Not if the frontend isn't trying to model the internals of the backend.

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

Velocity increases because frontend works to a stable API, and backend doesn't need to co-ordinate changes that don't affect the API output. Also, changes involving both don't require simultaneous co-ordinated release: once the PM has approved a change, the backend implements, releases non-breaking API changes, and then frontend goes on its way.

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

#215

Post by chuckadams »

acdha wrote: post #212
chuckadams wrote: post #201

Earlier quoted context omitted.

I remember maintaining webpack-based projects, and those were not exactly a model of simplicity. Nor was managing a fleet of pet dev instances with Puppet.

Puppet isn’t a front end problem, but I do agree on Webpack - which is one reason it wasn’t super common. A lot of sites either didn’t try to bundle things or had simple Make-level workflows which were at least very simple, and at the time I noted that these often performed similarly: people did, and still do, want to believe there’s a magic go-faster switch for their front end which obviates the need to reconsider t…

I do kind of miss gulp and wish there was a modern TS version. Vite is mighty powerful, but pretty opaque.

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

#216

Post by scotty79 »

Language with dynamic code evaluation on the server plus fat client-setver protocol that attempts to sync raw objects of the language. What could have gone wrong?

I wonder if similar magic fat pipe technologies (like Blazor) have similar vulnerabilities waiting to be discovered. Maybe compiled languaged are safer by default in this scenario, but anything built in Python, PHP, Ruby or any "code is data" language would probably fare similarly poorly.

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

#217

Post by crubier »

McGlockenshire wrote: post #102
_jzlw wrote: 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.

> And we're all just supposed to act like this isn't absolutely insane. This is insane to you only if you didn't experience the emergence of this technique 20-25 years ago. Almost all server-side templates were already partials of some sort in almost all the server-side environments, so why not just send the filled in partial? Business logic belongs on the server, not the client. Never the client. The instant you sta…

> The instant you start having to make the client smart enough to think about business logic, you are doomed.

Could you explain more here? What do you consider "business logic". Context: I have a client app to fly drone using gamepad, mouse and keyboard, and video feedback and maps, and drone tasking etc.

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

#218

Post by ricardobeat »

chuckadams wrote: post #201
ricardobeat wrote: post #99

Earlier quoted context omitted.

+1 to this. I seriously believe frontend was more productive in the 2010-2015 era than now, despite the flaws in legacy tech. Projects today have longer timelines, are more complex, slower, harder to deploy, and a maintenance nightmare.

I remember maintaining webpack-based projects, and those were not exactly a model of simplicity. Nor was managing a fleet of pet dev instances with Puppet.

Webpack came out in late 2012 and took a few years to take over, thankfully. I was lucky to avoid it at dayjob™ until around 2019.

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

#219

Post by rustystump »

hmcdona1 wrote: post #65
Uehreka wrote: post #55

Earlier quoted context omitted.

I think we (the Next.js user community) need to organize and either convince Vercel to announce official support of the Pages router forever (or at least indefinitely, and stop posturing it as a deprecated-ish thing), or else fork Next.js and maintain the stable version of it that so many of us enjoyed. Every time Next comes up I see a ton of comments like this, everyone I talk to says this, and I almost never hear a…

I would highly recommend just checking out TanStack Router/Start instead. It fills a different niche, with a slightly different approach, that the Next.js app router just hasn't prioritized enabling anymore. What app router has become has its ideal uses, but if you explicitly preferred the DX of the pages router, you might enjoy TanStack Router/Start even more.

Tanstack anything has breaking changes constantly and they all exist in perpetual alpha states. It also has jumped on the rsc train with the same complexity pitfalls.

Some libs in the stack are great but they were made pre rsc fad.

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

#220

Post by array_key_first »

christophilus wrote: post #208
array_key_first wrote: post #191

Earlier quoted context omitted.

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…

No, it's not. I've built native Windows client-server applications, and many old-school web applications. I never once sent data to the server on every click, keydown, keyup, etc. That's the sort of thing that happens with a naive "livewire-like" approach. Most of the new tools do ship a little JavaScript, and make it slightly less chatty, but it's still not a great way to do it. A web application should either be se…

Yes, as I've stated, the big stuff is new Web stuff.

When I say traditional client-server applications, I mean the type of stuff like X or IPC - the stuff before the Web.

> A web application should either be server-generated HTML with a little JS sprinkled in, or a client-side application with traditional RPC-like calls when necessary.

There's really no reason it "should" be either one or the other because BOTH have huge drawbacks.

The problem with the first approach (SSR with JS sprinkled) is that particular interactions become very, very hard. Think, for example, a node editor. Why would we have a node editor? We're actually doing this at work right now, building out a node editor for report writing. We're 95% SSR.

Turns out, super duper hard to do with this approach. Because it's so heavily client-side interactive so you need lots and lots of sync points, and ultimately the SERVER will be the one generating the report.

But actually, the client-side approach isn't very good either. Okay, maybe we just serialize the entire node graph and sent it over the pipe once, and then save it now and again. But what if we want to preview what the output is going to look like in real-time? Now this is really, really hard - because we need to incrementally serialize the node graph and send it to the server, generate a bit of report, and get it back, OR we just redo the report generation on the front-end with some front-loaded data - in which case our "preview" isn't a preview at all, it's a recreation.

The solution here is, actually, a chatty protocol. This is the type of thing that's super common and trivial in desktop applications - it's what gives them superpowers. But it's so rare to see on the Web.

Post reply on HN