How to safely throttle high traffic APIs and work with API gateways

#todayilearned #api

TL;DR notes from articles I read today.

Adopting a scalable language and framework can help spread the traffic across multiple endpoints and systems, spreading the load across a wider structure.
Rate limiting is among the most common ways to managing API traffic and may be implemented by Dynamic Limits (staying within a range of requests), Server Rate Limits (limits on servers) or Regional Data Limits (restrictions based on heuristics and baseline analysis).
Build a backend for your frontend (BFF), i.e. break each element of your API into additional functions that are then accessed via facade APIs, turning your traffic from single to multiple sources.
API gateways are a proven, time-tested methodology for managing API traffic. API gateways can interact with microservices to bring many of the same functions and benefits of the BFF structure.

Full post here, 9 mins read

Some of the most common cross-cutting concerns in applications include authentication, authorization, sessions, cookies, cache, logging and dependencies on other services.
Authentication is best handled by a service that produces either a JSON web token or some other auth token which can be included in subsequent requests. Authorisation should be possible using a token too and should be performed before a request is proxied through to any microservice.
Cookies are best avoided by your microservices. If needed, they are easier and cleaner to implement in the gateway.
When it comes to caching, start with small expiration times. Maintaining REST-friendly routes will allow for simpler caching at higher levels.
Use log aggregation for logging.
Each microservice should be as independent as possible, and should not risk cascading failures because one service outage triggers another. Thinking about how the gateway will interface with its microservices is crucial to its robustness

Full post here, 10 mins read

When building an API gateway using a microservices pattern that runs on Kubernetes, you must think about scaling the management of hundreds of services and their associated APIs and ensuring the gateway can support a broad range of microservice architectures, protocols and configurations across all layers of the edge stack.
The challenges of managing the edge increase with the number of microservices deployed, which also means an increased number of releases, so it is best that you avoid a centralized approach to operations and let each team manage their services independent of other teams’ schedules.
Encourage a diversity of implementations for consolidated tooling that supports architectural flexibility. However, take advantage of a consolidated underlying platform and offer a ‘buffet’ of implementation options rather than allowing developers to build bespoke ones for better security. This is a more manageable and scaleable approach too.

Full post here, 5 mins read

DEV Community