The UK currently has a cost of living crisis. Inflation is going through the roof and the only think being done to influence this is to put up interest rates! The argument for this is that if credit becomes more expensive people will reduce what they are spending. Are economists so stuck in 1970’s models that they can see nothing else?

Credit card use is not rising because credit is cheap, they are rising because costs are escalating. Adding to the interest on mortgages and credit cards won’t help control this. This will drive workers to ask for larger pay rises and will fix the interest rate growth as permanent.

Fuel price rises have a massive effect across the whole supply chain. We had protests in the UK when petrol first reached 1 GBP per litre, we are now at around 1.85 GBP.

We have a leadership contest going on between two people who are denying reality and aiming for the votes of a very small electorate. Neither candidate has a sensible plan (or indeed a mandate). One wants to control inflation and the other wants to cut tax.

Still working. through the examples.

Project is at https://github.com/chriseyre2000/absinthe_demo

Currently at df7c52f

Again there is a minor difference in the error message format, and the error is a 200 not a 400.

It’s interesting to see custom modification.

Now at the end of chapter 3

Chapter 4 introduces some useful extra structure, allowing the schema to be broken down into manageable pieces.

The next step will cover unions.

This is my current VSCode settings:

{
    "files.autoSave": "afterDelay",
    "diffEditor.ignoreTrimWhitespace": false,
    "git.openDiffOnClick": false
}

It’s not much but it is a start.

Autosave is a must.
Opening the file from diff is much more sensible than assuming you want the diff.

Not got as far as I had expected on this.

Good note on this book is that the tests are immediately after the code making errors much easier to spot.

I have now looked at https://github.com/steveteuber/kubectl-graph

I was hoping for something more structured than a force directed graph. It’s a good start, but a graph starting at the exposed endpoint and listing the routes to the main service would have been more useful.

One of the first questions I ask about a new technology is can I make it play with graphviz or Neo4j

The second trick is to see if someone else has already solved it.

This time both are true:

https://github.com/steveteuber/kubectl-graph

This is a library that can export k8s setups to either graphviz or to neo4j.

I am still working through this book.

So far chapter 3 seems reasonable. The only change so far is the 200 return type for an error in a query. Previously it had been a 400.

Now at commit 9c83b41 in the repo https://github.com/chriseyre2000/absinthe_demo

We are currently at page 93 of the book (halfway through Chapter 3)

I am now need to get a better understanding of Kubernetes.
For the last few years I have been working with Docker, sometimes deployed to ecs, and before that the very simple Heroku setup.

I have just quickly skimmed through Kubernetes: Up and Running.

So far: minikube is a small one-node Kubernetes setup that can be deployed to a developers machine.

kubectl is the command line tool used to start/stop/scale things.

k8s has its own dns server and a host of self-hosted services. I am also aware that docker is involved.
There is also the important concepts of pods, daemonSets and tags.

The next item to read up on is Helm This seems to be an improved tool for deploying things to K8s.

Back in the year 2000 there was a concept around that could have changed development. WSDL schemas allowed a project to define the contract that a service provided. Admittedly most people reverse engineered this from their existing systems and WSDL generated huge SOAP monstrosities. Having a single source that described a contract for a system really helps with integration. Making the contract a defined versioned item ensures that accidental breakages are less frequent.

In other spaces there were similar solutions that got more useful traction. Google had the problem of a large number of systems that needed to interact. They also used a range of programming languages to do this. Their solution was Protobuf. This is a file format that defines the serialization format for messages. Each service would use Protobuf to define the contract and libraries would generate the code to serialize/deserialize from the wire-protocol. It has strict versioning rules:

• Identifiers cannot be reused (that is the underlying numeric identifier)
• You can add a field to an existing read contract without breaking anything.
• A required field may become optional or repeating, but the reverse is not allowed.
• If you need more changes than the above allows you increment the version of the contract.

Oddly this is also the rules enforced by google BigQuery. Either it is isomorphic to Protobuf or uses Protobuf under the hood!

There are several styles of protobuf clients, some of which are smart enough to allow the generation of deltas. This means that when a large message changes and the client already has the previous version you can only send the updates. This proved to be very useful.

A typical usage of Protobuf is for the client to conform to the contract supplied. However it is a great system boundary and it is possible to use this at the edge of Bounded Contexts to translate field names into local concepts.You can also chose to ignore data that you don’t want.

Avro is a similar tool, typically used in the Kafka ecosystem. Here it is common to keep the schema in a Schema registry. This makes the asymmetric approach more difficult.