Please get in touch with any bug reports, feature requests and suggestions. I’d be particularly interested in if there is demand for a paid pro/premium version with extra functionality. Or maybe you would like a subscription-based hosted service version (with better uptime than the demo server and email support).
Some ideas that I have in mind are:
- Advanced caching
- In-memory or distributed cache
- Flexible duration configuration
- Tools to manage NRE API quota
- Analytics / counters
- Rate limits
- Multiple client tokens
- GraphQL endpoint
- Request only that data that you need
- Good for React apps
- TfL API integration
- Tube line rainbow board API
- Station live departures API
- Delay repay flags when train exceeds a late threshold (per TOC)
- NRE Knowledge Base API integration
- TOC disruption rainbow board (NSI)
- Service disruptions
- Engineering works
- Multiple stations in a single request
- Container and serverless support
- Pre-built Docker containers
- Support for Azure Functions (or AWS Lambda)
- Full coverage of the staff and reference API surface area
- Alternative client authentication methods
- HTTP basic auth
- JWT bearer token in local storage
- Configurable custom CORS domains
- Restrict access to your web app
- Allow authentication
- A web UI for configuring Huxley settings
- Geographical lookup for CRS codes
- Latitude and longitude or OS grid reference
- SignalR push updates to reducing polling of API
Let me know what you think.
There’s a licensing change for Huxley 2 but this isn’t very significant. Huxley 1 was licensed under the GNU Affero General Public License v3.0 but Huxley 2 is licensed under the European Union Public License 1.2 (or later).
These are broadly the same in what you can do but the EUPL has advantages over the AGPL, such as being shorter and available in 22 languages. The EU does great work.
The EUPL still covers distribution through a network or SaaS (like the AGPL). This means that if you make changes to Huxley and host the result then you must share those changes (even if you don’t distribute the application).
This is a quick guide on how to get Huxley 2 up and running on Microsoft Azure (with a Linux host).
You will need a Darwin API access token(s) / key(s) from National Rail Enquires. You can get a public token here and a staff token here. You can get and use both if you like, for full functionality. They are both GUID strings.
Sign up to GitHub, if you haven’t already got an account.
Fork my Huxley2 repository to create a copy in your own account.
You should then have a copy of the repository in your account.
Do not create a Pull Request, unless you actually have changes to share back to me upstream.
Sign up to Azure if you haven’t already. You can get a free trial but you will need to enter credit card details.
Create a new App Service.
Create a new resource group (or select an existing one) and give the instance a unique name. Select .NET Core 3.1 (LTS) as the stack and Linux as the OS. North Europe (it’s a UN naming thing) is the closest region to the public Darwin servers and has a wide selection of SKUs.
You can select the free SKU but if you want to set it to be always on then you will need something a bit bigger, such as a B1. You may need to create a new service plan.
Confirm everything and wait for the instance provisioning deployment to complete.
If you don’t want to pass your tokens in the query string then you will need to add them as application settings.
Add the tokens with the name as
DarwinStaffAccessToken and the value as your GUID token(s).
If you have both then add them as separate settings.
You can also set
ClientAccessToken if you want to provide a different token in the URL. This can be any string.
There are a few other settings that you can tweak too. Take a look at the
appsettings.json file for more details.
On the general settings tab you can set always on if your SKU supports it. Don’t forget to save the configuration.
Sign up for Azure DevOps if you haven’t already.
Create a new build (multi-stage) pipeline (not release).
Select GitHub YAML.
Authorise Azure Pipelines with GitHub.
Select your fork of Huxley 2.
Approve and install Azure Pipelines for your fork of the Huxley 2 repository.
Follow the wizard and when you get to review your pipeline YAML you will need to make a couple of changes. Find the deployment task entry (the last one) and click settings.
In the sidebar, change the dropdowns for Azure subscription to yours and App Service name to the one you just created.
Click add to apply the change to the code (yes, this is unintuitive).
Finally, click the run button at the top right.
You may need to authorise with GitHub and you’ll need to grant permission for the pipeline run to access your Azure subscription.
If all goes well you should get a green run.
You can now visit the URL of your web app and should see Huxley 2 up and running.
This should be at
https://[your App Service name].azurewebsites.net unless you have set a custom domain.
Get Ready For Actions
You should also see an Azure Pipelines build run tick next to the latest commit on your Huxley 2 GitHub repository. You might be able to use GitHub Actions directly to do the build and release but I’ve not tried it. It shares a lot of code with Azure Pipelines.
Please get in touch with any feedback. I’d be particularly interested in if there is demand for a paid pro/premium version/service with extra functionality.