A microservices-based software system requires applications to talk to each other using an inter-process communication mechanism. gRPC is a modern inter-process communication system that is scalable and more efficient than the traditional RESTful services.
Handling errors can be hard and it’s even harder if your application consists of many microservices exposing a mixture of REST and RPC APIs. The consumer of your API needs a consistent experience of error handling. In this article, we will see how to develop error handling, which works across RESTFul APIs and gRPC API.
Getting errors right can be tricky and it can be even trickier in gRPC. The current version of gRPC only has limited built-in error handling based on simple status codes and metadata. In this article, we will see what are limitations of gRPC error handling and how to overcome that
An API Gateway or Backend for frontend (BFF) is an important design pattern for building applications based on microservices architecture. This reduces chattiness between clients and services by aggregating multiple requests into a single request. We can build specialized BFF services(s) to handle different interfaces for browser and mobile applications. The API Gateway can also be used to offload cross-cutting concerns such as authentication, authorization, rate limiting to a proxy.
Stream operations can be either intermediate or terminal. An intermediate operation produces another stream. Likewise, a terminal operation produces a result or side-effect.
Streams let us do computation on the collection of data in a declarative way, (rather than specifying how to do, we specify what to do). To perform a computation, stream operations are composed into a stream pipeline. A stream pipeline consists of a source, zero or more intermediate operations, and a terminal operation. Streams are lazy; computation on the source data is only performed when the terminal operation is initiated.