gRPC vs WebSocket: What to Choose for Your Project
According to Statista, as of January 2022, gRPC is a second-popular mobile communication software development kit (SDK) among Android apps worldwide.
gRPC is a modern open-source high-performance Remote Procedure Call (RPC) framework that can run in any environment ranging from servers inside a large data center to your own tablet. It can be used for various scenarios such as connecting polyglot services in microservices architecture, generating client libraries, or connecting mobile devices and browser clients to back-end services.
gRPC is actively discussed in the developers’ community. One of the aspects under discussion is a comparison of gRPC and WebSocket. In this article, we are going to tell whether gRPC and WebSocket are comparable, what are gRPC and WebSocket cons and pros and their use cases to help you choose the best option for your project. At the end of the article, we’ll share our company’s experience with cryptocurrency app development and solutions we found to accelerate the speed of data flow, namely using gRPC-offered possibilities.
What is gRPC
gRPC (Remote Procedure Call by Google) is an open source remote procedure call system initially developed at Google in 2015. It is a framework that allows the server and the client transparent communication. gRPC was introduced to refresh the existing Application Programming Interface (API) design methods using Protocol Buffers and HTTP/2. gRPC is open source and part of the Cloud Native Computing Foundation (CNCF) ecosystem.
gRPC handles various tasks such as:
- complex communication between different languages and environments;
- large-scale synchronous communication between microservices;
- high throughput communication where performance is critical;
- support for bi-directional streaming;
- pushing messages in real time without polling.
Companies like Netflix, Cisco, Wisconsin, Cockroach Labs, and many more use gRPC to connect multiple services.
gRPC strong points
- switch from JSON to protocol buffers: data is transmitted as fast as possible and most compactly;
- multiplexing many requests on one connection so that multiple requests do not block each other,
- full-duplex bidirectional streaming enables simultaneous client request and response from server;
- due to the binary data format, messages are much lighter,
- built-in code generation in different programming languages, including Java, C++, Python, Go, Dart, Objective-C, Ruby, and more;
- strict specification which gives a detailed description for implementation of gRPC.
gRPC weaknesses and limitations
- limited browser support: a gRPC service cannot be called directly from a browser;
- the binary message format is not human-readable;
- gRPC is not the best fit for broadcast real-time communication.
What is WebSocket
WebSocket is a computer communication protocol that was built for bidirectional, full-duplex communications over a single Transmission Control Protocol (TCP) connection.
The WebSocket protocol was standardized by the Internet Engineering Task Force (IETF) as Request for Comments RFC 6455 in 2011, and the WebSocket API in Web IDL (interface description language) is standardized by the World Wide Web Consortium (W3C).
The WebSocket makes it possible to exchange data between a browser and a server through constant connection. Data is transmitted in both directions in the form of “packets” without breaking the connection and additional HTTP requests. The protocol is especially good for services that require constant communication, such as:
– online games,
– real-time web applications like trading websites or bitcoin trading,
– chats, and the like.
WebSocket strong points
- full duplex: WebSocket ensures bidirectional communication. Server and client can transmit data simultaneously;
- low latency: WebSocket allows for instantaneous communication. After opening a socket, data can be exchanged without any application layer overhead;
- flexibility: WebSocket supports a wide range of data types, including for voice and video media transmission, and XML for messaging applications.
WebSocket weaknesses and limitations
- fully HTML5-compliant web browser is required;
- no intermediary/edge caching;
- WebSocket is not the best fit for an application that doesn’t take a lot of dynamic interaction;
- WebSocket connections are persistent which is good for real-time applications, but makes it more difficult to scale.
gRPC vs WebSocket
To be more precise, the direct comparison shall not be about WebSocket and gRPC.
gRPC uses HTTP/2 which is a major revision of the HTTP network protocol used by the World Wide Web. That’s why, these are two protocols to be compared: WebSockets and HTTP/2.
Actually, HTTP/2 and WebSocket are capable of similar things.
When architecting the exchange of messages between a server and a client, the first idea will probably be to refer to some HTTP based technologies. WebSocket uses HTTP connection for sending messages back and forth and makes the communication bidirectional. The protocol succeeds in the task better than other options such as XNR, SSE, and more and therefore, belongs to widely used solutions.
HTTP/2 helps to avoid the use of additional technologies like WebSocket as it eliminates the restrictions that existed in HTTP. It enhances performance over HTTP by reducing latency through full request and response and minimizing protocol overhead via compression of header files.
The choice for a specific project will depend on the project’s conditions and purposes. Below you can read about our experience with cryptocurrency exchange app development,where we preferred gRPC and the decision turned out to be right.
gRPC — Surf choice for crypto exchange app
When developing the Twim app and choosing the technology stack, we focused on the quote charts as one of the main elements. They must be displayed correctly and updated very quickly.
To draw charts for Twim, we used the library of TradingView, the most popular financial visualization platform. Almost all trading terminals use it. Its advantage lies in flexible settings that allow displaying a lot of indicators that traders may need.
From a technical point of view, the process of displaying charts in a stock application is not as simple as it seems. To display charts from TradingView, we needed the WebView component. It allows embedding web pages in Android applications. For the charts to be displayed correctly on both iOS and Android devices, we made additional processing — native Swift and Kotlin wrappers.
The process was as follows:
- Data from the exchange server was transmitted to TradingView via the gRPC protocol for remote data transfer.
- Then, they were converted into graphs and sent to the application via WebView.
- Depending on the device used by the trader, iOS or Android, the required native wrapper was used.
It is very important that the quotes in the crypto exchange application are updated constantly and almost in real time. Not all applications can boast of high speed. So when developing the application, we tried to maintain a high data transfer rate — they had to be updated up to 20 times per second. Therefore, instead of REST, we used a bunch of gRPC, HTTP/2 and protocol buffers (protobuf).
With gRPC, the application transmitted data streams – cryptocurrency quotes – from the server to the client and vice versa. The HTTP/2 protocol converted data into binary form. This saved traffic and increased the speed of their transmission.
The protobuf serialization protocol has become an alternative to JSON. It packaged the data for the client and server and did it very quickly, since they were in binary form, optimized for the minimum message size.
In 2017, when we started developing the application for Twim, Android worked correctly with gRPC, since there were already stable libraries. But for iOS, we wrote an interpreter that generated entities in Swift. Now there is no need for such a layer, since the developers have already made an implementation for Swift.
Closing thoughts
To sum up, we’d like to highlight that gRPC and WebSocket are not interchangeable and each one serves its own range of tasks. For example, gRPC is not a match for browser-accessible APIs and broadcast real-time communication, while WebSocket is not the best choice if you have plans to scale.
To make the right choice for your project, try to consider aspects that cover both technology and business areas:
- whether it can ensure the required quality and security;
- whether it is suitable to solve your business goals;
- whether it does not in any way restricts your product future development;
- whether there are examples on the market to learn from.
If you have any questions left, you’re welcome to contact the Surf team.
