Evolution
Understanding how RPC protocols have evolved may help us understand the context better.
Early RPC implementations (1970s-1980s): The concept of remote procedure call was first introduced in the 1970s as a way to simplify distributed programming. Early implementations, such as the RPC mechanism in Sun’s Network File System (NFS), used proprietary protocols and were limited to specific operating systems.
The emergence of standard RPC protocols (1980s-1990s): In the 1980s and 1990s, standard RPC protocols such as DCE/RPC, CORBA, and Java RMI emerged. These protocols provided a common way for distributed systems to communicate, but were often complex and difficult to use.
Web services and SOAP (1990s-2000s): In the late 1990s and early 2000s, the rise of web services and the Simple Object Access Protocol (SOAP) brought RPC to the web. SOAP used XML to encode messages and was designed to work over HTTP, making it a popular choice for web-based RPC.
RESTful APIs (2000s-present): In the mid-2000s, RESTful APIs emerged as an alternative to SOAP-based web services. RESTful APIs use HTTP methods (GET, POST, PUT, DELETE) to manipulate resources, and return data in a simple, easy-to-parse format such as JSON or XML.
Modern RPC frameworks (2000s-present): In recent years, modern RPC frameworks such as gRPC and Apache Thrift have emerged, which provide efficient and scalable RPC over a variety of transport protocols, including HTTP/2, TCP, and UDP. These frameworks use binary serialization formats and efficient network protocols to provide high-performance RPC, and are designed to work in modern distributed systems architectures such as microservices.
gRPC
One of the primary motivations behind gRPC is to make it easier for developers to build and maintain distributed systems. Traditional RPC frameworks often require a significant amount of manual work to set up and configure, and can be difficult to scale as the application grows. gRPC simplifies this process by providing a lightweight, efficient, and standardized way to communicate between services.
Another motivation behind gRPC is to improve performance. gRPC uses HTTP/2 as its underlying protocol, which allows for more efficient communication between services. Additionally, gRPC supports several features such as request/response streaming, which can help reduce latency and improve overall application performance.
Finally, gRPC is designed to be language-agnostic, meaning that it can be used with a wide variety of programming languages. This makes it easier for developers to choose the language that best suits their needs, without having to worry about compatibility issues when communicating between services.
vs REST
gRPC offers significant improvements in performance, type safety, and code generation compared to REST, while also providing more advanced features like bidirectional streaming and cross-platform interoperability.
vs GraphQL
GraphQL is not an RPC framework, but rather a query language for APIs that allows clients to specify the data they need and receive only that data in response.
In a traditional RPC framework, the client typically sends a request to the server specifying the name of the method to be called, along with any arguments, and the server returns the result of the method call. The client must know ahead of time what methods are available and what arguments they accept.
With GraphQL, the client sends a query to the server specifying the data it needs, along with any filters or parameters. The server then returns only the requested data, in a format that is optimized for the client’s needs. The client does not need to know ahead of time what data is available or how it is stored, as the server provides this information as part of the schema.
While GraphQL and RPC share some similarities in that they both involve remote communication between client and server, they are fundamentally different approaches to building APIs. GraphQL provides a more flexible and customizable way of querying data, while RPC provides a more rigid and structured approach to remote method invocation.