> For the complete documentation index, see [llms.txt](https://kdongs.gitbook.io/kdocs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kdongs.gitbook.io/kdocs/grpc/grpc.md). # gRPC {% embed url="" %} ## About It is a framework for building robust and scalable communication between server applications. Ideal for: * Microservices. *(Communication between services)* * Backend. *(*`server-to-server` *communication)* * Client. *(*`client-to-backend` *communication)* {% hint style="warning" %} Browsers are not yet fully prepared to handle gRPC. {% endhint %} It has a couple of advantages over `REST`, like: * Type safety. * `gRPC` enforces message structures defined in [Protocol Buffers](/kdocs/grpc/protocol-buffers.md). This ensures compatibility between services and prevents unexpected data types from causing errors. * Performance otimizations. * Uses a compact binary encoding format for messages, leading to faster transmissions and lower resource consumption compred to other `JSON`-based APIs. * Cleaner developement experience. * It offers features like streaming `RPCs`, allowing for efficient handling of data transfers or real-time updates. {% hint style="info" %} `gRPC` can communicate over `HTTP/2`. This means it: * Supports traffic in `binary`. * Supports bi-directional communication. *(Between Client-Backend)* {% endhint %} ### REST vs gRPC
REST
  • Text / Json
  • One-directional only
  • Higher latency

  • No contracts (higher change of error)

    • Like number as string.
  • No streaming support.
gRPC
  • Protocol Buffers
  • Bi-directional and Asyncronous
  • Lower lantency
  • Defined contract (.proto)
  • Streaming support.
## RPC (Remote Procedure Call) A `Client` calls the `Server`, with a request, invoking a procedure and the Server responds with a response. ## Communication Types ### Unary Client makes a **single** `request` and the Server responds with a **single** `response`. ### Server Streaming Client makes a **single** `request` and the Server responds **one or multiple** `responses`. This helps the Client to use the data as it comes (piece by piece), and not have to wait the server to fully process and returns the hole data. ### Client Streaming Client makes **multiple** `requests` and the Server responds with a **single** `response`. Like if you will upload a file, you may upload it in peaces. After the Server receives them all it process it and respond. ### Bi Directional Streaming Client makes **multiple** `requests` and the Server responds with **multiple** `responses`.