This article will take you through the 2 commonly used API implementation models namely WebSockets and gRPC.
First , a bit of background…
In June 2008, a series of discussions led by Michael Carter , resulted in the first version of protocol – WebSockets. Later, it was authored to inclusion in the HTML5 specification by Ian Hickson.
WebSockets
Websockets defines an API establishing “socket” connections between a web browser and a server. It is a communication protocol, which allows to open a two-way interactive communication session between the user’s browser and a server. With this API, you can send messages to a server and receive event-driven responses(server side events) without having to poll the server for a reply. WebSockets are bi-directional, a full-duplex protocol and is stateful, which means the connection between client and server will keep alive until it is terminated by either party (client or server). After closing the connection by either of the client and server, the connection is terminated from both the end.
Use cases where webSockets is a right fit
As users of any web page, we would definitely like to set the data as quickly as possible. We are so lucky to have a protocol supported by all browsers which allows direct data exchange, where a user can see the latest data without having to refresh the browser.
Before making a decision to judge whether WebSockets is the right fit, try answering these questions :
- Does the application, where I would want to implement webSockets, have multiple users who communicate with each other ?
- Does the application require the data from the server sider which is constantly changing ?
If your answer is a YES, to the above to questions then you must consider using WebSockets for your application.
The following are some examples i have chosen to understand why WebSockets is a right fit based on a YES got to the above 2 questions,
Lets understand this in depth through examples.
Cricinfo/Cricbuzz:
Today, most people are hooked on cricket without even a need to watch it via these popular platforms which push live commentary/updates to interested folks. Infact, Cricinfo has capabilities to send 1 Million WebSocket Updates to Fans in less than 100MS.Games with multiplayer :
We are able to experiment high performance gaming in the Web browser today. Efficient and real time interaction with players becomes crucial. The player should know the movement of the opponent realtime , rather than later getting attacked due to late processing of data.Collaborative Editing Application :
We are in an era of distributed systems. In the very beginning, they would be one user with one copy of a document and later merging the document would have become another bigger challenge. Now, in distributed systems, multiple users collaborate and edit the documentation , with real time changes reflected when other users are simultaneously editing the document.
gRPC
gRPC – Google Remote Procedure Calls, This is an open source remote procedure call provided by Google in the year 2015. It mainly used HTTP/2 protocol for communication. Protocol Buffers commonly called as protobuf are used to encode the data. ProtoBufs is an open source mechanism for serialising structured data. They are smaller, faster and more efficient than other wire-format protocols. Hence, it is able to offer better performance and security. gRPC is used to make the client believe that the server is on the same machine.
gRPC honestly looks like it could have been just a websocket with a library enforcing data contracts.It is not an architectural style that comes up with a lot of design principles, instead, it is a technical specification that lets you call methods over the internet without having to worry about the platform the service or client is running on. Another important point to note here, by using protobuf you are giving up interoperability, Because your gRPC service will only be able to communicate with gRPC clients.
HTTP/2 protocol
Lets also look why was gRPC introduced, also gRPC is not really relevant for comparison here, but since , gRPC uses HTTP/2 this is mainly used to compare with webSockets.
HTTP/2 provides direct implementation to binary payloads which protobufs implement. Also, it addresses a number of limitations on HTTP 1.1 resulting in improved performance.
Here are some questions you will need to ask before considering gRPC as a right fit for you :
1. Do you require an intra-application communication ?
This use case mainly refers to you having to build a collection of co-operating micro-services. By cooperating I mean to say, micro-services are calling one another directly rather than using a queue or any event-driven approach.
2. Bi-directional services out of the box that allow the server to send messages to the client without first getting a request from the client?
If your answer to each of the above questions is a yes, then gRPC is an ideal solution to reduce inter-process latency. Also, since there are gRPC implementations for most platforms it doesn’t matter if your client is a Web browser, a desktop application, or a smartphone.
Most developers who use micro service architecture style use gRPC. It uses HTTP/2 protocol to support high performance and scalable APIs. allowing multiple concurrent messages to be in flight without compromising network resource usage. It uses header compression to reduce the size of requests and responses.
Comparison
When there is a need to stream real-time data, We have options to use webSockets or the new guy from google – gRPC. But which one to pick is going to be real tough given requirements, conditions and situations.
Now that we have understood Websockets and gRPC in detail, and we also understood in this article so far, what are some questions you will need to ask before you choose any of them.
Let me talk about the first difference wrt the protocol they use :
As the websites evolved, the amount of data that was loaded on a single page increased, leading to the visibility of the shortcomings of HTTP 1.1. It allowed only one open request per one TCP connection. The other drawback was redundant data which led to performance impact.
WebSockets is based on HTTP1.1 protocol and it also came to support bi-directional communication which was not supported in the plain version of HTTP 1.1 . It also maintains persistent stateful connection.
Now, with gRPC , the protocol is HTTP/2 , the messages are binary using protocol buffers.
Now, if we compare HTTP/2 against WebSocket, we can see a lot of similarities:
| Features | gRPC | WebSocket |
| Headers | Compressed (HPACK) – compressing headers significantly limits the number of required round trips. | None |
| Data Format | Binary – protobufs. Binary protocols are also more time and space efficient on the wire. In return, it is more difficult for humans to deal with them, as they are not human-readable. A tradeoff. | Binary or Textual |
| Multiplexing | Yes | Yes |
| Prioritization | Yesallows prioritization of requests, letting more important requests complete more quickly, further improving performance. | NoHTTP/1.x does not allow effective resource prioritization, resulting in poor use of the underlying TCP connection |
| Compression | Yes | Yes |
| Full-duplex | Yes | Yes |
Key Takeaways
Will WebSocket(HTTP 1.1 based) survive HTTP/2?
Yes, it will. This is because it is well adopted and, in very specific use cases, it has an advantage as it has been built from the ground up for bidirectional capabilities with less overhead (headers).
Suitability of use case?
Let’s say that you need to exchange a high throughput of messages from both ends, with almost as much data flow upstream than downstream (e.g Massively Multiplayer Online Game that needs to keep all their players in sync). WebSocket will probably remain a better choice.
But on the other hand, if you consider a use case like displaying real-time market news, market data, chat application, etc, relying on gRPC will provide you an efficient bidirectional communication channel and keep the huge advantage of staying in the HTTP world.
As HTTP/2 is not a full replacement of HTTP, both gRPC and Websockets are here to stay. Hope this helps you make the right choice for your application.
