Tag Archives: api

API versioning and deployment (a different point of view)

I’m quite new to the backend world so what I’m about to describe to you might be total blasphemy or quite trivial. Either way, I came up with this simple setup after a series of “Because that’s just how you do it” answers that didn’t please me as I’ve got quite a curious nature and nobody managed to satisfy my curiosity.

At work, in order to plunge me into the world of backend developers, I’ve been assigned a simple app. Got my tables, need to setup CRUD apis and so on. At a certain point I release my work for the frontend and mobile devs to test. They came back to me saying: “We need you to add versioning to your apis”. No problem for me, it sounds quite logical after all being able to support an older version whilst releasing a new set of APIs.

So, not being accustomed to the backend developer world and uses, I ask: “How do you guys do that?”. What I got as a response triggered me and made my skin crawl: “Just copy/paste the old code and make new routes for the new version”

I’ll let you guys read that last answer one more time…


Nice. So here I am, a C++ dev trying to get the hang of things in the backend world and these guys are telling me that duplicating code is actually a procedure that’s accepted.. At first I thought they were pulling my leg, but as I kept asking how they intended to deploy this I realized that they weren’t joking at all.

So basically, this is what backend developers do in order to support old apis:

|- v1/
|- myapi.js
|- v2/
|- myapi.js

I don’t know you guys, but that’s ugly as hell to me. I kept on asking “WHY” this procedure and duplication of code was the “common” procedure and I kept on getting a “Because it’s like that” answer.

Well, as a fan of docker that I am, it took me 10 minutes to demonstrate that their method was caveman-like and that I could obtain the same effect without code duplication.

How I did it

Basically what I did was, of course, dockerize my application (that’s basically the first thing I did when I setup the project). So now, I can have different working versions of my code in ready-to-use containers.

Let’s say I have myapp:v1 container and myapp:v2 container. This is already the first step into having tow different API versions. As the names states, v1 has /v1/:apis and v2 has /v2/:apis. Now both the containers in order to run together, need different ports to comunicate on and this is a problem for clients as they don’t want to go chaning their ports when calling my apis. In order to come over this problem I use nginx and the pretty cool feature proxy_pass. You should already know where I’m going here.

With a simple nginx setup I now have my two versions of the API running on the same server in different containers and both talking through port 80 (or whatever port you decide to setup for nginx).

NOTE: of course you’ll need to launch your containers and set them up to use different ports and be available on the system

server {
listen 80;
server_name localhost;

location /v1/ {
proxy_pass http://localhost:3000;

location /v2 {
proxy_pass http://localhost:3001;

This way I have my git repo correctly branched according to the various releases and no code duplication. I find this method to be tidy and simple.

So, how’s that instead of duplicating code to allow legacy apis to live?

Tagged , , , , , ,