gRPC bidirectional streaming versus back to back HTTP call

Question

I saw recently an article where we are using bidirectional streaming calls for exchanging business data and not only for uploading/downloading.

Then a question occurred to me: is this model viable in replacement of API backend to backend HTTP calls?

For example, if we check this:

A backend client could open a gRPC stream with other backend server when the service starts. Then when a front client call this service:

1. The back end client sends a request to the other backend service (with an ID) and wait
2. The other backend service callback the backend client with the response (and the same ID)
3. Once the response is received from backend client, it answers to the frontend

Is this pattern could be faster than back-to-back HTTP call? Or is this idea completely dumb? Did someone already try this?

Answer 1

This approach has its pros and cons.

Comparing to unary calls, if backend client follows best practices and re-uses gRPC channel between the calls, then this shouldn't be faster.

The difference will be that in unary calls header+data frames will be sent on request and headers+data+headers frames on response, whereas in bidi-streaming request-response messages would be just data frames. But the headers frames usually get sent in the same packet with data frames anyway and headers parsing shouldn't be too consuming, so I don't expect we can save any significant time here.

The cons of converting all unary calls into a single bidi-streaming are:

• There is no error code in response message, so you'll have to design error model in the response message and handle it on the server and client side.
• Placing all requests onto a single stream won't allow the client to load balance the requests.
• There is a flow control mechanism on http/2 streams level. Placing all requests on a single stream disables that - one big request will block all others.

Streaming calls have many valid use-cases, e.g., when we need to subscribe to updates or stream data between client and server. For these use-cases streaming calls are great, but if unary calls work for your use-case, converting them to a streaming call won't bring significant benefits.