Skip to content

Instantly share code, notes, and snippets.

@DavidBruant

DavidBruant/url-application-engineering.md

Created February 12, 2016 10:33
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save DavidBruant/5d7d92517fd128fe8748 to your computer and use it in GitHub Desktop.
Save DavidBruant/5d7d92517fd128fe8748 to your computer and use it in GitHub Desktop.
Download ZIP
URL application engineering
Raw
url-application-engineering.md

Isomorphic application engineering and URLs in Node.js

A good web application will make good use of URLs and browser history. This allows users to bookmark, use their browser history, etc. However, there are a number of considerations to have in mind when trying to have good URLs

Constraints

  • Good URLs
    • Different objects should have different URLs. The level of granularity is left to the application creator
  • Consistency after a refresh
    • If a user navigate the application and hits refresh, they should see what they left or close enough
  • Performance
    • Before the Single-Page Application movement, going to a new URL meant a page refresh and a network round-trip to the server. This cannot be acceptable for a good UX.
  • Maintainability
    • It should be easy to make a change and have that change reflected on what's generated both on the client and server-side.

Problems and tools

Isomorphic UI components: React

The same React components can be used both on the client and server-side.

This helps with the maintainability concern.

Server-side rendering

From 3 to 1 round-trip to first render

Single-Page Applications have had an habit of sending an empty <body/>. The browser downloads some JS after the HTML has arrived, this JS downloads data when it's in the browser and is only then able to render what the user wants. It usually takes 3 network round-trips before something is displayed on the screen. Latency is terrible for UX and inevitable but should be reduced to a minimum. Rendering server-side helps a lot as it allows for something to be rendered after the first round-trip.

Interactivity

The minor downside is that the page is at first static and not really interactive beyond default browser interactions (scroll, hover, copy/paste). Interaction is possible when the JavaScript is downloaded and React can re-render the same page (this is optimized by React and is usually close enough to a free operation).

However, rendering also requires the data (React's props). 2 options are possible:

  1. Do an XHR to get the data
    • con: one additional round-trip before the page is interactive
  2. Embed the data in an inert element <script type="application/json" id="init-data"></script> at the end of the <body> so it's available after the first round-trip
    • con: the data is sent twice (once in the rendered HTML, twice in the inert element), but this might be mitigated by gzipping which will hopefully notice the repetition and optimize away the biggest duplicates (long strings, etc.). (Proper benchmarking and research should be done to assess how much this is true.)

Routing

Server-side : express

Express is cool for routing. It offers lots of handy middlewares (body parser, compression, session, etc.)

Client-side : (not chosen yet)

  • page.js. It has an express-like API and does the job fine.
  • react-router. Seems to integrate well with React.

Isomorphic routing

For now, on both side, we must each time:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment