In this topic

• WebSocket🌱Seedling
• API Authentication🌿Growing

  Maybe not straight user ID in api. Jwt json web token contains signed json data about the user, like what role they have. Every request contains a signature that the server can…

• REST vs GraphQL🌿Growing

  When is GraphQL is a good idea? When flexibility of what data to retrieve is important, but it is possibly rarely worth the overhead.

• API retries🌿Growing

  Good to handle the odd error. Beware of overloading already failing services with even more load. API Circuit breakers will help.

• API Circuit breakers🌿Growing

  Failing fast is better than failing slow. Circuit breakers allows not calling services that are broken so that they're not overloaded. Half open allows letting a few requests through to see if…

• API short vs long timeouts🌿Growing

  Set long timeouts intentionally, services should be fast, unless it is purposefully (can't do otherwise) slow.

• REST framework🌿Growing

  REST favours plural nouns. Use path parameters for mandatory parameters, and use query parameters for optional ones. Rest is good for public facing Apis, easy to reason about. Http for external is…

• RPC methods🌿Growing

  RPC tends to be more for internal service communication. REST has a bit more overhead with http. Rpc tends to use more efficient formats like protobuf and grpc rather than http. This…

• API Rate limiting🌿Growing

  Django rate limiter? In memory per server. You don't get a global picture tho. Or separate service but extra latency. Most common is to have it with the api gateway. Rate limiting…

• Idempotency key🌿Growing

  Client generates an ID to send to the server that is unique when making operations. In case of failures or retries, this ensures operations on the server side are done only once.

• GraphQL🌿Growing

  This is good for when clients need to choose which fields to use and make complex joins in 1 query. With graphql, it's easy to introduce the n+1 query problem where you…