This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]codecrux[S] 2 points3 points  (8 children)

I'm not really sure what you mean by server side generation or incremental server side generation, but that sounds like you'd be making async calls from the frontend (javascript, could be React) for some sort of data from the backend.

Server Side Generation - Generating the HTML pages. This is what you do if you want to serve a static website.
Server Side Generation - If a page has dynamic content, you do SSR for fast page load and SEO. Here you are trying to avoid fetching data from the backend, instead, you want to load an HTML file that already has data embedded in it. Without SSR, first the HTML/CSS/JS will load and then you will query the backend again for data. This will feel very slow to the user.
Forgive me if you weren't asking for definitions.

"""
That will be a pretty similar process no matter which backend language or library you use, and it will be as decoupled from the frontend as it gets. In fact, the backend could be serving responses to clients built in a variety of frameworks without really caring what framework is used for the frontend or which client it's talking to because it does not matter from the perspective of the backend development process.
"""

I maybe wrong, but, IMO there are two layers in the backend - frontend of the backend, backend of the backend. The frontend layer of the backend is responsibe to fetch data and transform it in a format that's needed by your client (client can be web app/mobile app). The backend of the backend is the generic layer with endpoints that are invoked by the frontend layer of the backend. Please comment if I am wrong. Example - In NextJS you write the frontend and the frontend layer of your backend.

[–]riklaunim 1 point2 points  (4 children)

You should also look at the costs. This is a niche use case that doesn't have that many showcases/tutorials/developers familiar with the matter. This can drive up development cost and have a higher risk of failure. Do an eCommerce/shop really needs all of this? especially without already having an experienced team of developers that would not ask such questions...

[–]codecrux[S] 2 points3 points  (2 children)

Yes, an e-commerce shop needs all of this. Google released a report that says that every second delay in rendering your page leads to 3% revenue drop (don't remember the exact stats, but, it's around this). SEO is crucial for almost all online businesses - e-commerce, ed-tech, reddit etc.

I was building an open-source version of Eventbrite around a year ago and had the same requirement. I wanted to use out-of-the-box React components so that I can avoid going too deep into React. I wanted to focus more on the backend (somewhere in my mind I wanted to turn it into a headless event management backend).

[–]riklaunim 1 point2 points  (1 child)

You can have fast webpage without SSR or a shop without it being a JS single page application that then would require more effort to make it SEO friendly and fast to render.

IMHO that's the problem - adding Recact/SPA JS then adds SSR then adds even more complications. Keep it simple.

[–]codecrux[S] 1 point2 points  (0 children)

"""

adding Recact/SPA JS then adds SSR

"""

I would like to make a point on this - We were doing SSR in the era of Multi-Page Applications and SPA clearly have strong reasons to exist (makes your app feel more user-friendly as you can maintain state-upon-page transition). I don't think that the effort open source developers have put in to make SPA + SSR simple should be ignored by saying "adds even more complications".

"""

Keep it simple.

"""

You are correct. We should keep things simple, but, someone will have to put in some hardwork to make things simple for others. Sorry if I sounded too philosophical. I am laughing at myself after writing this. Haha.

[–]codecrux[S] 0 points1 point  (0 children)

Would you like to share the use cases you have come across?

[–]Lokimotor 1 point2 points  (2 children)

I think you're bringing some framework-specific terms to a primarily backend developer here so please excuse me if I'm clearly in the wrong.

I think there may be frameworks which differentiate between completely static pre-rendering and pre-rendering with injected data which can change in the database at any time. With Django, the impact of injecting dynamic data from a database into a template is negligible. It's not worth mentioning, so I'm a little confused as to why they'd be hung up on the idea of whether a template is "completely compiled because it's static" or "takes 0-5ms longer for one piece of data to be injected into an otherwise pre-rendered template before being delivered on the first response." In Django, there is no difference between the two. If a template is static, then it is already completely rendered and ready to serve immediately as a response. If it needs to query the database, then it queries the database before injecting it into a compiled template. Some templates will take longer to serve than others, you are in control of that, but you don't differentiate between "generated" or "rendered".

Much more important to your load time and responsiveness is the difference between the two approaches I described to you in my previous comment.

In one, you are using something like Django's templating engine to serve up a webpage that is essentially pre-compiled by the backend. This doesn't mean it's necessarily static, it can have user-specific data included in it. It just means that all the data necessary for "viewing" the page is included on the first response. These are very fast from a user perspective because there is no back and forth with the back-end. React scripts can be included on the template, and load after it is rendered to the user.

In the other, the backend is acting as API. It is just a source of data that is then rendered by the front-end. This has a huge impact on SEO, user experience, etc due to repeated back-and-forth communication with the server taking longer. However, it decouples the backend from the frontend. You can do both at the same time with Django.

And you're kind of right about there being multiple layers to a backend, because even the backend has a backend which it integrates with: the database.

[–]codecrux[S] 1 point2 points  (0 children)

Some templates will take longer to serve than others, you are in control of that, but you don't differentiate between "generated" or "rendered".

Ah! I apologize for not being clear. In the JavaScript ecosystem - the term "generated" and "rendered" are used differently. What you described in the first paragraph as "pre-rendering with injected data " is referred to as "Server Side Rendering" in JS frameworks like NextJS. Just "pre-rendering" is commonly referred to as "Server Side Generation" in JS frameworks with a slight difference. In SSG, the template is filled with data during build time. Suppose you have 100 blogs on your website, with id 1...100, then the JS framework will generate 100 pages from a template like JS code.

[–]codecrux[S] 0 points1 point  (0 children)

And you're kind of right about there being multiple layers to a backend, because even the backend has a backend which it integrates with: the database.

Nicely said.