Cocktail Maker: Software Architecture

As mentioned earlier the hardware side of the cocktail maker will be controlled by a Raspberry Pi with a user interface running on an Android tablet. The Raspberry Pi will make interacting with the valves simple via it’s builtin GPIO ports while the Android interface will mean we can have a nice touchscreen based client.

For ease of development the two devices will likely communicate with a RESTlike API. Luckily enough I’ve recently been working on a major plan at work involving a substantial bit of work to do with RESTifying our current API. In both cases this will probably be the popular conception of REST, ignoring the Hypertext As The Engine Of Application State (HATEOAS) constraint.

There is actually two mostly distinct sets of resources that the server will have to provide for the client. The majority of the resources will be a generic collection of cocktails with pictures, descriptions, recipes etc. Then there will also be the resources specific to the cocktail maker, list of available ingredients to allow filtering the cocktails, calibration information¹, current processing state, starting and canceling the current task. The first of these sets is also very widely applicable, anyone and everyone² could be interested, including other people building automated cocktail makers.

For that reason I’ve decided to separate the cocktail database from the main cocktail maker server. I haven’t been able to find any appropriate databases existing so I’ve taken it upon myself to create the first online crowd-sourced cocktail database. I’m hoping to have a very basic version up within a few months, the work on it will obviously be sporadic seeing as it is a part-time after work project. Actual time frame will probably depend a lot on how much stuff I get up to in America, if I find there’s not really that much to do in Austin I may end up spending a large part of most evenings working on it.³

As part of developing this database I do want to experiment with HATEOAS, especially HATEOAS as implemented via JSON. There are some really good examples of how to implement it in XML using the rel attribute for metadata about the resource. There are also a few libraries that do attempt to implement it with JSON, but just from what little I’ve seen of the libraries something seems off with them. Once I get some time to research the current libraries, I’ll try and write a post about what it is that bugs me about them and how I’m going to try and avoid the issues in my implementation.

In the meantime we’ll probably have a simple hardcoded list of cocktails to use. Worst case we’ll just be stuck drinking Tom Collins’ continuously.⁴

---

1. Especially if the pipes flow rate is affected by viscosity, sugar syrup can be a few hundred to over a thousand times as viscous as water. ↩

2. Above the legal age for alcohol consumption in their country. ↩

3. What’s the chance of that in The Live Music Capital of the World. ↩

4. I could think of much worse things in life than a nigh unlimited supply of automatically prepared Tom Collins’ *Cough*kscrew . ↩