I was pretty excited when David Heinemeier Hansson (DHH) announced that the Ruby on Rails web framework that he started 10 years ago would finally be getting the ability to be used to just build an API. While DHH himself is a huge fan of monolithic applications, there has been a huge trend towards having a Rails API backend serving multiple clients such as a single page JavaScript app as well as native mobile apps on iOS and Android. I myself have been building APIs in Rails for the better part of the last year, and am a pretty big fan of doing it this way. However I was always kind of ‘fighting’ the Rails framework, making modifications in order to use it just as an API. It’s really nice that this will just be built in going forward.
Since Rails is open source, anyone in the world can actually go and contribute code, and discuss issues around it. Once I saw the new branch with the code to make it optional to build a new Rails API, I started poking around. I noticed that some core features were missing, particularly around cross origin requests. By default Rails blocks any request coming from a client not hosted on the same domain. While this isn’t a problem for monolithic applications, it is an issue for any application that has different servers for it’s client and it’s API (which is the vast majority of cases when building a Rails API). The result of this is that when you start to make an API call from a client, you get an error, and have to add a few lines of code to your Rails API to make it work.
Having done this a few times, I thought it would be nice if that option was built in, especially since the programmer is already building a new Rails API from scratch. In order to make this happen, I would have to either write the code myself and submit it, or start a discussion around it. I opted to start a discussion, since I wanted to build consensus before spending time actually writing any code. It turns out that was a good idea, because although people agreed with me on principle, they suggested a slightly different way to implement the feature than I had in mind. After that consensus was reached I was going to branch off, implement it, and submit that code for review myself, but someone else actually beat me to the punch! Their code was quickly approved, and is now merged in.
Even though I myself didn’t actually write those few lines of code, just by joining in a discussion I was able to change the trajectory of the Ruby on Rails framework - one of the world’s largest and most important open source projects in the world. Just a few years ago I didn’t even know how to code. Now I have enough experience not only to build a project using Ruby on Rails, but to have strong enough opinions to shape the actual Ruby on Rails codebase itself. It feels really good to have played a (very small) role in helping nudge Rails towards the direction that I wanted. So the next time you build a new Rails API and don’t have to fiddle around with the cross origin request bit, you can have me (and of course a few others) to thank!