System Design — Client-Server Communication

Concepts and considerations for Client-Server Communication in System Design

Published in

Computer Science Fundamentals

9 min readApr 6, 2020

❤️ Thank you for your interest in this article, if you like the content feel free to Subscribe, clap👏🏻 and share it.❤️

Client-Server Communication
API Protocols

1. Client-Server Communication

The majority of the communication on the web happens over HTTP. There are two modes of data transfer between the client and the server. HTTP PUSH & HTTP PULL. For every response, there has to be a request first. The client sends the request & the server responds with the data. This is the default mode of HTTP communication, called the HTTP PULL mechanism. In HTTP PUSH, the client sends the request for particular information to the server, just for the first time, and after that, the server keeps pushing the new updates to the client whenever they are available. There are multiple technologies involved in the HTTP Push based mechanism such as:

Ajax Long polling
Web Sockets
HTML5 Event Source (Server-sent event)
Message Queues
Streaming over HTTP

Long-Polling, WebSockets, and Server-Sent Events are popular communication protocols between a client like a web browser and a web server.

HTTP is synchronous in the sense that every request gets a response but asynchronous in the sense that requests take a long time and that multiple requests might be processed in parallel. Therefore, many HTTP clients and servers are implemented in an asynchronous fashion, but without offering an asynchronous API. Using multiple threads is one way to implement asynchronicity, but there are others like callbacks or event loops.

1.1 Ajax Polling

Polling is a standard technique used by the vast majority of AJAX applications. The client repeatedly polls (or requests) a server for data, and waits for the server to respond with data. If no data is available, an empty response is returned.

The Client opens a connection and requests data from the server using regular HTTP.
The requested webpage sends requests to the server at regular intervals (e.g., 0.5 seconds).
The server calculates the response and sends it back, like regular HTTP traffic.
The client repeats the above three steps periodically to get updates from the server.

Problems:

The client has to keep asking the server for any new data.
A lot of responses are empty, creating HTTP overhead.

1.2 HTTP Long-Polling

This is a variation of the traditional polling technique that allows the server to push information to a client whenever the data is available. The client requests information from the server exactly as in normal polling, but with the expectation that the server may not respond immediately.

The client makes an initial request using regular HTTP and then waits for a response.
The server delays its response until an update is available, or until a timeout has occurred.
When an update is available, the server sends a full response to the client.
The client typically sends a new long-poll request, either immediately upon receiving a response or after a pause to allow an acceptable latency period.
Each Long-Poll request has a timeout. The client has to reconnect periodically after the connection is closed, due to timeouts.

1.3 WebSockets

A persistent full-duplex communication channel over a single TCP connection. Both server and client can send data at any time.

The client establishes a WebSocket connection through a process known as the WebSocket handshake. If the process succeeds, then the server and client can exchange data in both directions at any time.
Low communication overhead and real-time data transfer.
The server can send content to the browser without being asked by the client (without browser refresh) and allowing for messages to be passed back and forth while keeping the connection open.

Determining whether to use WebSockets for the job at hand is simple:

Does your app involve multiple users communicating with each other?
Is your app a window into server-side data that’s constantly changing?

Use cases:

Social feeds
Collaborative editing/coding: with WebSockets, we can work on the same document and skip all the merges.
Chat apps
Tracking apps
Live audience interaction
IoT device updates

1.4 Server-Sent Event (SSE)

It is a technology that enables a browser (client) to receive automatic updates like text-based event data from a server via an HTTP connection. The client establishes a persistent and long-term connection with the server. The server uses this connection to send data to a client. If the client wants to send data to the server, it would require the use of another technology/protocol.

The client requests data from a server using regular HTTP.
The requested webpage opens a connection to the server.
The server sends the data to the client whenever there’s new information available.

Use case:

When real-time traffic from the server to the client is needed.
When the server generates data in a loop and sends multiple events to the client.
Facebook/Twitter updates, updating statuses, push notifications, newsletters and news feed, stock price updates, sports results, etc.

2. API Protocols

In recent years, there are many types of API protocols, such as RPC and GraphQL.

2.1 SOAP

SOAP is the oldest web-focused API protocol that remains in widespread use. It is an example of a Remote Procedural Call or RPC. SOAP stands for Simple Object Access Protocol. It requires a fair bit of work to make requests. You have to create XML documents to make calls, and the XML formatting that SOAP requires isn’t exactly intuitive. This not only makes call implementation difficult but also makes problems hard to debug because debugging requires parsing through long strings of complex data.

On the other hand, SOAP relies on standard protocols, especially HTTP and SMTP. That means that you can use SOAP in virtually every type of environment because these protocols are available on all operating systems.

2.2. REST

REST, short for Representational State Transfer, is an API protocol that was introduced in a 2000 dissertation by Roy Fielding, whose goal was to solve some of the shortcomings of SOAP.

Like SOAP, REST relies on a standard transport protocol, HTTP, to exchange information between different applications or services. However, REST is more flexible in that it supports a variety of data formats, rather than requiring XML. JSON, which is arguably easier to read and write than XML, is the format that many developers use for REST APIs. REST APIs can also offer better performance than SOAP because they can cache information.

2.3 JSON-RPC

While REST supports RPC data structures, it’s not the only API protocol in this category. If you like JSON, you may prefer instead to use JSON-RPC, a protocol introduced in the mid-2000s.

Compared to REST and SOAP, JSON-RPC is relatively narrow in scope. It supports a small set of commands and does not offer as much flexibility as a protocol like REST with regard to exactly how you implement it. However, if you like simplicity and have a straightforward use case that falls with JSON-RPC’s scope, it can be a better solution than REST.

JSON-RPC can be used in HTTP and WebSocket.

Example of JSON-RPC request and response:

// request
curl -d "{\"jsonrpc\": \"2.0\", \"id\": 2, \"method\": \"subtract\", \"params\": {\"subtrahend\": 23.4, \"minuend\": 42.8},}" --header "Content-Type: application/json" http://myserver:8080/openroad/jsonrpcservertest// response
{"result":19.400, "id":2, "jsonrpc":"2.0"}

2.4 gRPC

gRPC is an open-source API that also falls within the category of RPC. Unlike SOAP, gRPC is much newer, having been released publicly by Google in 2015. Like REST and SOAP, gRPC uses HTTP as its transport layer. Unlike these other API protocols, however, gRPC allows developers to define any kind of function calls that they want, rather than having to choose from predefined options (like GET and PUT in the case of REST).

Another important advantage of gRPC is that when you make a call to a remote system using gRPC, the call appears to both the sender and the receiver as if it were a local call, rather than a remote one executed over the network. This simulation avoids much of the coding complexity that you’d otherwise have to contend with in order for an application to handle a remote call.

The ability of gRPC to simplify otherwise complex remote calls has helped make it popular in the context of building APIs for microservices or Docker-based applications, which entail massive numbers of remote calls.

2.5 GraphQL

In a way, GraphQL is to Facebook what gRPC is to Google: It’s an API protocol that was developed internally by Facebook in 2013. It is officially defined as a query language, also represents an effort to overcome some of the limitations or inefficiencies of REST.

One of the key differences between REST and GraphQL is that GraphQL lets clients structure data however they want when issuing calls to a server. This flexibility improves efficiency because it means that clients can optimize the data they request, rather than having to request and receive data in whichever prepackaged form the server makes available (which could require receiving more data than the client actually needs, or receiving it in a format that is difficult to use). With GraphQL, the clients can get exactly what they want, without having to worry about transforming the data locally after they receive it.

2.6 Apache Thrift

Like GraphQL, Apache Thrift was born at Facebook and functions essentially as an RPC framework. However, the design goals and target use cases for Thrift differ significantly from those of GraphQL.

Thrift’s main selling point is the ease with which it makes it possible to modify the protocol used by a service once the service has been defined. Combined with the fact that Thrift also supports an array of different transport methods and several different server-process implementations, this means that Thrift lends itself well to situations where you expect to need to modify or update your API architecture and implementation frequently. You might say that Thrift is great for avoiding “API architecture lock-in” because it ensures that you can easily change your API architecture whenever you need to, instead of being forced to keep the same architecture because of API inflexibility.

On the other hand, some developers might contend that the choice that Thrift gives you when it comes time to implementing the API is not ideal because it leads to less consistency than you get with other API protocols that offer only one way of doing things. If you like rigid consistency and predictability, Thrift may not be the best choice for you.

2.7 SOAP vs REST

2.8 Webhooks (it is not API)

Sometimes webhooks are referred to as a reverse API, but this isn’t entirely true. They don’t run backward, but instead, there doesn’t need to be a request initiated on your end, data is sent whenever there’s new data available.

To set up a webhook all you have to do is register a URL with the company proving the service you’re requesting data from. That URL will accept data and can activate a workflow to turn the data into something useful. In most cases, you can even specify the situations in which your provider will deliver you the data.

Webhooks and APIs differ in how they make requests. For instance, APIs will place calls for data whether there’s been a data update response, or not. While webhooks receive calls through HTTP POSTs only when the external system you’re hooked to has a data update.