Server-side rendering (SSR) using WebAssembly (Wasm)
This article discusses Server-side rendering using WebAssembly (SSR using Wasm). More specifically, how to launch a React application using the WasmEdge runtime.
For about the first decade of the internet, websites were loaded for the user through server-side rendering (SSR). This meant that the total contents of each web page were being loaded and rendered by the server and then sent to the user. This wasn’t necessarily called server-side rendering at the time, it was just how the client/server model of the internet worked.
However, an alternative was sorely needed because the nature of this process meant that whenever the user interacted with the web page, a full-page load would be required to render any changes. This lead to most web pages being static text & images because any increase in interactivity directly lead to a decrease in convenience for the user.
As usual, this inconvenience lead to innovation in the form of client-side rendering (CSR), a process whereby a web page was then delivered with minimal (or no root content) and whereby the Javascript on the client side would compile and render almost everything. Obviously this approach greatly improved functionality on the client’s side and also significantly reduced load times (by preventing full page loads during each user interaction with the page).
Now, almost all popular web applications are rendered client-side and most are a specific type known as single-page applications or SPAs [1]. Examples of SPAs include Gmail, Facebook, YouTube, Twitter and GitHub [2] [3]. Frameworks like Angular, React and (and more) are becoming widely used to develop these SPAs because they give developers the tools required for quickly and efficiently designing and maintaining entire sites[4].
A quick word about React.
React is a declarative, efficient, and flexible JavaScript library for building User Interfaces (UIs). React lets you compose complex UIs from small and isolated pieces of code. React has the ability to efficiently update and correctly render those UI components as the underlying data changes. From a developer’s point of view, React’s declarative nature makes code more predictable and also easier to debug. Most importantly for this article, React can also render on the server side.
As we mentioned, the main advantage of an SPA is that any page load after the initial content download does not require a round-trip from the server back to the user (SPAs do not require ongoing full page loads).
Initial application load time
There are some caveats with SPAs. Firstly, it is important to note that the need to initially download the entire single page application at the outset means the initial load time of a given SPA is lengthy (compared to a traditional generic page load). Simply put, this is because the entire application needs to be download at the outset; rather than just a page at a time.
Search Engine Optimisation (SEO)
Additionally, in the case of SPAs, search engine web-crawlers would initially see blank content within the div with ID of root which exists inside the SPAs main HTML file. With client-side rendered SPAs, whilst the data may have been downloaded, it is not necessarily rendered … yet.
From a search engine optimisation (SEO) point of view, in the case where a search engine’s web-crawler performs its request (to the SPA) in a different manner to a user’s browser, it is possible that the web crawler sees no content at all (and therefore has nothing to index).
In contract to these single page client-side rendered applications, single page server-side rendered applications render content to the web page immediately (content is generated on the server and sent to the client). The load time is fast, and in addition the content can be naturally indexed by web crawlers; subsequently performing better when it comes to that site’s SEO.
It is clear that configuring an application which can combine the fast initial load times of SSR, with improved SEO and the efficiency and flexibility of SPAs would be the best of both worlds. Thankfully, this can be done with WasmEdge-QuickJS.
WasmEdge-QuickJS is a WebAssembly-based JavaScript interpreter program for WasmEdge.
WasmEdge is a Cloud Native Computing Foundation (CNCF) Sandbox project which provides a lightweight, high-performance, and extensible WebAssembly runtime.
WasmEdge-QuickJS is able to render React app components on the server side and send HTML as a string (to the client’s browser).
Let’s see how this works.
Server-side rendering using WebAssembly is done by running the React JavaScript in the WasmEdge container and then sending the rendered elements to the browser. WasmEdge-QuickJS supports static rendering and streaming rendering on the server-side.
Static rendering
With static rendering, all dependencies and components from the React app are packed into a bundled JavaScript file. Once this JavaScript file is processed by WasmEdge-QuickJS (the WebAssembly-based JavaScript interpreter) the output is ready to be presented to the client’s browser in the form of an HTML string.
Streaming rendering
The streaming SSR examples make use of WasmEdge’s unique asynchronous networking capabilities and ES6 module support.
Rendering an entire React App
This React SSR demonstration, which uses WasmEdge-QuickJS, demonstrates how content from React’s traditional build can be rendered server side and sent to the client.
If trying this out, please note that this demonstration works best with a React app that was created using create-react-app and which has minimal changes after that point. Obviously taking a very complex React app with any alterations including changes to file locations, paths, dependencies, overall layout or any convention changes will be much more work.
The next task, in relation to this article, is to build this React Blog software which is part of this 32 lesson YouTube tutorial series called Full React Tutorial and then perform the React SSR modifications; running the blog as a server-side rendered app. Watch this space :)
Additional features and benefits of Server-side rendering (SSR) using WebAssembly (Wasm)
Aside from the improved load times, SEO and impressive performance gains, the WasmEdge runtime also provides isolation and protection for operating system resources and memory space. This means that WasmEdge’s implementation of SSR is able to execute user-defined or community-contributed code safely in its well-defined execution sandbox.
This allows shared use of a single server when performing SSR. For example, multiple user-defined applications and code (for SSR purposes) could be stored and executed on a single shared server.
References
[1] https://medium.com/jspoint/a-beginners-guide-to-react-server-side-rendering-ssr-bf3853841d55
[2] https://medium.com/@NeotericEU/single-page-application-vs-multiple-page-application-2591588efe58
[3] https://www.mindk.com/blog/single-page-applications-the-definitive-guide/
[4] https://www.monocubed.com/blog/top-single-page-application-frameworks/
