Server-Side Rendering at Mobify

Mobify’s next upcoming product release includes a new environment to handle server side rendering (SSR) with the Mobify Platform. In this blog, we’ll cover everything you’ll need to know about our new SSR environment.

First, let’s review our previous SSR environment (referred to as the “browser-like” SSR environment), which will help provide some context on what’s changed and the benefits for our new SSR environment.

“Browser-like” SSR Environment

When Mobify originally embarked on the journey to becoming a Front-end Platform as a Service, we had to determine how to enable server side rendering for applications shipped through the Mobify Platform. There were two primary drivers that shaped the possible solutions our team came up with: 

  • Providing Mobify’s existing client-side rendered progressive web app customer base with an easy upgrade path to our end solution.
  • Ensuring it could support web scraping applications well for legacy customers.

Following these drivers, we also had two constraints we were bound to while solutioning:

  • Ensure that our customers wouldn’t have to re-build their existing application to run on a server
  • Minimize the number of project code changes that would be required to adopt our solution

We were able to navigate all of these constraints and drivers through the usage of JSDOM, a JavaScript-based headless browser used to emulate a web browser. This is how we came to name our previous SSR solution the “browser-like” SSR environment. JSDOM enabled us to stick a browser on the server side, and then render an existing application within that browser to re-use the application.

While the “browser-like” SSR solution allowed us to navigate all of our constraints and drivers, the solution overcomplicated the development experience. Developers would have to learn how to render their applications server side with an approach unique to the Mobify Platform, which ultimately wasn’t the developer experience we strive to provide developers.

Fast forwarding to the present day, our original drivers and constraints have evolved and changed, leading us back to the drawing board for a new solution. Additionally, we’re always striving to provide developers the best possible development experience we possibly can. Feedback indicated that developers were hoping to see a SSR solution that was more reflective of how React conventionally handles SSR.

This led us to move forward with a new solution to handling SSR in the Mobify Platform, which we’ve named the Node SSR environment.

Node SSR Environment

The key difference between the Node SSR and Browser-like SSR environments is the actual environment they’re running in. With Node SSR, we’ve moved to using a standard Node.js and Express.js environment, unlike the old environment that used a browser-like environment through JSDOM.

Node SSR also closely follows how React conventionally handles SSR, through the usage of their renderToString() function.

Here are some of the key benefits and changes when comparing the two SSR environments:

  • Familiarity and simplicity:Developers who are well-versed in conventional server side rendering with React will feel right at home with Node SSR. One of our objectives with the Node SSR environment was to provide developers a familiar approach in tackling SSR.
  • Decoupled: The Node SSR environment is completely state management library agnostic. Redux dependencies are now optional. The “browser-like” SSR environment previously had direct dependencies to Redux.
  • Improved developer experience: Node SSR provides developers full access to your applications HTML and HTTP responses so that they can make easily changes .
  • Interoperability: Since Node SSR leverages conventional React SSR practices, this will allow developers to easily leverage existing React and third party library documentation for SSR. This also results in Mobify’s own libraries and tools working better with others in a React ecosystem.

Conceptually, Node SSR should feel much easier for developers to grasp as they’ll no longer have to spend effort imagining a fake web-browser running server-side while developing.

Here’s a code example showing the simplified developer experience to set a simple HTTP header:

node-ssr-http-header

With Node SSR, developers have full access to their applications HTTP request and response objects, and can simply set HTTP headers like they would for any other Express application.

Upgrade path

For existing “browser-like” SSR environment projects looking to transition to the new Node SSR environment, there are three important considerations that should be taken into account to make the transition as seamless as possible:

  • Most importantly – ensure the projects Commerce Integrations connector and components are all able to run outside of a browser
  • Avoid the usage of browser globals throughout your application, such as window or document
  • Hide any browser related parsing hacks behind the projects Commerce Integrations connector

Maintenance & support

Following the release of the Node SSR environment, we’re committed to continue supporting both SSR environments. Node SSR will become the new default environment for any new projects generated. “Browser-like” SSR will no longer receive any major updates or improvements. However, we will continue to maintain and support it, and critical issues or bugs will continue to be addressed.

Looking for more?

Looking for a deeper technical overview of Node SSR or for some hands-on training? Please reach out to our support team to set something up directly with a Mobify team member.

Leave a Reply

avatar
  Subscribe  
Notify of
Resource ad

Subscribe to the Mobify Insights Blog

Stay in the know on the latest in mobile commerce so you can effectively engage your customers and drive revenue.

Related Articles