While investigating Protobuf I shot from the hip and wrote that: to model money, one should use BigDecimal. That’s the conventional wisdom and it is correct - in a lot of cases. It’s fine when you deal with one single currency and you are most of all concerned with the precision of financial calculations. But what are some other options? let’s find out.
In the previous blog I introduced the gRPC calls and told about the absence of error handling in the model itself. Let’s investigate how this came about.
In the previous blog I started my journey into Protobuf and introduced my first steps by
introducing an example Contract service and some business operations on it.
Now let’s start with diving into details of how to model the gRPC calls.
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….
In a modern service landscape, especially when using containers, you are probably using something like the ELK stack (Elasticsearch, Logstash, Kibana) to flow all the logging into. But how to find from all those loglines what caused the nasty bug after a innocent buttonpress? One of the easy answers to this is what’s called a correlation id - basically a unique number assigned to that buttonpress which gets carried around between the services and added to every logline. Sounds good you say? it is so let’s see how to do this.
