TDD, or Test Driven Development, is fairly well acknowledged to be a great idea. The general theory behind it is that you write your tests first, which will initially fail, and then you write just enough code to make the tests pass. Once the tests pass, the code is finished and you can move on to the next bit of functionality. There have been studies done that show that working this way drastically reduces the number of issues in the overall product.

And for some languages, this is all fantastic. You write the tests, the tests fail, you move on to the actual development.

And for yet other languages, this just doesn’t work at all. Specifically I’m thinking compiled, statically typed languages here. The problem with this scenario is, when you write your tests against non-existent types then you break the compilation of the test suite, which in turn breaks every test in the system. And that in turn means that until you’ve implemented at least enough for all of the tests to compile you can’t be sure that you’ve not broken anything else.

Read More

HATEOAS, for anyone who’s not come across it yet, is an additional constraint added on top of normal REST services whereby the only way that clients ever interact with the server is through Hypermedia that the server provides. The server will provide a single starting point, and every single interaction with the server after that is made only through URLs that the server has previously provided to the client. The advantage here is that the server can change independently of the client, and as long as the client only ever follows the URLs provided to it then everything will continue to work correctly.

That all sounds fantastic on the face of it. Completely decoupled evolution of server and client sounds almost idyllic.

Of course, in reality this doesn’t actually work. There are a number of problems with the idea, ranging from the very simple - clients cut corners and just hard-code URLs to specific resources instead of following links - to the very complicated, where changes to the server need to be made that just aren’t backwards compatible.

Read More

I’ve just gone through some of the reasons that I don’t like the Relay API requirements for GraphQL, so lets have a go at designing an API that I do like.

Read More

I’ve started playing with GraphQL again recently, having been looking into various other specifications for HTTP based APIs, and I’ve come to a conclusion. I really like GraphQL, but I don’t like Relay.

Now, don’t get me wrong, there are bits of Relay that I think are really good ideas. But there are also bits that I just think are either a waste of time, or worse actually make the API harder to use.

Read More