Representing State in Rest

13 Sep 2017

Representing state is a complex thing. […] When you ask the clients to infer state from the fields alone, they often infer things differently.

We tell the clients that if there is no paid date, then it has not been paid, and the same logic applies for sent. […] Inferring states from dates or other arbitrary fields is awful, and it always goes wrong.

The data can be stored like this in the database, but exposing it in the contract is begging for trouble, as clients will always end up with a slightly different picture of the current state.

“Hypermedia As The Engine Of Application State” is […] what makes a REST API so powerful […] as a collection of affordances (potential actions that can [be] taken).

http://philsturgeon.uk/api/2017/06/19/representing-state-in-rest-and-graphql/

Understanding .NET Standard

21 Jun 2017

NATS Streaming Server

30 Apr 2017

When attempting to design microservices on windows, you inevitably want to use a tool that only runs on *nix. This lead me down the path of wanting to run windows and linux containers side-by-side.

While watching a video on running a hybrid docker swarm, the speaker mentioned he was using NATS as a message queue. In a windows container.

NATS is a highly performant, extremely lightweight, open source messaging system written in Go.

NATS streaming adds reliable streaming to NATS core.

So, if you are in the market for a message queue for your microservices architecture, be sure to give NATS a spin!

Learn how to design large scale systems

21 Mar 2017

Learning how to design scalable systems will help you become a better engineer.

System design is a broad topic. There is a vast amount of resources scattered throughout the web on system design principles.

This repo is an organized collection of resources to help you learn how to build systems at scale.

https://github.com/donnemartin/system-design-primer/blob/master/README.md

Reducing work using pull request refs

16 Mar 2017

Refspecs are cool and you should not fear them. They are simple mappings from remote branches to local references, in other words a straight forward way to tell git “this remote branch (or this set of remote branches), should be mapped to these names locally, in this name space.”

http://blogs.atlassian.com/2014/08/how-to-fetch-pull-requests/

To checkout a pull request locally:

git fetch origin +refs/pull-requests/your-pr-number/from:local-branch-name

Or add the refspec that will map remote pull requests heads to a local pr name space. You can do it with a config command

git config --add remote.origin.fetch '+refs/pull-requests/*/from:refs/remotes/origin/pr/*'
git fetch origin
git checkout pr/1