React on Rails PRO

React on Rails Thunder


Improve your server-response times up to 90% with React on Rails PRO!

“Anybody who regularly hits six digit request numbers a day is going to be in for a bad time. React on Rails PRO is perfect on this case. Do you want your app to randomly crash sometimes in hard to predict ways? Then Execjs is perfect for you.”

Pete Keen

Lead back end developer at

Get in touch to Buy $950/year

Code Splitting

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.

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.

Node React Server Side Render

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

Overall Management Memory and CPU

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.

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.

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.

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.

How much performance can I get from it?
decrease in server response time 90%

in server response time

read the article
decrease in server response time 68%

in server response time

read the article

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.

How do I purchase React on Rails PRO?

Get in touch to buy a license for $950/year.

We can do a free trial for select companies.

React on Rails PRO comes with a ShakaCode Pro Support Plan.

Get in Touch

Get Updates on React on Rails