re: Server Side Rendering pros and cons. When to use it and when to choose something else VIEW POST

VIEW FULL DISCUSSION
 

Nice article. It's quite sad though you talk about SSR without explicitly pointing out that this only works with a node server and therefore, you don't talk about alternatives regarding other types of servers & backend languages.

Alternatives are:

  • Prerendering (obviously works too)
  • Putting a node server in front of your initial server and proxy api calls
  • Using $V8js module on PHP if you use PHP
  • As someone said below, just do a regular website like we always did with backend languages, stringify then hydrate your React, Vue or any SPA framework app with the data. (this solution can be quite challenging though).

In summary, if you have a server thats is NOT node, you pretty much want to go with prerendering. I would even say prerendering is most of the time the best bet.

SSR is IMHO overkill for many apps, but people like to put it to be "in the futur" if you know this reference :)

Great article though.

 

I like to use a dedicated render service and a separate API service. You can run the rendering on a node server or serverless. The API might use a totally different technology in this case.

 

yes that is a good way to go. BUT! (haha always a "but"), if you have a lot of traffic and a load balancer, your load balancer will have x2 requests each time, one from the client (browser) to the render server, and one from the render server to the API server.

Which means, if you have 1Millions http requests, you end up with 2Millions request, and that may cost a lot and be quite slow as there are 2 hhtp request for only one page asked by the client.

A way to breaj that is to have both servers on the same machine and do the inner communication through direct IP instead of a dedicated domain name to reduce domain resolving.

code of conduct - report abuse