ft-next-router v3.0.0

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.

Requirements

• Runtime and version of Node.js is as per the package.json engines.node value.
• Access to FT Vault (see Getting Started With Vault) and to be logged in.

Setup local app to run via next-router

Running an app locally via next-router will mean your requests follow a similar journey to a request on production. This mean all GET requests will get decorated via preflight with headers for things like flags and session data. This is optional for some apps as they are self contained and do not require external services.

Setup for Tool Kit

Install the @dotcom-tool-kit/next-router plugin (more details to come in CPP-870).

Setup for n-gage

The router needs to be installed on you system when it is used with an application using n-gage. Clone this repo then run the following commands:

Before running make install, install Vault so that the .env file is correctly populated.

	cd next-router
	make install
	make .env
	npm link

If the npm fails, do not put sudo in front of it. Follow these instructions and fix your computer properly!

To verify everything is working:

	make test

Volta + n-gage

There has been some issues linking the next-router with your application that managed its' node version with Volta on local environments. If you are coming across this issue, you may need to manually link the next-router with your application by running npm link ft-next-router.

Development

Running locally

Do something like,

	make run

Then this will proxy your request to the correct service version, Eg

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

Running over HTTPS

To run the router over https,

	make run-https

To fix the browser security issues associated with using a self-signed cert, it will be added to your keychain (OS X) on first time of running.

• If you are on OSX, you should now get prompted for your keychain password, and the key will be added for you, with the correct trust settings.
• Open https://local.ft.com:5050 (if you haven't already set up local.ft.com see Localhost below for instructions) and revel in the fact the little padlock is all green and happy

If the key is not added to the keychain, this is how to do it manually:

• Open the Keychain Access app
• Select the System section in the left-hand Keychains panel
• Drag the generated cert file into the Keychain Access application from your local next-router code folder
• Double-click on the newly added cert (name will be *.ft.com)
• Expand the Trust section
• Change the Secure Sockets Layer (SSL) dropdown to Always Trust
• Close the cert and enter your password to save

Localhost

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 be available on https://local.ft.com:5050.

Running multiple local apps

Next Heroku Tools allows you to run multiple local apps through the router.

First, start up the apps on separate ports using --local. For example:

$ cd ~/next-product
$ PORT=3000 npx nht run --local
$ cd ~/next-article
$ PORT=3001 npx nht run --local

Then, start the router with --local-apps, specifying the apps and their ports (note that the next- prefix should be omitted):

$ cd ~/next-router
$ npx nht run --https --local-apps product=3000,article=3001

Now, you should be able to access both these local apps on the host https://local.ft.com:5050.

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