This article is aimed at developers who are interested in Server Side Rendering ( ) but don’t know where to start or developers who are familiar with but want more info on using async code splitting with . If you are interested in optimizations to achieve faster page load times and smoother UX experiences, this is for you too. SSR SSR SSR tldr; Server Side Rendering ( ) and provide faster loading, smoother user experiences, and uses less resources SSR SOA is hard, using async code splitting with is harder, once you overcome the learning curve none of it is very hard SSR SSR Just keep all window op’s out of your code and you’re fine SSR We will cover the core concepts of , how it works with Service Oriented Architecture ( , and the more advanced concepts of using async code splitting with . To begin there will be a small primer on the terminology we will be using. Anyone who is new to needs to have the Isomorphic/Universal talk. For those familiar with the subject, feel free to move right along to the section. SSR SOA) SSR SSR SSR can be hard to grasp initially (I know it was for me), but it provides considerable benefits to your clients. They use less round trips for data, and get more data earlier in the client app loading process. Using async code splitting with lets developers have the best of both and on demand asset loading, but has a reputation of being extremely difficult, and that is true at first. SSR SSR SSR One of the main goals of this writing is to break down the complexities of and async loading into more digestible chunks to take some of the difficulty out of getting into the world and make the subject matter a little less intimidating. SSR SSR Moving right along we have our obligatory Isomorphic/Universal speech as promised. Those familiar with or those who just like to avoid the issue, the good stuff is right after. Enjoy! Isomoprhic/Universal Isomorphic and Universal are both used when describing code that produces the same result when executed in different runtime environments. The terms are also used to describe the processes of executing said code, as well as the composition of code units and entire applications. While incredibly boring, it may be worth it in this case to break out some dictionary definitions. Isomorphic as an adjective isomorphic is defined as: being of identical or similar form, shape, or structure as an adverb the word is modified to isomorphically: In an Isomorphic manner as a noun the word is modified to isomorphism: The state or quality of being Isomorphic Universal as an adjective: of, relating to, or characteristic of all or the whole as a noun: something that may be applied throughout the universe to many things Isomorphic describes kinds of mimicry and different entities forming similar or identical shapes, whereas Universal has an emphasis on sameness and equality of entities. Following the definitions, neither covers all the concepts involved. There are some pieces of code that just are not able to run on every platform, so the definition of universal cannot be applied to all concepts all the time, but Isomorphic fails to acknowledge that some concepts and constructs are truly universal and valid on any platform, so it does not fit all conditions either. The developer community is somewhat split on the issue. Charlie Robbins and Spike Brehm use Isomorphic in their influential writings from the earlier part of the decade. Michale Jackson proposed using just universal to make it easier for people new to the concept. Gert Hengveld splits the difference and proposes Isomorphic when referring to functional aspects and universal when referring to code itself. No guidance will be provided on which is best in this article. There is plenty of evidence that the issue is dependent on context to a large degree, and what developers are comfortable with. Universal JavaScript does sound a bit better than Isomorphic JavaScript. Isomorphic renderer is a bit more pleasing to some than universal renderer. It’s one of those subjects that depends on the person and the day. With all that being said, the remainder of this article will use the term Isomorphic instead of universal. If you prefer, just pretend it says universal when you see Isomorphic. The experience will be roughly the same. In terms of JavaScript Individual statements, functions, and applications can be said to be Isomorphic if they can be executed on both server integrated JavaScript runtime environments and client JavaScript runtime environments without error. For an individual statement to qualify as Isomorphic, it has to be able to execute without error in both client and server JavaScript runtime environments. Example: Isomorphic statement const foo = 10 ; Example: Non Isomorphic statement const jsonpArray = window [“webpackJsonp”]; To qualify as Isomorphic, a function, route, or application does not have to guarantee all branches of execution run without error, but must guarantee at least 1 path will execute without error in a given JavaScript runtime environment. Example: Isomorphic function } }; const extractDataWhenIso = ( someData ) => { if ( typeof window === 'undefined' ) { return null ; return someData; Example: Isomorphic Application Isomorphic JavaScript/applications can be executed using server integrated JavaScript runtime environments, on hosts that are collocated with service hosts and resources for low latency access to data needed for execution. Server Side Rendering (SSR) The rise of gave us sprawling networks of services that provide us any data we could want, and being collocated in the same data centers makes it possible to run data fetch sequences in reasonable time. leverages by applying it to webpage request serving much like service API’s handle data requests. SOA SSR SOA Example: Non SSR SOA Example: SSR SOA Being able to access data collocated in the same data center reduces latency of service and other API calls. Moving low latency data fetches to the server removes multiple page load blocking round trip fetches from a client apps loading flow, allowing partial and full first request page loads. Example: Non SSR SOA timings Example: SSR SOA timings Results from the data rendering pass for a requested route can be used to compute the initial DOM state as it would appear in a client’s browser. DOM management frameworks like React can apply specialized rendering methods called hydration that forego running DOM computation on the client and directly set the entire DOM from the server rendered version embedded in the initial HTTP response. Characteristics has 3 characteristics that remain constant regardless of implementation SSR Server integrated JavaScript runtime environment Data rendering DOM rendering A page can be considered Server Side Rendered if characteristic 1 and either characteristic 2 or 3 are present in a server applications implementation. 1) Server Integrated JavaScript Runtime Environment A server will execute the client JavaScript that will be run for a page being requested, and will obtain the result of the execution for HTML injection. 2) Data Rendering Calls for external data in executing JavaScript are handled by the server integrated JavaScript runtime environment and the results are stored for later use in execution and/or HTML injection. 3) DOM Rendering Execution of client JavaScript on the server for a route will render a DOM representation of the route as it will appear on the client, and the representation will be returned from the renderer for HTML injection. Modes Data and DOM rendering are not mutually exclusive, and by their nature can be used independently of each other, or in unison. Complete Both Data and DOM rendering are used to render a requested routes final DOM representation for HTML injection that embeds the DOM representation into the HTML page that is sent to the client. Example When a user requests a page, the sever renders the requested route as it would be run on the client. Data fetch calls are executed when encountered in the execution path, and a DOM rendering pass is executed which uses the results of the Data rendering pass to initialize and configure persistent storage systems like Redux and/or DOM affecting components. The rendering result is then embedded in the HTML page that is severed to a requesting client. Example: Complete SSR Partial The result of server side JavaScript rendering does not necessarily have to contain both Data and DOM rendering results, and the two modes can be run independently. Data only The result of Data rendering will be used to initialize a data store or component states on the client when configuring the client DOM on HTML request response loading. Example Results of Data rendering for a requested route are used to initialize default state of persistent storage management systems like Redux for later client use in flux systems, or to be accessed directly by the application. Data does not have to be used in the initially rendered path, and may be used latter in the application without incurring any loading penalties by accessing the data embedded in the HTML page. Example: Partial SSR (Data only) DOM only The DOM representation produced as a result of rendering will be used to initialize the DOM on a client when performing HTML request handling. Example Rendering a requested routes DOM representation can be completed without using any Data rendering pass results, or without having done any data rendering at all. Components with static content like help or FAQ pages can be server rendered without having to obtain any external data. Example: Partial SSR (DOM only) Async Route Rendering (ARR) is performed by client applications when an async route is encountered in execution. When encountered, the client will call for the external resources needed to complete rendering of a route. ARR Example: Async page loading In contrast to a implementation, clients do not have direct access to assets. Any data or assets the client needs beyond what is provided in the HTML response for a requested route has to be obtained from an external source, causing clients to block and preventing meaningful user interaction until all needed assets are retrieved. SSR AAR and SSR implementations need to be able to render requested routes with the resources available to them through the server integrated JavaScript runtime environment. While possible, most implementations of server integrated JavaScript runtime environments do not have a window object, having to rely on pollyfills and the runtime environments fetch emulation capabilities, which makes it difficult to load multiple JavaScript files like a client would. SSR capable implementations access all needed resources directly from their local file system, making async characteristics ineffective in implementations. Direct access to resources negates the benefits of and eliminates the need for async resource caching like clients require. SSR SSR Isomorphic Async Rendering (IAR) characteristics are incompatible with the characteristics of due to ’s asynchronous asset loading strategies. performs optimally with all resources directly accessible, is predicated on not having all resources at the time of execution. ARR SSR AAR SSR AAR allows implementation of characteristics inside a implementation using a characteristic called Isomorphic async containment. IAR AAR SSR Isomorphic Async Containment (IAC) To meet the required characteristics of , components need to yield a renderable result at time of execution. When running on a server integrated JavaScript runtime, the renderer result cannot be a promise of an async external resource loading requests resolution, it must be a promise to resolve a concrete resource. SSR AAR The following is a simplified diagram of how to employ in a based client. There is a lot more involved in the full build chain in regard to boilerplate, but to clearly demonstrate the concepts of / the example focuses on the async portions of code. IAC IAR SSR IAC IAR app.js / steps 1 thru 3 are where is employed by leveraging the build tools aliasing capability to keep async commands out of the path. IAC SSR Example: IAR build and run time Build time Build tool starts the build process Standard routes are consumed (async components allowed) SSR safe routes are consumed (no async components allowed). The app consumes the correct routes for the build variant using the build tools import aliasing feature which allows specifying an alternate name to use for import statements that is defined in the build variants configuration. Build tool outputs artifacts intended for direct and indirect client consumption. Build tool outputs artifacts intended for webserver consumption. Artifacts directly consumed by clients are sent to CDN 1) 2a) 2b) 3) 4a) 4b) 5) Run Time Webserver consumes HTML that has been embedded with src loading instructions for all needed artifacts on the CDN Webserver consumes SSR build artifacts to render the client app on the server Client requests yoursite.com Webserver uses request as input for rendering the requested route with the server integrated JavaScript renderer Rendering result is embed in the HTML and returned to the client Client executes the HTML response and requests the client specific build artifacts CDN returns the requested build artifacts Client is fully loaded and usable #) *) 1) 2) 3) 4) 5) 6) The mechanism that allows the client render to match what the sever has rendered despite one set of build artifacts resolving to async loading commands and one resolving to concrete components is JavaScript’s Promise object. The server renders a promise for async components but does not generate any asynchronous loading code, generating resolutions to concrete components instead. The client hydrates the rendered response using the async build artifacts whose promises resolve to an async loading operation. The only condition the clients async version of the app needs to meet for hydration to succeed is a promise that will be resolved is present in both the server rendered result and the async version of the code the client has. What the promise resolves to and how it resolves does not affect hydration parity. Example: Async and SSR routes }); }); // routes.js const AsyncAboutComponent = asyncComponent({ loader : () => import ( './components/about/index' ) < Route path = "/about" component = { AsyncAboutComponent } /> // ssrRoutes.js import About from './components/about/index' ; const AsyncAboutComponent = asyncComponent({ loader : () => Promise .resolve(About) // route usage < Route path = "/about" component = { AsyncAboutComponent } /> When a user requests an async route, the sever does not render the route, and only renders a promise to be resolved in its place. Since the rendered result does not explicitly say what has to result from the promise resolution, hydration succeeds and the client is free to do whatever it likes after hydration without worrying about exactly matching the SSR version of the code. Parting Words First and foremost, thanks to you the reader! I hope everyone got a little something from this and wasn’t bored. I will leave you with some links to materials that were really helpful in learning about and how how to implement an capable sever, as well as resources for async components. SSR SSR Additional Reading Isomorphic/Universal JavaScript : Gert Hengeveld : : Concise opinion piece on the terms Isomorphic and Universal in regards to JavaScript Author Link https://medium.com/@ghengeveld/isomorphism-vs-universal-javascript-4b47fb481beb Overview : Michael Jackson : : Advocates for the use of universal over Isomorphic on the grounds that Author Link https://cdb.reacttraining.com/universal-javascript-4761051b7ae9?gi=f9925180d7cf Overview JavaScript can run on a multitude of platforms besides traditional clients Beginners appeared to understand the concepts of universal JavaScript more easily in training sessions when using the term universal Universal is a more common term and concept than Isomorphic : Spike Brehm : : Rundown of the history of Isomorphic rendering as of 2013. Focuses on Isomorphic as a term form rendering and server architectures. Author Link https://medium.com/airbnb-engineering/isomorphic-javascript-the-future-of-web-apps-10882b7a2ebc#.4nyzv6jea Overview : Charlie Robbins : : Early definition of the JavaScript language itself as Isomorphic (with some notable or exceptions), with focus on the code itself being Isomorphic. Author Link https://blog.nodejitsu.com/scaling-isomorphic-javascript-code/ Overview SSR : Oleg Lebedev : : Implementation of a Go based webserver that uses the Goja JavaScript renderer and a React/Redux based front end. Author Link https://github.com/olebedev/go-starter-kit Overview AAR : Arpy Vanyan : : Great breakdown of a React HOC that facilitates async loading. Author Link https://medium.com/front-end-hacking/loading-components-asynchronously-in-react-app-with-an-hoc-61ca27c4fda7 Overview : Anomaly Innovations : : Another async HOC with a deep look at integration with React Router v4 Author Link https://serverless-stack.com/chapters/code-splitting-in-create-react-app.html Overview IAR : James Gillmore : : react-universal-component is a unified async/ compliant higher order component that provides an out of the box wrapper. To accomplish , react-universal-component uses webpack-flush-chunks to swap out chunks with async calls for their compliant counterparts when executed server side. Author Link https://github.com/faceyspacey/react-universal-component Overview SSR IAR IAR SSR
