Recently in the development of a server-side rendering tool, through a brief introduction to server-side rendering, and server-side rendering methods. There are two server-side rendering ideas later in this article. Based on the pros and cons of server-side rendering, which one would you choose?

What is server-side rendering

Use React to build client applications. By default, you can export the React component to the browser for DOM generation and DOM manipulation. React can also be converted to HTML on the server via Node.js, which “renders” the processed HTML strings directly on the browser side. This process can be considered “isomorphic” because most of the application code can be run on both the server and the client.

Why server-side rendering

The advantages of server-side rendering (SSR) over traditional SPA(Single Page Application) are:

  1. Better SEO, thanks to search engine crawler crawler tools can view fully rendered pages directly.
  2. Better user experience, for slow network situations or slow devices, the resource browser renders directly after loading, without waiting for all JavaScript to finish downloading and executing before displaying the HTML rendered by the server.

Drawbacks of server-side rendering

  1. Due to the server and browser client environment difference, select some open source libraries need to pay attention to, some libraries can not be executed in the server, for example, you have document, window and other object acquisition operations, will report errors in the server, so in the selection of open source libraries to do the screen.
  2. Using server-side rendering, such as creating a dedicated server-side rendering service, requires more knowledge of Node.js server and deployment than the static resources required by the client
  3. The server needs more load to complete the rendering in Node.js, which takes up a lot of CPU resources due to Node.js.
  4. This new operation has new problems, such as two API requests and various server side problems. You can’t do anything about it, because the new tool is written in Golang. Your team or you need to learn more about Golang.

The server side renders in two ways

According to the above introduction to the pros and cons of server rendering, we can make trade-offs according to the pros and cons. Recently, in the project of server rendering, we found a variety of server rendering solutions, which can be roughly divided into two categories.

The first way

There are many tools that use this approach, such as React (Next-js), Vue (nuxt.js), etc.

Some tools run WebPack in the server production environment, compile in real time, and cache the compiled results. This is still the traditional way, but running WebPack on the server in real time is still a pre-compiled problem in the development environment.

I choose to put Webpack in the development environment and only do the function of development packaging, including packaging the client bundle, server bundle, resource mapping file Assets. json, CSS and other resources for deployment.

  • Server Bundle for Server-side Rendering (SSR)
  • The client bundle loads the browser. The browser loads more chunk JS from the bundle
  • Resource mapping file assets.jsonIt is,Server bundleIn preparing the required HTML, it is necessary to pre-insert those module (chunk) JS, and CSS, which only improves the user experience.

I recently built a kkT-SSR wheel that encapsulates part of the tool. You only need to write business code and a small amount of server rendering code. There are also dozens of examples, plus a relatively complete example of React-Router + Rematch. Similar to next.js, but with considerable differences.

The second way

This is an innovative approach, front-end single-page application, how to play before, and still play now, the additional step is that you have to visit a Rendora service first, in front of the interception whether server rendering is required. Below is the official image:

This approach was originally just an idea, the idea is that the front-end doesn’t have to deal with server rendering, isn’t it SEO? Yesterday, I happened to see a tool named Rendora on GitHub’s trending list. It happened to be the same idea. This tool mainly provides zero-configuration server rendering for web crawlers. To effortlessly improve SEO issues for websites developed in modern Javascript frameworks such as react.js, Vue. Js, angular.js, etc.

This is a great way to create a new Rendora service without changing any of the previously written projects. For each request from the front-end server or external (Baidu Google crawler), Rendora will detect or filter it based on configuration files, headers, and paths to determine whether Rendora should pass only the initial HTML returned from the back-end server or the HTML rendered from the headless server side provided by Chrome. More specifically, there are two paths for each request:

  1. The request is whitelisted as a candidate for SSR (i.e., filtered Get requests), and Rendora instructs the headless Chrome instance to request the corresponding page, render it, and return HTML containing the final server-side response. Usually only need to baidu, Google, Bing crawler and other network crawling tools included in the white list.
  2. Without being whitelisted (that is, the request is not a GET request or does not pass any filters), Rendora will simply act as a reverse HTTP proxy, passing the request and response as-is.

Rendora can be thought of as a reverse HTTP proxy server between back-end servers (e.g. Node.js/express.js, Python/Django, etc.), or your front-end proxy server (e.g. Nginx, Traefik, Apache, etc.),

Rendora is as close to perfect a dynamic renderer as I’ve seen, providing zero configuration server-side rendering

Which server-side rendering do we choose?

Rendora, the new approach is awesome and has many advantages:

  1. Easy migration of old projects, no front-end and back-end code changes required.
  2. Possibly faster performance, and possibly less resource (CPU) consumption, Golang writes binaries
  3. Multiple caching strategies
  4. You already have the Docker container scheme

This tool, server-side rendering of the page need to cache, cache caused by the small problem is

  1. Performance issues with caching and issues with calling the API twice, server rendering, client rendering, normally calling the API once, now calling it twice.
  2. Cached pages can not be cleaned up in time. For example, the website finds that users have sent bad information and need to be cleaned up. It is necessary to clear cached pages.
  3. If you want to improve the user experience, some pages on the browser side need to be rendered by the server side. At this time, the server side needs to request API, and there will be permission problems. Or the HTML read directly from the cache to the browser client side, there may be inconsistency between the server side and the browser side rendering error.

If the above two approaches are not on your radar, Rendora is the perfect server-side rendering solution for you

conclusion

Feel my wheel KKT-SSR seems to be written in white, after analysis found that there is still a bit of effect, at least to solve the problem of not calling API once, and API call permissions caused by inconsistent rendering. But I prefer the Rendora way, which is the future.