CSR, SSR or SSG content

Content on the internet is usually divided into three parts: CSR or Client-Side Rendering, SSR or Server-Side Rendering and SSG or Static Site Generation. CSR content is usually created by JavaScript frameworks on the client side, which is why search engines cannot easily understand them. SSR content is processed on the server side and is easily understandable by search engines. However, to create this content, the server must be involved in processing them each time. The best contents for publishing on the web are SSG contents because they are completely understandable by search engines and the server will not be involved in processing their data. Static contents can be placed on CDNs (Content Delivery Networks) and requests for this content can be returned from the stored location on the network before it reaches the server. To understand the popularity of SSG content, you can refer to popular JavaScript frameworks such as Gastby and NextJS.

One of the biggest problems with creating SSG content is the complexity of the data model. As the number of requests for data from the database increases, the amount of content that can be converted to SSG decreases. Because to create SSG content, the number of requests to the database must reach zero in order to produce static content.

Lesan’s framework has simplified the conditions for creating SSG content by reducing the number of requests to the database.

In addition, Lesan only updates SSG content when a data has changed. Unlike the process that is usually used in NextJS or Gastby, which uses time periods to create and update SSG content due to lack of awareness of data changes. In this way, a specific time is determined in advance (for example, one day) to generate SSG content, and when that time ends, they send a request to the server to receive the content again and convert it to SSG and repeat this process. This cycle has two major problems:

• First, it is possible that the data has not changed and an unnecessary processing task is imposed on the server which can cause problems if the number of these requests on the server increases.
• And the second problem is that it is possible for the content on the server to change and it may be necessary to quickly update that content everywhere, including places where SSG content is stored. But in current processes, we have to wait until the time we have set in advance ends and send another request to the server to update the SSG content.

Returning to the example of a news agency, if this website intends to convert its news to SSG content, it will face both of the above problems. On the one hand, the process of generating SSG content may be performed for many news items that have not changed, which creates an unnecessary processing load for the server. On the other hand, it is possible that a news item has been mistakenly converted to SSG content and the news agency wants to remove it quickly, but we have to wait until the end of the specified time for that content to disappear. Also, someone has to request this news after the end of this time. For these two simple reasons, many websites prefer to process their content in SSR form. But how can we create SSG content only when data changes in the main database? This can be easily done with Lesan.