Is GraphQL the Resurgence of RPC style API’s?

GraphQL’s development started in 2012 at Facebook to mitigate the issues they faced integrating their mobile application with the verbose API’s the website used before it was released to the public in 2015. Since then, the there has been a public debate if GraphQL should be classified as RPC-style API standard or if it is something entirely different. While there has always been a debate of which API style might be best, the truth is that each style has its advantages and shortcomings and is tailored to solve a specific use case. So let’s try to understand the differences and commonalities between RPC, REST and GraphQL before coming to the conclusion that GraphQL might be the latest resurgence of RPC style API integration.

RPC – Remote Procedure Calls

Remote Procedure Calls were developed in the 1970’s gained adoption throughout the 1980’s where Bruce Jay Nelson is credited to coin the term for the technique of calling a function or subroutine over the network on a different computational node and expecting a response. From an API point of view, the unit of interest is the function that defines the service. With the advent of REST, RPC style communication lost initially some traction but re-gained interest resulting in gRPC or Apache Thrift.


  • Simple and easy to understand as each function describes semantically its intention
  • Payloads are lightweight and tailored to the problem the function solces
  • Performance generally higher as protocol layers can be optimized for RPC execution


  • Tight coupling between a service provider and consumer based on function and related data sets
  • No standardization, implementations vary and services can not be discovered through standardized lookups
  • It is easy to add additional functions which results often in the so called “function explosion”
  • Maintenance of different RPC services grows more and more difficult with the growing number of services and dependencies
  • No standardized abstraction at an API layer that is decoupled from the underlying system

REST – Representational State Transfer

REST defines a set of constraints to expose resources via URLs. The term was introduced in 2000 by Roy Fielding and described the principles that were discussed during the 1990s as “HTTP object model” resulting in the Uniform Resource Identifiers standard. With its focus on resources and the adoption of the HTTP protocol, that defines the operations that can be applied on resources, REST achieves the opposite of tight coupling. The latest development defining the REST API interaction model further resulted in the JSON Hypertext Application Language (HAL), JSON-API as a specification for building APIs in JSON and the Ion Hypermedia Type as intuitive, JSON-based hypermedia type.


  • Client and server are semantically decoupled and only focused on operations around resource access
  • API can evolve over time as long as basic constraints for backward compatibility are respected
  • Use of the HTTP protocol helps to decrease resource consumption and reduces the network bandwidth resulting in APIs performance
  • No limitations regarding the data format used between client and server


  • Not a single specification that defines the way the interaction between service provider and consumer should be structured
  • Potential for large payloads that reduce the overall application performance for both, server and client

GraphQL – Query language for your API

GraphQL is a query language for your API, was developed since 2012 by Facebook as a response to their transition to mobile and released in 2015 to the open-source community. Since 2018 the project was moved to the newly found GraphQL Foundation and hosted by the Linux Foundation. GraphQL offers clients the ability to define the structure of they expect. To achieve that, the central unit of the work is structured around is a query. The latest development includes a schema definition as a description of all queries that can be executed against a service. The queries provide the client with flexibility to defined what they expect.


  • Due to the nature that queries specify exactly what a service consumer needs, the network overhead is low
  • The schema definition is typed and both service provider and consumer can use the definition as contract
  • Larger object graphs are best suited to be exposed via a GraphQL service since clients want to consume portions of the entirety


  • Exposing queries instead of the simple HTTP protocol operations increase complexity of adopting the framework
  • Caching architectures that fit the HTTP resource model become obsolete since not all data is exposed in a default way consistently
  • Versioning of queries and attributes is not clearly defined by any set of best practices


When looking at the core concepts of each API style, it becomes obvious that there is a clear distinction between the resource-centric view of REST and the functional- and query-based perspective of RPC and GraphQL API styles. Trying to distinguish between functions and queries becomes much harder and I agree with Phil Sturgeon’s statement:

“GraphQL is essentially RPC, with a lot of good ideas from the REST/HTTP community tacked in”

The biggest advantage that I see over REST is, that the specification has lead to a clear schema enabling the navigation of your object tree whereas REST-full services have often the notion of an RPC-style interaction based on HTTP operations without considering the navigation across resources. I think it is fair to say that there are commonalities between GraphQL and RPC, but SQL like queries provide still more flexibility than exposing a function that accomplishes something. As a consequence, I would not consider GraphQL to be the resurgence of the RPC API-style and rather a valuable addition to the existing set of

Each of these API-styles has its own use case and there is not a single API-style that can be considered to be superior to another. The advantages of each API-style feature and I recommend considering the adoption of more than one when building out APIs to offer integration points to your applications. There are cases, where a query-based integration style might be superior, i.e. when trying to integrate flexibly with a data or a mobile API, but there are other API scenarios like a management or command API that has entirely different requirements on how to interact with the data and the functions it exposes.


  1. GraphQL – A query language for your API
  2. Phil Sturgeon – Understanding RPC, REST and GraphQL
  3. Tom Smith – APIs: RPC versus REST versus GraphQL
  4. Renato Athaydes – The return of RPC
  5. gRPC – A high performance, open-source universal RPC framework
  6. Apache Foundation – Apache Thrift
  7. M. Kelly – JSON Hypertext Application Language
  8. JSON-API – A specification for building APIs in JSON
  9. Ion Working Group – The Ion Hypermedia Type