There are plenty of different out-of-the-box solutions ready to use as an edge service. Tyk.io, Zuul or Spring Cloud Gateway to name a few. Yet at Allegro we decided to build our own. Reinventing the wheel or filling the functionality gap? During the talk we want to share what are the qualities of different api gateways available out there and why sometimes it is still not enough (or too much).

1. Should I make my own
API Gateway?
Michał Trojanowski
Senior Software Engineer @allegro.pl

2. Who are we
2

3. •SOAP API and REST API
•more than 30k sellers actively using the API
•over 100k req/min on SOAP and ~120k req/min on REST
•REST API used both by 3rd
party integrators and our own
clients
The API
3

4. •development and maintenance of the gateway codebase
and legacy SOAP API
•help design endpoints available to integrators
The API Team
4

5. Origins of our API Gateway

6. Moving from monolith to SOA
6
PHP
Monolith
Java
Service
Java
Service
Kotlin
Service
Node.js
Service

7. • Repose
• zuul
• apigee
• Intel Mashery
• Layer 7 Api Proxy
• IBM API Management
• Software AG
• SOA Api Gateway
• wso2
• s3scale
• api-umbrella
• apigrove
• apiaxle
• mulesoft
• oracle
• web
• hipache
• trapeze
• node-http-proxy
• vulcan
• undertow
• Vert.x
7

8. Feature Analysis
8

9. •API Manager, for publishing a finished product with the
support of documentation, accountability, client
registration, etc.
•API Proxy, providing additional services for your API like
authentication, rate-limiting or payload modification
Feature analysis
9

10. Current solution

11. Allegro Edge service
11
EDGE-SERVER
UNDERTOW
PROXY
ZOOKEEPER
COUCHBASE

12. Allegro Edge service
12
METRICS
HANDLER
OAUTH
HANDLER
PROXY
HANDLER
HTTP
Request
SERVICE
...

13. •4-12 instances, each with 1.5 CPU core and 2GB RAM
•~13.5k requests/second in peaks
•120 ms - average p99 of overhead
Allegro edge service
13

14. Routing

15. Routing
15
● kept in a git repository in json
{
"id": "some-service",
"uri": "service://some-service",
"routes": [
{
"method": "POST",
"path": "/sale/offers/{offerId}",
"accept": "application/vnd.allegro.public.v1+json",
"contentType": "application/vnd.allegro.public.v1+json",
"timeoutMillis": 2000,
"tags": [ "public" ],
"filters": [ {"name": "session-to-oauth2"} ]
}
]
}

16. Security

17. •edge-service checks validity of sent tokens
OAuth and sessions
17
•session support for our own pages - exchange session
cookie for an oauth token

18. •centralised built-in support for CORS and CSRF
•configurable support for sending credentials and exposing
headers:
{
"path": "/sale/offers",
"cors":
{
"allowCredentials": true,
"exposedHeaders": []
}
}
CORS and CSRF
18

19. Automatic documentation

20. Documentation
20
● Swagger UI
● automatic at first, currently
created manually

21. Rate limiting

22. •business need to apply different limits based on client
segment and resource
•based on Couchbase
Rate limiting
22

23. Was it worth it?

24. •yes
Was it worth it?
24
•build in relatively short time
•contains all necessary features
•easily developed

25. And should you build your own solution?

26. ● when you’re custom needs are
not that sophisticated
● it’s faster to start with
● easier to maintain
● when you feel your traffic is too
much for an outsourced solution
● if you want to have total control
over the resources and features
● costs of implementation and
maintenance!
As usual...
26

27. Would we do it again?

28. YES, BUT THIS TIME...
28
using SPRING CLOUD GATEWAY
with Webflux

29. 29
Thanks for attention!
- https://allegro.tech/blog/
- https://www.meetup.com/allegrotech/
- https://www.facebook.com/allegro.tech
- @AllegroTech