Dev Log: January 2019
Happy New Year!
Nitro 3 ⚡ #
I’ve sent the first couple of invites to the Nitro 3 private beta. It looks like everything went smoothly - the emails went out, and people were able to sign in and start using Nitro.
A couple of things happened to get Nitro to production: I fixed all the critical bugs, added JS Module support, but also had to build a new component to onboard new users. It ended up being pretty simple - if you have a valid invite code, you can login, and it’ll set some metadata on your user in Auth0. If you try to login to Nitro without having activated your account (and thus having no metadata), it’ll tell you that you don’t have access to the application.
I also added a rudimentary stats page for Admin users, as I decided not to add Google Analytics. At the moment, it’s just a count of the lists, tasks, users, and archived tasks in Nitro, but is still useful. I implemented this properly too - it doesn’t just connect straight to the database, but calls the Nitro API authenticating as a machine.
It’s common in a lot of environments to not have any authentication and simply trust other traffic because it’s coming from the same network. The problem with this approach is that it’s not only hard to audit what is requesting what, but ties you a little bit more into your cloud provider (peering VPCs can be a pain). If you use machine to machine authentication, you don’t need to build a BFF (your private and public APIs are the same) but you can also make requests over a zero trust network. For example, I could run Nitro API as a container on AWS and Account Manager as a serverless function on Azure with no special networking. Auth0 made this really easy to do - you can grant an application access to an API by just flicking a switch and choosing some scopes.
I’ve been using Nitro for months in a test environment - it’s always a good idea to dogfood your own app! However, I didn’t have any production infrastructure deployed. I’ve been using Terraform to provision infrastructure, so deploying to production was as easy as renaming some configuration. I would highly recommend everyone to check out Terraform - you write your infrastructure as code, and it’ll be built out like magic, even over multiple cloud server providers.
Nitro itself is running on AWS, on an ECS Cluster (EC2 launch type) behind a load balancer. The Nitro client is deployed into a S3 bucket, sitting behind Cloudflare. Currently, all the Docker containers are running on a single instance, but I’ll add some auto scaling when I onboard a few more people. Additionally, the database is fully managed by AWS (Postgres RDS), and again, I’m using Auth0 to provide login. This is all aided by Nitro being fully functional while offline, so if there is an outage, it’s unlikely you’ll even notice it 😁.
In terms of what’s next, I’m actually not sure! I’ll definitely be checking out the feedback from the first beta users, as well as onboarding more people. Based off the feedback, I’ll be able to prioritize the most important issues, and go from there!
Waka #
Because I actually managed to run out of things to do on Nitro, I put a little bit of work into Waka. After choosing a line on the lines screen, it’ll show the live vehicle locations if there’s any! It’ll also show the services you can transfer to at each stop. I then removed the existing route map that is visible when you press route map on the stations page - it now sends you to the unified lines page.
This change is live for both Auckland and Wellington, and works for buses and trains!
I’m definitely going to make it better though - here’s a couple of plans for that page:
- Show transfers at transport hubs (e.g Otahuhu, Albany, Kilbirnie)
- Show how long it takes between stations
- A better way to select the route variant (e.g The NX1 can run to either Albany or the Hibiscus Coast, the 1 can run to one of three possible destinations)
And if you’ve jumped in from the station page, or have selected a station:
- Show the live service info
- Show the time that a service yields at each station
Once that work is all done, it should lead into a few other changes. Notably, showing the inactive stops on the station page, and making transport hubs more prominent on the map. There’s also other work where we’re disassembling the Waka monolith (okay, it’s not really a monolith, but we want to split out the data import from the runtime).
That’s all for January. I’m off to take a well needed holiday! ✈
- Previous: Dev Log: December 2018
- Next: Dev Log: Febuary & March 2019