airbnb.io - Hypernova A service for server-side rendering your JavaScript views4,266

Airbnb Engineering & Data Science

Airbnb.io Spined HTML

Airbnb Engineering & Data Science Airbnb.io Open SourceEventsBlogGithubCareersAirbnb.io HypernovaA service for server-side rendering your JavaScript views4,266By Josh PerezA service for server-side rendering your JavaScript views Why? First and foremost, server-side rendering is a largest user wits compared to just client-side rendering. The user gets the content faster, the webpage is increasingly wieldy when JS fails or is disabled, and search engines have an easier time indexing it. Secondly, it provides a largest developer experience. Writing the same markup twice both on the server in your preferred templating library and in JavaScript can be tedious and nonflexible to maintain. Hypernova lets you write all of your view lawmaking in a single place without having to sacrifice the user‘s experience. How? A user requests a page on your server. Your server then gathers all the data it needs to render the page. Your server uses a Hypernova vendee to submit an HTTP request to a Hypernova server. Hypernova server computes all the views into an HTML string and sends them when to the client. Your server then sends lanugo the markup plus the JavaScript to the browser. On the browser, JavaScript is used to progressively enhance the using and make it dynamic. Terminology hypernova/server - Service that accepts data via HTTP request and responds with HTML. hypernova - The universal component that takes superintendency of turning your view into the HTML structure it needs to server-render. On the browser it bootstraps the server-rendered markup and runs it. hypernova-${client} - This can be something like hypernova-ruby or hypernova-node. It is the vendee which gives your using the superpower of querying Hypernova and understanding how to fallback to client-rendering in specimen there is a failure. Get Started First you‘ll need to install a few packages: the server, the browser component, and the client. For minutiae purposes it is recommended to install either slantingly the lawmaking you wish to server-render or in the same application. From here on out we‘ll seem you‘re using hypernova-ruby and React with hypernova-react. Node npm install hypernova --save This package contains both the server and the client. Next, lets configure the minutiae server. To alimony things simple we can put the configuration in your root folder, it can be named something like hypernova.js. var hypernova = require('hypernova/server'); hypernova({ devMode: true, getComponent(name) { if (name === 'MyComponent.js') { return require('./app/assets/javascripts/MyComponent.js'); } return null; }, port: 3030, }); Only the getComponent function is required for Hypernova. All other configuration options are optional. Notes on getComponent can be found below. We can run this server by starting it up with node. node hypernova.js If all goes well you should see a message that says "Connected". If there is an issue, a stack trace should towards in stderr. Rails If your server lawmaking is written in a language other than Ruby, then you can build your own vendee for Hypernova. A spec exists and details on how clients should function as well as fall-back in specimen of failure. stow install hypernova Now lets add support on the Rails side for Hypernova. First, we‘ll need to create an initializer. config/initializers/hypernova_initializer.rb Hypernova.configure do |config| config.host = "localhost" config.port = 3030 # The port where the node service is listening end In your controller, you‘ll need an :around_filter so you can opt into Hypernova rendering of view partials. matriculation SampleController < ApplicationController around_filter :hypernova_render_support end And then in your view we render_react_component. <%= render_react_component('MyComponent.js', :name => 'Hypernova The Renderer') %> JavaScript Finally, lets set up MyComponent.js to be server-rendered. We will be using React to render. const React = require('react'); const renderReact = require('hypernova-react').renderReact; function MyComponent(props) { return <div>Hello, {props.name}!</div>; } module.exports = renderReact('MyComponent.js', MyComponent); Visit the page and you should see your React component has been server-rendered. If you‘d like to confirm, you can view the source of the page and squint for data-hypernova-key. If you see a div filled with HTML then your component was server-rendered, if the div is empty then there was a problem and your component was client-rendered as a fall-back strategy. If the div was empty, you can trammels stderr where you‘re running the node service. Debugging The developer plugin for hypernova-ruby is useful for debugging issues with Hypernova and why it falls when to client-rendering. It‘ll exhibit a warning plus a stack trace on the page whenever a component fails to render server-side. You can install the developer plugin in examples/simple/config/environments/development.rb require 'hypernova' require 'hypernova/plugins/development_mode_plugin' Hypernova.add_plugin!(DevelopmentModePlugin.new) You can moreover trammels the output of the server. The server outputs to stdout and stderr so if there is an error, trammels the process where you ran node hypernova.js and you should see the error. Deploying The recommended tideway is running two separate servers, one that contains your server lawmaking and flipside that contains the Hypernova service. You‘ll need to deploy the JavaScript lawmaking to the server that contains the Hypernova service as well. Depending on how you have getComponent configured, you might need to restart your Hypernova service on every deploy. If getComponent caches any lawmaking then a restart is paramount so that Hypernova receives the new changes. Caching is recommended considering it helps speed up the service. FAQ Isn‘t sending an HTTP request slow? There isn‘t a lot of overhead or latency, expressly if you alimony the servers in tropical proximity to each other. It‘s as fast as compiling many ERB templates and gives you the goody of unifying your view code. Why not an in-memory JS VM? This is a valid option. If you‘re looking for a siloed wits where the JS service is kept separate, then Hypernova is right for you. This tideway moreover lends itself largest to environments that don‘t once have a JS VM available. What if the server blows up? If something bad happens while Hypernova is attempting to server-render your components it‘ll default to failure mode where your page will be client-rendered instead. While this is a well-appointed safety net, the goal is to server-render every request. Pitfalls These are pitfalls of server-rendering JavaScript lawmaking and are not specific to Hypernova. You‘ll want to do any DOM-related manipulations in componentDidMount. componentDidMount runs on the browser but not the server, which ways it’s unscratched to put DOM logic in there. Putting logic outside of the component, in the constructor, or in componentWillMount will rationalization the lawmaking to goof since the DOM isn‘t present on the server. It is recommended that you run your lawmaking in a VM sandbox so that requests get a fresh new JavaScript environment. In the event that you decide not to use a VM, you should be enlightened that singleton patterns and globals run the risk of leaking memory and/or leaking data between requests. If you use createGetComponent you’ll get VM by default. LinksGithub© Airbnb, Inc.© Airbnb, Inc.CareersDesignCareersDesignCareersDesign