Step 4: Write a Minimal End-to-End Solution

The goal is to test out the overall architecture as rapidly as possible. Make skeleton applications that call the APIs, and skeleton stacks that implement both sides of every protocol. You want to get a working end-to-end “Hello World” as soon as you can. You want to be able to test code as you write it and to weed out the broken assumptions and inevitable errors you make. Do not go off and spend six months writing a test suite! Instead, make a minimal bare-bones application that uses your still-hypothetical API.

If you design an API wearing the hat of the person who implements it, you’ll start to think of performance, features, options, and so on. You’ll make it more complex, more irregular, and more surprising than it should be. But—and here’s the trick (it’s a cheap one, was big in Japan)—if you design an API while wearing the hat of the person who has to actually write apps that use it, you’ll use all that laziness and fear to your advantage.

Write down the protocols on a wiki or shared document in such a way that you can explain every command clearly, without too much detail. Strip off any real functionality, because it’ll only create inertia that makes it harder to move stuff around. You can always add weight. Don’t spend effort defining formal message structures: pass the minimum around in the simplest possible fashion using ØMQ’s multipart framing.

Our goal is to get the simplest test case working, without ...

Get ZeroMQ now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.