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.
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.
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.
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 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:
- Database calls to compute the props.
- Serialization of the props values hash into a JSON string for evaluating JavaScript to server render.
- Costs associated with evaluating JavaScript from your Ruby code.
- 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.
The "React on Rails Pro Node React Renderer" provides more efficient React Server Side Rendering on a standalone Node JS server.
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.
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.
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.
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.
See the Node React Render Docs.
See the Ruby API.
"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.
Caching is extremely useful to any server rendering you're doing, with or without ExecJS.
React on Rails pro support caching at 2 levels:
- Caching of rendering request to ExecJS (or the Node renderer). This avoids extra calls to ExecJS.
- 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.
- Monthly, $135/month, via Github Sponsors
- A license for React on Rails Pro.
- 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.
For more info on demoing or buying React on Rails Pro, email justin@shakacode.com.