As a fan of DDD I sometimes struggle to map the business needs into the current industry standard REST because of its technical nature and entity orientation.
So I went looking for an alternative and found a couple of possible candidates, gRPC+Protobuf, Thrift and Avro.
Of these, it looks like gRPC+Protobuf has the most traction at the moment. It also has a solid future ahead as it is a strategic choice within Google.
So let’s dive in and find out…​.

DDD as the culprit

When designing business oriented services this starts with domain partitions (as small or large as you need it to be) and the operations that are needed in those partitions.
It’s that beautiful moment when development and business almost talk the same language.

The next step is creating services.
In my experience the partitioning into separate services and operations on them mostly do not map very well to the entities model of REST; never mind business operations which do not map at all onto a 'GET/POST/PUT/DELETE entity' url.
So we end up with a service that talks a REST dialect which is not understandable anymore for the business people and is difficult to map from code to business needs.

This all makes maintaining the services difficult in the long run.

Example - the Contract service

So to explore a possible solution, I want to first investigate the problem a bit more with an example service. Let’s say we have a small contractor who does fixed-price contracting work and wants to administer what goes on.

The business process follows these steps:

  • Customer asks for a quote for a piece of work

  • Contractor does the math and gives a fixed-price quote

  • Customer accepts quote

  • Contractor starts working and administers the costs made

  • When finished, the contractor calculates the profit made

These steps are easily understandable for our contractor if we show this to him; and to implement it sounds like this could be a Contract-service, doesn’t it?

There’s one small caveat that we probably can ignore in that it starts with some sort of quoting business, but apart from that, it’s basically a Contract entity.

But what if we don’t want to ignore those small details which make our work easier but the understanding from a business standpoint a lot less? Let’s investigate what a non-REST solution would mean.

Protobuf it is

As stated in the introduction, I will focus on exploring Protobuf. How to model, the network aspects, security etcetera. Starting my journey into Protobuf I was amazed at the amount of very useable documentation Google already made, thanks for that!

But when I really started to use it all the practical stuff quickly became a bit overwhelming. Time for a discovery into the world beyond REST.

First steps

As a quick introductory I’ve used this blog of my colleague Christophe Hesters which is excellent: gRPC as an alternative to REST - If you didn’t read it yet I’ll wait here 'till you get back…​.

There is some confusion about naming. The distinction between gRPC and Protobuf is that the first is the RPC framework and Protobuf is an IDL[1] to describe messages. This IDL is used by gRPC to describe the request and response messages.
To make it confusing, it seems nobody uses the name gRPC to describe what they’re doing, everybody talks about Protobuf to describe both. It does sound better and from here on forwards if I write Protobuf, I’ll probably mean gRPC+Protobuf.

So now let’s start modelling, this is what the service part of our proto definition could look like:

service ContractService {
    rpc newQuote (NewQuoteRequest) returns (NewQuoteResponse);
    rpc promoteQuote (PromoteQuoteRequest) returns (PromoteQuoteResponse);
    rpc addWorkDone (AddWorkDoneRequest) returns (AddWorkDoneResponse);
    rpc finalizeContract (FinalizeContractRequest) returns (FinalizeContractResponse);
}

As you can see, all calls have dedicated request and response messages. That was the first practicality I came across, Protobuf needs more forward thinking. Not of the kind that was needed with old-skool RPC solutions like SOAP, but nevertheless it is more than is needed in the JSON world.

In the next Blog I will dive into my first gRPC call: Practical protobuf - First Call

shadow-left