React.js Efficient Server Rendering (Using Node.js as a Proxy Server)

Don’t you just love how React.js works? The simplicity that it creates in the front-end code. How we can write code in JSX Components instead of function calls or create JSX Components using functions (HOOKS API YAAYYYYYYY)! Creating Web Applications has never been easier than it is now. And this also leads to more posts in recruitment site on “hire React.js developers.” The Market is crazy right now for it.

But in some scenarios, such as if we require better performance in load time for a frontend page or we need to implement SEO with dynamic JSX content. The primary way of serving up the frontend (pushing up the code on the server and running ‘npm run start’ or ‘yarn start’) is not the optimum way to do so. And it is for such cases that Facebook developers have enabled us to serve the build-up using basic Node Js Functionality.

To-do so, we follow the following steps:

1. The Client sends a request to get the JSX code.

2. The server (which we build up using Node.js) will get the main file containing the JSX code.

3. Then we will render it to plain browser understandable HTML code.

4. We will, well actually the Node.js server will send the HTML response back to the clientele.

5. With the help of HTML Markup, the client loads React.js client-side code to add dynamic logic to the rendered HTML.

What this does is help us acquire the goals that we had — first is reducing the time taken for React to render the Components. It will load the HTML content much faster, and it will help in providing content to Search Engine bots or the website crawlers.

That great!! Isn’t it? But do we develop all servers using Node.js?

Not, so what to do if we have a large-scale project that uses Python Django and React.js in the frontend. Or should I just change and create the applications in native HTML? Will your “hire ReactJS developer” posts go to waste? Or should I stick to Node.js for all backend code that requires server-side rendering?

Well, we cannot do either of those. There are some options to embed some JS engines in Python that quenches our desire for the server-side rendering. So, should we embed JS engines to Python? Just for the server-side rendering? I don’t think so.

The workaround for this is to create a proxy server in Node.js, just for the purpose to serve up the React.js JSX template and nothing else. We build up a standalone Node.js server. The Python server will make a proxy request the Node.js server. The Node.js server will then render the JSX content and prove native HTML code back to the Python Django template. Using this approach will surely help you in the goals for a faster serving of the HTML pages and providing content to Search Engine Bots.

Proxy Rendering?? How Will We Implement It?

Don’t worry; I have you guys covered. Here is a code snippet that will help you in proxy rendering for Python.

import requests
import json

ProxyAddress = 'http://127.0.0.1:3000/'

def recieve_html(file, prop):
   Try:
       props_str = json.dumps(prop)
       r = requests.post(url=ProxyAddress + file
                         , data=props_str
                         , headers={'Content-Type': 'application/json'})
       if r.status_code == 200:
           return r.text, props_str
   except Exception as exp:
       print(exp)
   return False, False

What this code does is, it makes a POST request to the Node.js server. And in response receives the HTML code, rendered by the Node.js server.

The main profit points:

1. No need to integrate Node.Js or use Js engines in Python.

2. The ability to keep the JSX cache. It helps reduce the load time even more.

3. You can scale the backend services without scaling the rendering service. Thus, it will give you the ability to have multiple servers with a single cached rendering service to attain better performance.

4. Huge flexibility in writing the code. Just need to pass an object to the Node.js server in order to receive the HTML.

Proxy Rendering In Producation

In production, the proxy server runs without any excessive memory or CPU consumption and without the need to restart. The average page rendering for the initial time is 600ms. But due to the Node.js require caching and service caching, the average time is reduced to 10ms.

This tool helps in other languages as well. Like in Go, Ruby or Java but still allows me to use fancy frontend frameworks and tools.