There are hundreds of pre-built solutions for everything API, whether it’s authorization, documentation, or some other functionality. While there’s a wide range of choices for your API gateway solutions — especially in recent years — the very best ones can cost quite a chunk and aren’t always tailored to your needs.

This was what the API team from Allegro, Poland’s largest online shopping platform, discovered when they went on the hunt for a gateway package back in 2014. With over six million active users and about one million products sold every day, they needed a gateway that wouldn’t cost the earth. Senior Software Developer Michał Trojanowski told us more about their gateway requirements and the decision to build one themselves at our 2018 Platform Summit.

Watch Michał Trojanowski present at the Nordic APIs Platform Summit:

Allegro and Their APIs

To give some quick context, Allegro’s online shopping platform revolves around a simple, sleek marketplace, although they also host auctions and, since 2015, have maintained a retail branch. With 700 people in IT, Allegro is most certainly a tech company.

But onto the APIs! It was clear that Allegro needed an API for sellers, so they built one. In fact, they built two: an older, legacy SOAP API and a more recent REST API. Between the two, there are around 30,000 sellers using the APIs themselves, with each API logging over 100,000+ requests per minute during peak times.

While there are third parties using both APIs, Allegro’s internal development team uses just the REST API for all the data they need, which is especially important in the front end, including their mobile apps.

Michał’s development team has two main purposes, he says. The first is to develop and maintain the gateway codebase for their APIs, and the second is to aid other developers — internal or external — by designing the models, paths, and endpoints they need to extract valuable data from the back end.

The Need for a Gateway (2014)

Back in 2014, Allegro made the decision to switch from a PHP monolith to a Service-Oriented Architecture (SOA), with microservices programmed in a mixture of Java, Kotlin, and Node.js. This opened up the need for an API gateway — we explain why in our article API Gateways to Direct Microservices Architecture.

So, in January 2014, they took a look through what the market had to offer for pre-built API gateway solutions. Having compiled a list of nearly every option, they then made a list of necessary features including both the functionality they needed from day one, and the functionality they’d want to add further down the road.

One extremely important feature was support for their existing, in-house service discovery. Unfortunately, they couldn’t find a solution offering this.

They came to the conclusion that pre-built gateway solutions fell into two broad groups: API managers and API proxies. API managers were business-focused gateway solutions, that would publish existing APIs with documentation support, client accountability, and registration features. API proxies were the tech-focused solutions, which would include authorization, rate limiting, and payload modification features.

There wasn’t really anything in between the two available for free — especially not with support for their service discovery — and they were hesitant to go for a paid solution given the huge traffic they were dealing with.

Do It Yourself!

Since there weren’t many alternatives, Allegro made the decision to build an API gateway in-house. Their DIY solution, Allegro Edge, used an Undertow proxy with Zookeeper to handle the config and Couchbase for rate limiting.

The basic design was a chain of Undertow handlers, each with a specific purpose — such as handling sessions or collecting metrics — that would eventually pass the request onto a proxy handler and to the service itself. Response listeners could add headers, collect some last metrics, or modify the final response.

Four years later, Allegro is still satisfied with their solution. They’ve found there’s an average overhead of about 120 milliseconds (99th percentile) through the entire architecture. Michał acknowledges this isn’t the greatest, but it’s more than enough for a marketplace where latency doesn’t really matter and resources do.

Allegro Edge Features

While the Allegro Edge service sounds effective on paper, what it is really taking care of? Here are some of the most important features they’ve implemented, with insights on how you could do the same:

Routing

For routing, Allegro took the simple approach of outlining all routes in JSON in a regular git repository. They found this was an easy way to expose new resources, and also offered them transparent control over what was being exposed. If you offered a resource for third party users, you’d simply tag it as public.

Security

In terms of security, Allegro Edge handles validity checks of OAuth authorization tokens for the integrators. There’s no need to worry about expiration or signatures. Similarly, there was centralized support for CORS and CSRF to take security into their own hands. Also, the service offers built-in session support for the website’s own pages: session cookies would be converted straight into tokens.

Documentation

For docs, Allegro chose Swagger UI. At first, everything was automatic: exposing a public endpoint would create a YAML specification file, which would be collected into one big support page. Eventually, developers started adding models with the wrong names, which resulted in a minor docs mix-up. Now, they use manually edited docs files.

Rate Limiting

The last big concern to handle was rate limiting. Using Couchbase, they built two rate-limiting mechanisms from technical and business perspectives. The first would limit requests based on IPs, which was effectively an anti-DDoS precaution, while the second would limit requests based on resources, allowing only verified or VIP users greater access to the resources.

Was It Worth Building an In-House Gateway?

The question you’re probably wondering is whether it was worth building the Allegro API gateway in-house. In a word, Michał says yes. The big reasons are:

  • It works.
  • It was built from the ground up in three months.
  • It offers all the necessary features.
  • It won’t be a struggle to build on.

Should You Build Your Own?

Having discussed the Allegro API gateway, Michał was kind enough to answer more of the obvious questions before they were asked, including Should You Build Your Own?

As usual, it depends. If you have no custom needs, it might be easier to use what’s available on the market (especially if you need to build a gateway quickly). Also, existing solutions can be easier to maintain, regardless of whether they are paid — which often means free support — or open source — which often means a passionate community.

If you think you have high traffic numbers or, indeed, custom needs, it might be easier to build one. It’s not exactly difficult, but Michał says the ongoing maintenance is a necessity and still needs to be paid for by someone.

And in case you’re walking away from this post with the hopes of building your own gateway, the enthusiastic developer added that if he did it again, he’d probably use a Spring Cloud gateway with WebFlux.

Thomas Bush

About Thomas Bush

Thomas Bush is an enthusiastic freelance writer from the United Kingdom, who loves breaking down tough topics into bite-sized articles. Covering everything from cryptocurrencies to medicine, and now APIs, you can find out more about Thomas on LinkedIn or on his website at http://thomasbush.co.