Contributing to Open Source with Mockservr

When working on software development, developers often need to access remote data using API. Sometimes, it is not convenient to use these APIs during the development process : some of them have a low limit rate, consume credits or don’t have sandbox available for development purpose. Furthermore it may be convenient for a developer to be able to work on his project with no Internet connection. In other words it would be great to be able to access these API from localhost while staying as close as possible to the production environment. Nobody wants to handle its environment directly from within the code. The “ideal” solution is, for the code, to be completely agnostic of the environment it is being executed on.

At Reputation VIP, we aggregate a lot of data from an increasing number of datasources to enrich our softwares or simply to perform further analysis. We fetch these data from a lot of different APIs. Problem is, some of the APIs we are using are pretty expensive and as I said earlier, most of them do not offer sandbox mode. We wanted to be able to mock these APIs ourselves in order to avoid unpleasant surprises. I mean, development process is all about writing draft code, debug, and improve. In such a process, we often run into nasty bugs like infinite loops for example. You wouldn’t like one of these to dry your credits out or even worse: to cost you thousand of euros.

On one hand you have online API mocking systems available nowadays but they require you to have an internet connection to be able to work. Plus, maybe you don’t want them to access your mocks in case of mocking an internal API.

On the other hand you have local mocking systems. Most of them are written in Java, which requires you to have a running JVM on your system. As nowadays’s development stacks are evolving fast, it is hard to find a tool that keep up.

So we decided to start building our own mocking tool, which would fit perfectly into our stack : light, easily configurable but powerful and packaged into a docker image.

Using node, we built a server that would receive HTTP requests and send tailored responses defined is some YAML or JSON configuration files. From there, our needs became more and more precise. We needed to forge the response accordingly to the data from the request so we included an Apache Velocity template parser. We also needed to be able to emulate API rate limits, responses delays and so on…

Packaged under a Docker image available from Dockerhub, it is easy to integrate it in any of our dockerized development stacks.

That’s how Mockservr was born.

A quick example

One of the software we developed needs to access currency change rates. There are number of APIs that give you these informations. We decided to go with Fixer.io because it was free and met our needs. Problem is calls are not unlimited and using this API during the development process could actually cause issues with the production environment, where the deployed version of the software needs to access the API.

Fixer.io API can be reached through a simple HTTP request, as follows:

GET https://data.fixer.io/api/latest
{
"base": "USD",
"date": "2018–02–13",
"rates": {
"EUR": 0.806942,

}
}

As Mockservr was already integrated in our development stack it was easy to add a JSON configuration file that would allow us to emulate the Fixer.io API from within our development environment. A simple JSON configuration file was enough to mock Fixer.io, specifying the endpoint is available on /fixer/latest and that the response was contained in another dedicated JSON file.

$> cat fixer.mock.json
{
"http": [
{
"request": "/fixer/latest",
"response": {
"status": 200,
"body": {
"type": "file",
"value": "./latest.json"
},
"headers": {
"Content-Type": "application/json; charset=utf-8"
}
}
}
]
}

Inside this JSON file we simply mocked the response of Fixer.io. Our development process does not need fresh data so the following JSON file perfectly does the job.

$> cat latest.json
{
"base": "USD",
"date": "2018-06-18",
"rates": {
"EUR": 0.806942
}
}

As from then we just needed to replace the real Fixer.io API’s URL with the address of Mockservr in the Docker network and we were good to go. Since we always configure the address of external services as environment variables, we didn’t make any change in the software’s code.

GET http://mockservr:80/fixer/latest
{
"base": "USD",
"date": "2018–02–13",
"rates": {
"EUR": 0.806942
}
}

What’s next for us?

We are planing to add many features in the future such as Websocket support, API recorder and a browsable GUI to manage the mocks even more easily or monitor their usage.

With the release of Mockservr, we hope to humbly contribute to the Open Source world.

Like what you read? Give Nicolas Couet (Tejerka) a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.