Home

This wiki is used ONLY for React on Rails Pro, the paid, enhanced version of React on Rails.

See React on Rails Pro for the most recent updates.

React on Rails Pro

Improve your server-response times up to 90% !

Performance enhancements and priority support for React on Rails.

HVMN Testimonial, Written by Paul Benigeri, October 12, 2018

The price we paid for the consultation + the React on Rails pro license has already been made back a couple of times from hosting fees alone. The entire process was super hands-off, and our core team was able to focus on shipping new features during that sprint.

See Egghead React on Rails Pro Deployment Highlights for a case study of React on Rails Pro usage at egghead.io.

Features

Code Splitting

From The Cost of JavaScript in 2018:

To stay fast, only load JavaScript needed for the current page. Prioritize what a user will need and lazy-load the rest with code-splitting. This gives you the best chance at loading and getting interactive fast. Stacks with route-based code-splitting by default are game-changers.

We've got this already in production at https://egghead.io.

Caching

Server Rendering

Server rendering of JavaScript evaluation is cached if prerender_caching is turned on in your Rails config. This applies to all JavaScript evaluation methods, including ExecJS and the Node VM Renderer.

Fragment Caching View Helpers

Fragment caching is available via the cached_react_component and cached_react_component_hash view helpers. This includes lazy evaluation of props. Such fragment caching saves a ton of CPU work for your web server and greatly reduces the request time.

Fragment caching is a HUGE win, as it completely skips the evaluation costs of:

1. Database calls to compute the props.
2. Serialization of the props values hash into a JSON string for evaluating JavaScript to server render.
3. Costs associated with evaluating JavaScript from your Ruby code.
4. Creating the HTML string containing the props and the server-rendered JavaScript code.

Note, even without server rendering (without step 3 above), fragment caching is still effective.

See Caching for more additional details.

React On Rails Pro Node React Render

The "React on Rails Pro Node React Renderer" provides more efficient React Server Side Rendering on a standalone Node JS server.

Overall Management Memory and CPU on both the Rendering and Ruby Servers

A separate Node rendering server is easier to manage in terms of monitoring memory and CPU performance, allocating dynos, etc. This also makes it easier to manage the ruby servers, as you no longer have to consider the impact of starting an embedded V8. Thus, you can never hang your Ruby servers due to JavaScript memory leaks.

Proper Node Tooling

A disadvantage of Ruby embedded JavaScript (ExecJS) is that it precludes the use of standard Node tooling for doing things like profiling and tracking down memory leaks. With the renderer on a separate Node.js server, we were able to use node-memwatch (https://github.com/marcominetti/node-memwatch) to find few memory leaks in the Egghead React code.

Caching of React Rendering

To limit the load on the renderer server or embedded ExecJS, caching of React rendering requests can be enabled by a config setting. Because current React rendering requests are idempotent (same value regardless of calls), caching should be feasible for all server rendering calls. The current renderer does not allow any asynchronous calls to fetch data. The rendering request includes all data for rendering.

Rolling Restart of Node Workers

Due to poor performance and crashes due to memory leaks, the rolling restart of node workers was thus added as an option to the core rendering product. This option is cheap insurance against the renderer getting too slow from a memory leak due to a bug in some newly deployed JavaScript code.

Docs

See the Node React Render Docs.

Other Utility Methods

See the Ruby API.

Testimonials

"Do you want your app to randomly crash sometimes in hard to predict ways? Then ExecJS is perfect for you" Anybody who regularly hits six-digit request numbers a day is going to be in for a bad time." Pete Keen, https://egghead.io

For details, see Egghead React on Rails Pro Deployment Highlights.

FAQ

Why should I use React on Rails Pro if ExecJS seems to work?

Caching is extremely useful to any server rendering you're doing, with or without ExecJS.

React on Rails pro support caching at 2 levels:

1. Caching of rendering request to ExecJS (or the Node renderer). This avoids extra calls to ExecJS.
2. Fragment caching of server rendering. This avoids even the calculations of prop values from the database and the cost of converting the props to a string (lots of CPU there)

By doing such caching, you will take a CPU load off your Ruby server as well as improving response time. And this is with virtually no code changes on your part.

Purchasing

See React on Rails Pro

Price

• Monthly, $135/month, via Github Sponsors

Includes:

1. A license for React on Rails Pro.
2. For each calendar month, up to one hour of support, via Slack, zoom, Github reviews, etc. or one hour removed from the invoice for additional consulting for the month at $135/hour.

For more info, email justin@shakacode.com.

References

• Caching
• Rails Configuration
• VM Renderer Docs
• HTTP Caching