Microservice Fundamentals - Communication Styles & Standard Protocols

This post attempts to discuss MS 'Communication Styles' & 'Standard Protocols' used for MS communication.

Predominantly Communication Styles are - Synchronous & Asynchronous

Synchronous -

1. REST
2. gRPC
3. GraphQL
4. WebSockets
5. Thrift

Asynchronous -

1. Single Receiver
2. Multiple Receiver

Note: Synchronous communication does not mean, it's I/O Blocking. We can have Non-IO Blocking implementation by using 'Callback' function.

1). REST

• REST is an architectural style, uses navigational scheme to represents 'Resources' (Objects and Services) over the network. A client then access these resources uses unique URI (In case of HTTP, this interface consists of standard HTTP ops e.g. GET, PUT, POST, DELETE)
• Though REST does not depend of any of the implementation protocols, well most used is HTTP.

More details - http://arun-ts.blogspot.com/2017/04/rest-vs-soap_2.html

2). gRPC:

• In past, RPC was a popular inter-process communication, well multiple drawbacks
• gRPC - uses Protocol Buffers, and HTTP2 as the Transport Protocol, a key reason for gRPC wide adaption.

To get better understanding of gRPC, please check this - https://arunmanglick-ms.blogspot.com/2020/10/grpc.html

To find real use-case (Order Service), assume there is a 'Return Service' (Java Impl) and 'Product Management Service' (Go Lang Impl) to initiate return and update product inventory with returned item.

Here 

• PM Service, uses gRPC and exposes it's contract via ProductMgmt.proto file using Go Language.
• Return Service (Consumer), will also use ProductMgmt.proto file to generate client-side Stub (In Java) and invoke PM Service

Here, under the hood, 

• When a client invokes Retrun Service, the client-side gRPC library uses the Protobuf and marshals the remote function call, 
• This call is then sent over HTTP2
• At the server side, the request is un-marshalled and the respective function is executed using Proto Buf.

Here you can also use Client Streaming, Server Streaming or Bi-directional Streaming RPCs - Details in https://arunmanglick-ms.blogspot.com/2020/10/grpc.html

3. GraphQL:

With REST, wherever client needs data from multiple resources at the same time, it results in multiple service calls. 

GraphQL addresses such concern in a conventional REST based service by providing a Query Language and a Runtime for fulfilling those queries with your existing data.

• Developed in 2012 by Facebook, publicly released in 2015
• In it's simplistic form - It's a Query Language for your API
• GraphQL gives client power to request what exactly they need and nothing more or less. E.g. Only First Name, makes API evolve over time.
• Allows multiple resources to be requested in a single request. Where as with REST, you need to make two request to two endpoints - /users, /books

GraphQL Server exposes a schema describing APIs  - Organized into Types and not Endpoints. Each Type has one or more fields, which each takes zero or more arguments and return a specific type.

Note: Operation Type is Query, Mutation or Subscription, describing what type of operation you are intending to do.

4) WebSockets

• In simple words, WebSockets is TCP but over the Web.
• WebSocket is an architecture consist of a socket that is opened between client and server, for full-duplex (Bi-directional) communication. This anytime your MS need duplex communication, WebSocket is right choice.
• Uses a single TCP connection for traffic in both directions and uses HTTP as the initial handshaking protocol. (As below - Showing interaction between client and server using WebSockets)

Note: WebSockets has few similarities like HTTP2, such as Single Connection, Bi-directional Messaging etc. However difference is WebSockets allows you to build any Message Protocol on top of WebSockets For instances MQTT or AMPQ over WebSockets).

MQTT - MQTT - MQ Telemetry Transport-

Residing on top of the TCP/IP network stack, MQTT is a extremely simple and lightweight publish/subscribe messaging protocol designed for low-bandwidth,limited devices,networks with high latency, low bandwidth or unreliable networks. MQTT's features make it an excellent option for sending high volumes of sensor messages to analytics platforms and cloud solutions.

AMPQ - Advanced Message Queue Protocol

Is a specification for how messaging clients and brokers can interoperate. An open standard for passing business messages between applications or organizations.  MQP is a specification of a wire-level protocol for client to message broker communication.

5). Thrift

This is an alternative to gRPC, but Thrift-based communication requires a lot of work from developer side, as it expose low-level network details to the user. Also being TCP based, makes it less suitable for modern API or Mobile devices. Well on the other hand, being TCP based, performance is high.

Well conceptually Thrift allows you to define data-types and service interfaces in a Simple Definition File. Similar to gRPC, using interface definition compiler generates code to be used to build RPC clients and server communicate across languages.

Asynchronous -

Here client does not wait for a response in a timely manner. Possibly client may not in fact receive a response, or receive response asynchronously via  a different channel.

Asynchronous messaging between microservices is implemented using using Dumb Message Broker (Having No-Business Logic).

Both Single/Multiple can be read here in detail - https://arunmanglick-ms.blogspot.com/2020/12/make-microservices-communicate.html 

1). Single Receiver Mode - 

• Here a given message is reliably delivered from a produce to exactly one consumer.
• AMPQ messaging protocol is most commonly used with Single Receiver based communication.
• AMPQMessage Broker (Such as RabbitMQ, ApacheMQ) can be used - Where producer microservice will produce a message to a specific queue in the broker.
• Consumer microservice can subscribe to the message broker to receive messages.

2). Multiple Receiver Mode - 

• Used when message produced by one producer go to multiple consumers. (Pub-Sub Model)
• Here the services interested will subscribe to the topic.
• Most of the AMPQ based brokers support pub-sub. Well Kafka is mostly used. (Amazon SNS & Event Bridge is also widely used).

Source Used: Link

Hope this helps.

Arun Manglick