Home

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

React on Rails Pro

Node rendering and caching performance enhancements for React on Rails. See Egghead React on Rails Pro Deployment Highlights for a case study of React on Rails Pro usage at egghead.io.

Purchasing

You have 2 options:

1. React on Rails Pro comes with a ShakaCode Pro Support Plan.
2. You can buy a license for $950/year. I can do a free trial for select companies.

For more info, email justin@shakacode.com.

Features

Caching

See Caching for details.

Server Rendering

Server rendering JavaScript evaluation is cached if prerender_caching is turned on in your Rails config. This applies to all JavaScript evaluation methods.

Fragment Caching View Helpers

• Fragment caching for react_component and react_component_hash, including lazy evaluation of props.

React On Rails Pro VM Render

The "React on Rails Pro VM Renderer" provides more efficient server 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 manager 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 VM Renderer 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.

References

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