At Moonpig we are passionate about using Open Source software, and recently we’ve decided it’s time we started giving back to the community. Over the coming months, we hope to open source much more software from the Moonpig development team.
The story of developing an open source API gateway…
Many tech teams are choosing to use service oriented architectures or micro-services. This leads to numerous services and these can be written in any technology, exposing different types of APIs with varying requirements.
If you expose these APIs publicly, your clients are going to need to know how to talk to each one specifically and may need to handle various nuances. For example, service A might return XML while service B returns JSON. Service A has a lovely API, but service B isn’t quite so nice to use.
In addition to this, each service is likely to have to implement various cross cutting features such as authentication, authorisation or caching.
An API gateway presents a unified point of entry into your services which can implement cross cutting features in one place.
API Gateway Architecture
There are already plenty of API gateway products out there. The big cloud player is Amazon’s API gateway; Microsoft also have a product in Azure. In the Open Source world, Tyk and Kong seem to be popular choices. There are many enterprise products such as CA’s – formerly known as Layer7. Yet another popular option in the .NET world is simply to build your own service, expose it publicly and add new endpoints as and when you need them.
At Moonpig we have our own service that is exposed publicly using Micrsoft’s Azure platform. Unfortunately, we have two API gateways! Like many high-growth start-ups from the early 2000’s, we have inherited a legacy architecture that we are continually working to improve. One key aim of re-architecting is to have a unified point of entry into our system from the outside world.
I was looking for a project to sink my teeth into and thought I would try writing an Open Source API gateway in .NET core. Initially I didn’t think much would come of it. I started writing some “must have” features and publishing a NuGet package. I kept a readme up to date in case anyone did stumble upon the project. Lo and behold, a few months after I started I was contact by a contributor on GitHub who expressed interest and started raising issues.
Shortly after, a Moonpig colleague also started contributing. He has since done all the work to get a good quality build pipeline in place using Cake, GitVersion, AppVeyor, Coveralls and Codescene. Having taken a lean approach, we initially focused on getting something working. The priority now is to clean up the early hacky code, while also starting to add new features that the community are requesting.
At the time of writing Ocelot supports the following features:
- A user can specify a map between an upstream request and forward this to a different URL on the downstream service.
- Service Discovery
- Ocelot can look at your service discovery and find the services it should be forwarding downstream requests to. It can then load balance across these services.
- Authentication using IdentityServer
- You can mark endpoints as authenticated and use IdentityServer bearer tokens to authenticate you users.
- Authorisation using Claims
- If using bearer tokens, you can use the claims on them to mark specific endpoints as authorised
- Claims Transformation
- Ocelot provides a syntax to transform the downstream request and add claim data to headers, URL parameters, other claims and more!
- Quality of service
- Retries, circuit breaker, timeouts etc.
- Request / Correlation Ids
- Custom Middleware
I am hoping we’ll be ready to start using Ocelot at Moonpig after .NET Standard 2.0 is released. We’ll need a few of those features to use .NET core projects at work!
Check out our work at https://github.com/TomPallister/Ocelot
I’m the guy in the Moose outfit…