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.
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.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.