5 ms·

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 mi

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.

the_gastropod 4y ago
As an example, Ruby on Rails makes this relatively trivial using respond_to https://apidock.com/rails/ActionController/MimeResponds/respond_to https://apidock.com/rails/ActionController/MimeResponds/resp...
ttymck 4y ago
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.
- bigmattystyles 4y ago
  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.
zelphirkalt 4y ago
> 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.
- bigmattystyles 4y ago
  I was talking about my power and computation costs, in the aggregate, I agree that it's worse.
- mattnewton 4y ago
  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?
  - TrispusAttucks 4y ago
    Depends but most server side frameworks cache render outputs of varying granularity. So you can cache components that are static.
- guhidalg 4y ago
  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.
  - Schiendelman 4y ago
    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.
    - guhidalg 4y ago
      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.
TrispusAttucks 4y ago
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.
- bigmattystyles 4y ago
  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.
  - TrispusAttucks 4y ago
    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.
bigDinosaur 4y ago
This is a non-problem in all SSR projects I've ever dealt with.
- bigmattystyles 4y ago
  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.
  - bigDinosaur 4y ago
    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.
hamandcheese 4y ago
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.
- lolinder 4y ago
  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.
  - hamandcheese 4y ago
    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.
achillean 4y ago
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.
- ducharmdev 4y ago
  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.
  - achillean 4y ago
    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.

the_gastropod 4y ago

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

ttymck 4y ago

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.

bigmattystyles 4y ago
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.

zelphirkalt 4y ago

> 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.

bigmattystyles 4y ago
I was talking about my power and computation costs, in the aggregate, I agree that it's worse.
mattnewton 4y ago
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?
- TrispusAttucks 4y ago
  Depends but most server side frameworks cache render outputs of varying granularity. So you can cache components that are static.
guhidalg 4y ago
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.
- Schiendelman 4y ago
  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.
  - guhidalg 4y ago
    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.

TrispusAttucks 4y ago

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.

bigmattystyles 4y ago
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.
- TrispusAttucks 4y ago
  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.

bigDinosaur 4y ago

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

bigmattystyles 4y ago
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.
- bigDinosaur 4y ago
  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.

hamandcheese 4y ago

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.

lolinder 4y ago
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.
- hamandcheese 4y ago
  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.

achillean 4y ago

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.

ducharmdev 4y ago
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.
- achillean 4y ago
  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.