Hacker News Reader

Comment by bigmattystyles | Hacker News Reader

If you don't do server side rendering, you don't (almost) automatically get a set of nice REST endpoints that return JSON/XML/ETC? I get that the abstraction might be nice for security, but at least for corporate intranet applications, a nicely structured, secured (e.g ODATA) webapi you query for client side rendering has the added benefit that it can be invoked programmatically with REST by other authorized parties. Obviously, you want the standard DDoS and security protections, but this fact alone, has turned me off server side rendering alone. Isn't it also nice from a computation cost standpoint to let the client do the rendering? I suppose UX could suffer and for external facing apps, this is likely of the utmost importance. Happy to be educated if I'm unaware of something else.

View on HN

What difference does it make, with respect to security, whether the server returns html or json that needs to be formatted into html?

The computation for rendering (in every case I've seen, and I have to speculate in 80% of cases ever) is so trivial compared to the actual retrieval of the data to be rendered.

None really, I was not eloquent about it - just that returning well structured data makes easier to extract data. You could also argue that if you render locally, you might return data used only for rendering that's not output and that also leaves your server's boundary where it wouldn't be necessary to leave at all with SSR. But like you said, these are things that are not really security.

Getting an API for free is an anti-feature for all the temporarily-embarrassed monopolists on HN.

More seriously, though, it's nice to be able to just build without thinking too hard about if you're getting your abstractions perfect. To me, this is the main advantage of SSR - moving fast doesn't leave behind a wake of idiosyncratic APIs that need to be (carefully, dangerously) cleaned up later.

In my experience moving-fast SSR absolutely does leave behind a wake of idiosyncratic APIs that definitely need to be cleaned up later.

You still need client-server communication, so you still have an API, it's just an ad hoc API that speaks HTML and form data instead of JSON. And because you didn't think of it as an API while you were building it, it actually tends to be harder to clean up later, not easier.

You probably have more experience than me. My primary SSR experience is with more recent frameworks and libraries like blitz and tRPC, which make it much easier to delete those when they are no longer used.

Maybe I misunderstand but it's pretty trivial to render different server side output based on context and is common in most frameworks.

Just pass a header for request content type json. Then the server returns data in json format as opposed to html.

but then you'll have a server side path for json and one for html. If I have rendering logic client side entirely, then I just have json / xml on the server. That's it.

No. It's one path. The client merely requests the the format it desires. The response handler on the server side returns the appropriate response format as requested by the client. Nothing crazy here.

Why are those things mutually exclusive? You can have an API and then have a different app that uses that API with server-side rendering. I.e. instead of a client SPA you have a server app using the API.

Sure they're both viable options, but running 2 server-side apps that could be 1 server-side app and a folder full of HTML/CSS/JS served over CDNs certainly has some trade-offs. e.g. in terms of security, I'd prefer to have a smaller surface area server-side.

Then you're comparing server-side apps to client-side ones. And imo the attack surface of managing a SSR webapp is fairly minimal - especially when you're already responsible for providing an API to the public. My point was more that API-first doesn't prevent you from doing server-side rendering and there are benefits to doing so.

> Isn't it also nice from a computation cost standpoint to let the client do the rendering?

Aside from all other implications, letting each client render the same stuff is a massive waste of energy and compute.

If it was truly the same computation then it could be a static site generator, but with typical server side rendering you are still doing a new render per user no?

Depends but most server side frameworks cache render outputs of varying granularity. So you can cache components that are static.

No? Each client may be receiving the same document, but based on their device, view port, preferences, etc… the rendered result may be different.

Either way, the measurement of Joules/page is likely to be such an astronomically small number compared to the constant cost of simply having a server at all IMO.

The number of devices is very small. I’m sure you get a number of different window sizes, but within a range, you can very slightly scale.

Are you suggesting we give up on rendering layouts that respond to different window sizes, display resolutions, and zoom levels? I think what you’re suggesting is that clients requesting websites should receive essentially an image of the website with limited interactivity, but that’s not going to make anyone that’s ever used a website satisfies in C.E. 2023.

You can make web pages responsive to "different window sizes, display resolutions, and zoom levels" with no JavaScript at all, so that's clearly not what they're suggesting.

That’s true, but it’s not like translating HTML into a bitmap for a display is some spontaneous process that happens for free. Your browser is anyone going to interpret all that HTML and CSS, and your users are going to click on buttons and submit forms that require changing that HTML and CSS. Whether that happens through JavaScript or SSR is bike-shedding: processing will be done, computation is needed, we can sit here and argue about how the web front end world sucks but billions of users expect interactive web applications that are very difficult to deliver without JavaScript.

Client-side json-to-html is such a microscopic part of the compute cost related to showing a change in a website that it's a rounding error. Totally inconsequential. A single widely-used inefficient css attribute or repaint costs WAY more.

I was talking about my power and computation costs, in the aggregate, I agree that it's worse.

As an example, Ruby on Rails makes this relatively trivial using respond_to https://apidock.com/rails/ActionController/MimeResponds/resp...

This is a non-problem in all SSR projects I've ever dealt with.

But how many of the SSR projects you have dealt with had a requirement to enable API access for users? If it's not a requirement, then yea, you're right, it's a non-problem.

Several. I just literally do not see the problem. I'm not saying it's absolutely the most efficient way to do a given project, just that it never was presented as any kind of problem to provide both a SSR app with an API. Obviously you just can't reuse already existing API routes and methods that you would if you had structure it as a SPA but you're likely rendering using SSR from structured data anyway which you can just send as JSON or whatever on a separate route.

I've done this multiple times and it's fine. It's really not an issue for delivering projects. I'm not saying I'd do this every time - if the API was identical for both my app/website and any other clients I'd very possibly abandon the SSR approach for the ease of a frontend API that everyone can use identically, but that's a specific project requirement not a general statement on SSR and API development.

Reply on news.ycombinator.com