Skip to main content

Server side versioning

Background​

Practically, when we deploy the client build, all static assets' filename must have a hash. This is for not only the long-term caching purpose but also the version travelling. It means you can revisit previous or preview upcoming build anytime without a second deployment. When there is a live site issue, you can rollback your PROD build instantly by invalidating the static path such as index.html in the CDN cache. We can apply the same strategy into the server build and think about node.js is a browser. Then you do not need to restart the server on each deployment if node.js version does not change.

Prerequisite​

  • Must not use any singleton pattern
    • For example, the store on server side is instantiated once and shared with different requests. You may leak some sensitive information to other request.
    • To identify it, you can think about if there is a variable which is created once AND shared AND lives until the application exit.
    • Each request should go through all the variable creation progress.
    • Make the good use of React Context to store global things on each incoming request.
  • Must not have externals: [nodeExternals()] in webpack.config.js
    • node.js can require the new server build on the fly without a restart.
    • This allows node.js to run two versions of server build which depends on a package in different major versions at the same time.
  • web-framework-related logic and application logic need to separate from each other.
    • web framework logic includes
      • expressjs, polka
      • Parse and convert request parameters e.g. query string, request headers, cookies... to a plain object
      • Call and pass the plain object to server entry
      • Reponse HTML from the entry execution result
    • app logic includes
      • Data fetching
      • Store initialization
      • renderToStaticMarkup and renderToString
      • Define <head> and <body>