Favourite tutorials for developers
A design that initially looks good may not be the best design to easily solve the problems at hand. Too often, our initial assumptions about our API and microservice designs are incorrect as they encounter the real world. So, how can we avoid designing an API that doesn’t meet the needs of our consumers?
I’m often asked which is the better style of API: REST, GraphQL, or gRPC. My answer is always: “I’m not sure. What does your API model say?” At this point, I’m often met with blank stares or given an answer about some database. What I’m really asking is: “What problems does your API solve and why?” Once we understand the needs better through modelling our API, we can then determine what API interaction style(s) are the best fit for your API.
The REST style is particularly suited for synchronous APIs, where requests generally return quickly (less than a few seconds). For operations that take a longer …
In today’s world, users expect applications or websites to be fast, and usually, a latency of around 100 milliseconds is considered reasonable. We can improve the latency of services by avoiding chatty APIs or leveraging materialised views for more expensive queries. However, for some long-running jobs like generating a PDF or performing a complex calculation, there is not much we can do to make them run faster rather than scaling up/out. In this article, I’m going to take a look at two patterns for handling such requests.
by