ft-next-router

Next-Router

A router for Next ft.com that proxies requests that have missed the Fastly cache and sends them on to the relevent app as defined in our service registry. All systems accessed with the subdomain www.ft.com will have been handled via the Next Router (read more about this design in What happens when you visit FT.com?).

Requirements

• Runtime and version of Node.js is as per the package.json engines.node value.
• Access to Doppler, its CLI installed and logged in (see its Tech Hub page for more info).

https://local.ft.com:5050

For local development of these systems, we run a local version of the next-router to access our local version of our system. This simulates the request that our readers will have made to reach the system. We also setup a new hostname (local.ft.com) to alias our environment's localhost IP. This gives us some added benefits:

• Your local system will get requests almost* like in production, reducing architectural bugs
  • *the local environment only simulates production versions of next-router and next-preflight, not ft.com-cdn
• The hostname allows us to use the same cookie values as production, such as the session cookie
• We can run multiple local systems behind our local router to be accessible via the same domain

Setup HTTPS (SSL Certificate) for local development

The easiest way to setup an SSL certificate – which will let you access the next router via HTTPS – is to run a system that uses the @dotcom-tool-kit/next-router package (such as next-article). This will run an executable to generate a self-signed certificate and add it to your environment. You can also clone this repo and start the executable directly by running ./scripts/generateCerts.sh.

Setup local.ft.com hostname

Add this line to your /etc/hosts if you want to share your cookies across domains:

127.0.0.1   local.ft.com

The router will then be available on https://local.ft.com:5050.

Setup for Tool Kit

Install the @dotcom-tool-kit/next-router plugin.

Development

Running locally

Do something like:

npm start

this will proxy your request to the correct service version, e.g.,

curl -i -A 'iPhone 5' localhost:5050/badger
curl -i -A 'Nexus 4' localhost:5050/badger

Running multiple local systems

To run multiple systems behind the router, ensure each system has @dotcom-tool-kit/next-router installed and run the system's start script. For example:

cd next-stream-page
npm start
cd ../next-article
npm start

This will put the local versions of next-stream-page and next-article behind the next router.

About

This is a router for the Next FT platform.

The project is comprised of Services.

Services represent an application with a specific purpose in the context of ft.com. For example, there's a service that renders articles and another that renders the front page.

The job of the router is to route incoming requests that match the pattern of an article to our service, Eg.

	$ curl -i http://www.ft.com/4d3e8748-26b6-11e4-8df5-00144feabdc0

Essentially, the router sits in between the CDN and our presentational services, directing traffic to the correct application.

The router is written in Node.js and uses http-proxy.

By default, the timeout on the proxied requests is 5 seconds but this can be over written on each service configuration in the Next Service Registry

Why?

We want to avoid creating a monolithic application where all requests for ft.com are sent from a load balancer to a single, ever-growing application.

ft.com comprises several presentational services working in tandem to provide a set of features and products. We need to be able to intelligently route between them.

An architecture based around several small, modular applications allows for low-risk experimentation and prototyping as part of the normal, day-to-day production release cycle - the router, in effect, controls the exposure to these services depending on where they are at in their development life-cycle.

Releasing

next-router follows the canary release pattern, i.e. it deploys to an app which receives a small portion of production traffic. Once it's verified as OK it can be deployed to the full production app.

Workflow

• Once you're happy with your branch merge to main
• This will trigger a deploy to ft-next-router-canary.herokuapp.com in the EU region
• We'll receive a notfication in the #ft-next-support Slack channel, and the Dotcom Support team will probably bug you to keep track of the release
• Once deployed, the CDN will start to route traffic to the app (about 5%, but the exact figure may change)
• While a canary app is up all builds will fail
• Monitor the canary app for at least an hour:
  • Compare metrics with the production app on Grafana
  • Check Sentry and Splunk for errors
  • Navigate FT.com with your journey routed via the canary app by setting in your browser a Router-Canary header (with any value, e.g. 1), which can be achieved with a tool such as the FT Headers Chrome extension
  • For troubleshooting information and tips see RUNBOOK.md
• If there are issues with the release, scale down the canary app and revert the changes in main. This will create another canary release for the reverted change, which should be immediately deployed to production
• If everything's okay with it, release to production by approving the CircleCI workflow for this release. In the workflow the waiting-for-approval will be paused. Click on it, then click Approve