Tube status

[joshvince]

This creates a whole bunch of functionality and scaffolding:

• Creates an interface with Amazon's DynamoDB (currently hardcoded to be running locally to avoid any charges)
• Creates a basic version of a task to blow away the local dev DB then initialise it again with a first record to allow you to start again (npm run reset-db)
• Creates a fake TFL server for the main app to call, to allow for flexible development, giving the ability to create delays on cue etc (it's set by an env. variable)

And, in terms of getting actual Tube Statuses:

• Visit /lines/northern endpoint.
• The app will call the TFL API to get the status of the Northern Line
• The response will be parsed until it ends up with just the StatusSeverityCode
• The app will retrieve the relevant entry in the DB and will update a scoreArray value in the record like this: 1: Add the latest status code to the front of the array 2: Remove the last (oldest) entry in the array if there's already 12 entries

The scoreArray is currently returned to the client. In the next round, the app will call the TFL api and update the internal DB at regular intervals (every 5 mins). Then, when the client calls the /lines/northern endpoint, the client will receive a "Score", which will be some jiggery pokery maths to do with whether there has been any delays on the line in the last hour (12 entries in the array, remember).

[joshvince]

OK, this is updated:

Every 5 minutes, this app calls the TFL API and requests the status of the northern line.

When the client hits the /lines/northern endpoint, the app returns a "score", which is calculated with some simple maths that treats delays/closure responses from TFL as high/bad and good service responses from TFL as low/good. The score can be considered a rough guide as to how the line has performed in the last hour.

This is ready for the front end work to begin now. I'll do that in another branch.