I’m pleased to announce the launch of BikeTheT, a serverless transit API which helps Bostonians figure out whether they can bring their bike with them on the MBTA. BikeTheT was built using Azure Functions, and is available on the RapidAPI marketplace. The code is MIT-licensed, and you can check it out, or fork it, at https://github.com/shaisachs/BikeTheT/.

Brining a bike on a train in Boston can be a little tricky, because the MBTA’s bike policies are a bit complicated. While regular bicycling commuters probably know the policies well enough, casual cyclists need a bit more help. BikeTheT helps bridge that gap, allowing anyone to instantly determine whether they can bring a bike with them on their next subway or commuter rail ride. It’s built so that existing MBTA apps can start using it right away. It would be quite easy, for example, to use BikeTheT to determine which trips allow bicycles, and to display a suitable icon in an app’s UI.

The BikeTheT API is not rocket science; translating the MBTA’s policies into working code is quite straightforward. The most challenging part of the project was actually going through the list of commuter rail schedules, and putting together a cohesive list of the train lines that allow bicycles. Though it probably wouldn’t be too difficult to write a script that would scrape the relevant web pages, I instead went through each of the schedules by hand - there aren’t really enough commuter rail schedules to make a scraping script worth the effort. Of course, because the main logic here is so easy to implement, there’s nothing stopping an app developer from adapting this code into an app’s native code base, instead of calling the BikeTheT API. That’s all to the good, and in fact I’d welcome that - it would inevitably be a nicer experience for the end-user anyway.

The real goal of this project, for me anyway, was to get my feet wet with Azure Functions, and to integrate a Function with the RapidAPI marketplace.

I manage APIs all day at work, but they are all built on .NET’s Web.Api framework - I haven’t really had a chance to play around with Azure Functions before this project. As far as that goes, it was a relatively easy process. Using Visual Studio 2017 and the Azure development workload got me off to the races in terms of a local development environment. There were a handful of minor gotchas, but nothing too serious. For example, I would have liked to develop these Functions using Visual Studio Code on a Mac, but alas - there are no tools for local development on a Mac. By default, Azure Functions serialize their output as XML, meaning that there’s some annoying glue code needed to provide output as camel-cased JSON. And the OpenAPI generator that comes built-in with Azure Functions really only gives you a very skeletal starting file; it doesn’t make any effort to read the input or output parameters of your Function and convert those into suitable parameter and response definitions in OpenAPI. It’s also targeted at OpenAPI 2.0; hopefully it’ll be updated soon, since OpenAPI 3.0 has been out for several months now.

Integrating with RapidAPI proved to be relatively easy and painless, I’m happy to say. Once I got my OpenAPI file ready to go, it was quite easy to launch a new entry in the marketplace, and to have most of the relevant documentation automatically imported into my app’s profile. RapidAPI uses HTTP headers for basic authentication, and so I had to develop a simple little service in my code that would read the header and kick out any requests which didn’t provide the appropriate header value. That also meant that I had to circumvent the default Azure Functions authentication mechanism, and to allow both functions to authenticate anonymously through the Functions framework. The result, I hope, is a nice, simple piece of code that can be reused by anyone wishing to integrate an Azure Function with the RapidAPI marketplace - I’d certainly love to hear feedback on it!

I really enjoyed this project; it was a great way to play around with some new tools. More than that, it allowed me to explore the concept of “Policy as an API” - that is, the translation of a human-written policy into a machine-readable API. In this case the policy was simple enough that building an API around it was almost overkill - but it certainly provides a nice framework for providing APIs for other, more complicated policies. And, I hope, the API might actually come in useful for app developers hoping to provide support for cyclists within their apps.

Image courtesy of ArtsyBee