If you run any web service always enable support for serving compressed responses. It will save egress bandwidth costs for you. And, more importantly, for your users. Over time, the servers as well as client devices have become more powerful, so, compressing/decompressing data on the fly is cheap.
Every public-facing API service should have API usage limits. If this seems overkill then ask yourself if would it be OK if a single IP sends a million requests a second. This does not apply just to publicly documented services but even to undocumented services that are publicly accessible.
Data Loaders allow transparent batching of requests to a data provider (e.g. database). More often than not, this leads to reduced latency and better performance without forcing an explicit batching of requests for the API users, for example, your frontend developers. Many programmers relate data loaders to Graph QL for N+1 query patterns. I believe data loaders are a great idea any time you are building an API backend. Let me illustrate the concept with a simple example. And while I am using Go as an example, data loader implementations are available in many languages.
Writing tests at an early-stage startup is always heatedly debated. If a function has one call, adding a unit test doubles the number of calls, this not only doubles the current work but even slows down future code changes 2X! Further, if the code is not finalized, it is legitimate to ask why even bother writing test code. Here鈥檚 a better way to write tests
RPC calls allow one service to call functions in another service as if it is a part of the same service. And unlike a REST API, one gets strong type checking. The two services can even be in different languages. gRPC is a great framework for implementing an RPC service. Another language-agnostic framework for making RPC calls is GraphQL. Many people don鈥檛 think of GraphQL that way, however, it can serve the same purpose. ...