APIs have never had more connections and requests for data. With variable data types, changing programming languages, and a demand for high performance, even with an increased focus on authentication mechanisms and data security, it’s never been more critical to figure out the efficiency of your systems.
Enter GraphQL and gRPC. These two solutions are juggernauts in the API space, offering different solutions for connecting servers, systems, modern browsers, and mobile apps with better efficiency and data service. How do these systems work? And which is best for you? Read on to find out!
What is GraphQL?
GraphQL is a query language designed to allow clients more significant control over the data they’re requesting, both in terms of the expected output and the format of that output. It was first developed by Facebook in 2012 as a methodology for allowing services to request specific data formats and was later released in 2015 to the public. Since then, it has gained a significant user base.
The core of GraphQL operates on a schema-based system, where developers define the underlying data structures of the API. From here, users can then place a request via a client using a single endpoint to query data – this request can also be used to form the output format and function, allowing for more significant client control over service with a single endpoint and request flow rather than the typical multiple requests and iterative formatting in other systems.
Benefits of GraphQL
This approach has significant benefits for both the client/user and the service provider alike.
- GraphQL minimizes over and under-fetching by allowing clients to dictate the specific data needed in the format necessary for its use. In addition to resolving fetching issues, this also has a positive effect on user sentiment, reducing the overall time and effort to generate necessary data. This declarative data fetching also has the ability to reduce overall payload size and align output data against data structures, allowing for more efficient processing.
- This operation occurs on a single endpoint – all queries and mutations are sent via one endpoint and data flow, which simplifies the API architecture significantly both on the client side and the server side. A GraphQL server leverages a pre-determined GraphQL schema, meaning both the structure data in storage, the exact data in transit, and the response data format can be well-controlled by the needs of the client without laying an extensive series of restrictions upon the server requiring transformational endpoints or subprocesses.
- GraphQL tends to be strongly typed, ensuring reliability even in the most complex data environments. This results in simplified server code as well as understandable structured data definitions.
What is gRPC?
gRPC, or “gRPC Remote Procedure Call”, is an open-source remote procedure framework. It was originally developed by Google as an RPC system to power their connected systems and was released to the public in 2015.
The framework offers a highly efficiency way to interact with distributed systems through a system of strongly typed contracts, which are defined using the Protobuf, or Protocol Buffers, standard. gRPC focuses on defining service methods rather than exposing resources, and as such, it has been classed as a framework that is competing against GraphQL.
gRPC utilizes a few key technologies that set it apart from other frameworks:
- Protobufs – Protobufs, or Protocol Buffers, are a compact and efficient serialization format that allows providers to define data for exchange.
- Streaming – gRPC allows for bi-directional streaming, which makes it highly efficient for complex interactions across distributed data sets.
- Service-Oriented – since gRPC focuses on operations and methods rather than the resources themselves, it tends to be focused more squarely on the service, which gives quite a bit more control to the service provider.
Benefits of gRPC
gRPC offers some unique benefits that have made it a relatively popular option for some developers.
- gRPC utilizes Protobufs, which is an extremely efficient and compact binary format for data serialization. This makes gRPC extremely fast – when paired with the multiplexing inherent in HTTP/2, this further reduces latency and improves throughput, making the system even more efficient.
- Support for bi-directional streaming and long-lived connections means that gRPC is especially useful for systems that need multi-directional streaming and real-time communication. It supports a few key streaming types, including server-streaming and client-streaming, and provides a system for unary singular request-response streaming to provide additional functionality.
- Protobufs ensure strong typing, which reduces runtime errors and improves reliability.l
How is GraphQL Different from gRPC
GraphQL and gRPC approach data and systems in distinctly different ways. While GraphQL focuses on flexibility in the data fetching process, gRPC focuses more on service-oriented solutions and performance improvements on the codebase itself.
For example, GraphQL largely allows clients to control their queries and manipulate the underlying data. gRPC, on the other hand, focuses on more efficiently exposing service methods to execute the operations based on the data. This is foundationally different, and while the result is still enabled – more efficient querying across related data and multiple clients how the solutions get there is vastly different.
These solutions also use very different transport layer solutions. While GraphQL utilizes HTTP/HTTPS, largely opting for JSON, gRPC utilizes HTTP/2 and Protobufs for binary serialization, which is quite a lightweight methodology. In theory, this makes gRPC a more efficient data transporter – although it must be said that an efficient client with the proper structure on their query requesting data in a specific format might have a more efficient data transfer due to the laminate nature of their data retrieval.
Ultimately, GraphQL is a solution that is much more flexible, allowing only the data that is needed to be requested in one request by the client. gRPC, while it doesn’t boast the same benefits in the theory of the single request, can gain much of the same efficiencies through the implementation of the gRPC client and the communication patterns inherent to it.
GraphQL vs. gRPC: Comparison Table
| Feature | GraphQL | gRPC |
| Primary Use Case | Client-server communication | Backend-to-backend or microservices |
| Data Format | JSON | Protocol Buffers (binary) |
| Transport | HTTP/HTTPS | HTTP/2 |
| Query Model | Flexible, client-driven | RPC-based, server-defined |
| Real-Time Support | Subscriptions | Streaming (bidirectional) |
| Tooling | Strong front-end ecosystem | Extensive multi-language support |
| Performance | Higher latency due to JSON parsing | Low latency due to binary serialization |
| Learning Curve | Moderate | Steeper due to protobuf and RPC concepts |
| Schema Definition | GraphQL SDL | Protocol Buffers |
| Error Handling | Granular error messages in responses | Centralized error handling with protobuf |
A Brief History: GraphQL vs gRPC
GraphQL was born out of Facebook’s need to efficiently handle complex and dynamic data fetching for its mobile applications, and the nature of GraphQL reflects this. Because of this historical context, GraphQL was seen as an evolution of the “send all the data” mentality, allowing clients to request exactly what they want. When a client sends a request for a specific stack of data, it gets only that data.
gRPC, on the other hand, came from a need to connect internal systems more efficiently. Because this historical context focuses on the internal aspects of the data and its functions, it’s obviously less concerned with existing clients and much more concerned with the patterns between the gRPC server and its constituent parts.
For this reason, the history between these two services has resulted in products that reach the same end state – more efficient services – in entirely different ways.
Which is Better: GraphQL or gRPC
This is a very hard question to answer – that being said; we can give you an answer based on our specific use case here at Speedscale.
Speedscale’s Solution – Out with GraphQL, in with gRPC
During Speedscale’s MVP, we leveraged GraphQL to expedite product market fit. Moving forward, we’re switching to gRPC.
At Speedscale, we’re always trying to find ways to iterate faster and reduce developer toil. In line with that mission, we slant our engineering decisions towards using cutting-edge tech because we usually move faster, and it also allows us to help our customers later on when they upgrade their own tech stack. Recently, we had the opportunity to upgrade the communication channel between our api-gateway and react front end. This journey provided some unexpected benefits.
At Speedscale, we’re always trying to find ways to iterate faster and reduce developer toil. In line with that mission, we slant our engineering decisions towards using cutting edge tech because we usually move faster and it also allows us to help our customers later on when they upgrade their own tech stack. Recently, we had the opportunity to upgrade the communication channel between our api-gateway and react front end. This journey provided some unexpected benefits.
Growing Pains
During our MVP phase, we initially built our user interface using the react-admin prototyping framework which communicates using GraphQL via the apollo-server. The architecture is easy to very straightforward and common:
Early on we needed something fast that was easy to work with and GraphQL turned out to be a fantastic decision. Our observations from using GraphQL for over a year net out as:
What we love:
- easy developer on-ramp
- fine grained data access facilitates progressive disclosure
- easy to debug in production
What we don’t love:
- large bandwidth requirements
- hard to debug on the developer desktop
- schema drift between backend and front end systems
- lack of native support for hash maps
However, as we migrated off react-admin to pure react, we noticed we were building things more slowly and generally becoming very grumpy every time we had to make certain kinds of changes. Specifically, we started seeing increased blocking between the front-end (react) and API (nodejs) engineers whenever there was a change in the data model. It was taking us longer to add and debug a single data field to the Data Provider and API than to add it to the other 12 microservices feeding the API. Ultimately we diagnosed the problem to the protocol-equivalent of schema drift between our back end microservices, which utilize protobuf, and our front end which utilizes a completely separate schema in GraphQL. Whenever we changed the protobuf, we had to make the same changes in multiple components, often including custom translation logic (for instance to convert a map to an array). This process is manual, error prone, and generally painful.
Alternatives
Before diving into re-architecting a big chunk of our front end we considered a few alternatives:
- Improve automation to enforce consistency and find errors
- Move to a tried and true REST API
- Move to Google’s grpc-web
Ultimately, we decided to implement end-to-end gRPC from react all the way to our data collectors using grpc-web. After overcoming some initial pain, the benefits turned out to be enormous.
gRPC Is Fast AND Easy to Use
What we love:
- grpc requires 50-90% less processing than GraphQL in the web client. We aren’t ready to release comparative load test results but our results are in line with what others have posted. Our users initial reaction is usually “Whoa, what did you do to this thing?”
- Grpc reduces network utilization drastically. We experienced a roughly 70% reduction in data volume on average, with even larger gains for messages containing a large metadata to payload ratio. For example, the left JSON blob enjoys a much higher compression ratio vs the right:
!= 
- schema drift is found when code is written instead of when it runs. This turns out to be a substantial improvement in developer experience.
What we don’t love:
- HTTP/2 support, which gRPC relis upon, is somewhat immature as of May 2021. Plan for a small, but ongoing DevOps tax that must be paid. We found and overcame a variety of sharp edges up and down our stack including:
- nginx requires all traffic to be HTTP/2 when using grpc_pass to a TLS enabled endpoint, even though we had a mix of HTTP and gRPC
- AWS ALB HTTP/2 support has arrived but is not yet feature rich
- we were forced into maintaining certificates for every component that egress data through our K8s load balancer
- our synthetic monitoring tool currently doesn’t support HTTP/2
- grpc tools are immature and debugging in production requires a new skillset. You can’t pop open the network tab in Chrome and inspect request information. Fortunately, tools like gRPC-Web Developer Tools, grpcurl, wombat and BloomRPC are starting to emerge.
- Onboarding new engineers takes a little bit longer because of a lack of familiarity with grpc-web. However, our react developers refuse to go back to GraphQL now that they’re over the learning curve.
As we grow, it may become an issue that we have tightly coupled back end and front end data definitions but for now it’s been a huge boost. Also, we haven’t done things like optimize for mobile which may change the equation but for now the migration to gRPC-Web has been unexpectedly smooth and developer productivity has returned to normal.
Conclusion
Ultimately, choosing between GraphQL and gRPC will be determined based on the specific needs of your system and stack. While gRPC services are often quite efficient, a GraphQL request can prevent unnecessary data from being serviced, significantly improving efficiency. gRPC, on the other hand, is built to be efficient from the ground up – and with this focus, HTTP requests don’t need as much efficiency in data service as the service is already highly efficient.
While Speedscale has adopted gRPC as its solution, there are serious pros and cons to consider with either solution. Your architectural style, the way you engage in code generation, and even the API technology under the hood at your service will determine what you need to get out of this process.
Building apps with GraphQL or gRPC and need to create ephemeral environments for testing or mocking? Speedscale has you covered! You can sign up for a free trial in seconds and start with Speedscale immediately!