gRPC
Source: https://grpc.io/docs/what-is-grpc/introduction/
In gRPC, a client application can directly call a method on a server application on a different machine as if it were a local object, making it easier for you to create distributed applications and services. As in many RPC systems, gRPC is based around the idea of defining a service, specifying the methods that can be called remotely with their parameters and return types. On the server side, the server implements this interface and runs a gRPC server to handle client calls. On the client side, the client has a stub (referred to as just a client in some languages) that provides the same methods as the server.
gRPC is commonly used for service-to-service communication.
GRPC should be a replacement of your REST API and other synchronous forms of communication be it from a client (grpc-web) or backend-to-backend communication (just grpc).
In a sufficiently complex application you’ll always find the need for asynchronous communication for myriad reason, the most common likely being “holy shit we have to make 100 API calls when this action happens so we can notify everyone and their mom someone signed in”. This is where you’d use mqtt or pub-sub or kafka to publish a message/event and then let the people who care about that event manage subscribing to said event. This lifts the complexity burden of notifying everyone through API calls and replaces it with 20 lines of code to “publish user sign up event” and keeps your user sign up application/code lightweight and not dependent on all those downstream services being up and ready to receive an API call.
uid: 202211261243 tags: #distributed-systems