This is a simple and straightforward adaptation of the HTCPCP protocol (RFC 2324) implementation using Golang, Docker containers and MVC design pattern.
WEBDAV PROPFIND and XML structures are not used - instead, your coffee is encapsulated in a delicious JSON format.
Speaking of capsules, this app includes a MongoDB container to store the configuration of all your coffee capsules at no cost.
Coffee pots have been replaced by a coffee-machine.
Thanks to the magic of Docker containers, deploying a coffee-machine is very simple.
A Dockerfile is provided, along with a docker-compose.yml file.
The Dockerfile uses a multi-stage approach to building all the necessary golang binaries into a super lightweight docker image (cca 22 MB).
The docker-compose.yml file declares 2 services, one for the coffee-on-the-go app and one for the mongo-db.
To deploy and start your very own coffee-machine, run the following command at the root folder of this repository:
docker-compose up -d
To verify the appropriate installation, run the following command:
docker container ls
You should see an output similar to the following:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f760adbaf0e5 coffeeonthego:v1.0 "./..." About an hour ago Up About an hour 0.0.0.0:8080->80/tcp coffee-on-the-go
6084b7c26084 mongo:3.4.23-xenial "docker-entrypoint.s…" About an hour ago Up About an hour 27017/tcp mongo-on-the-go
As you can see, the Mongo-DB container is named mongo-on-the-go and runs on port 27017. The coffee-machine container is named coffee-on-the-go and is mapped to the host's port 8080.
If you wish to customize configurations such as the container names and assigned ports, you can change these settings in the docker-compose.yml file.
As per the HTCPCP protocol implementation, both BREW and POST reques methods are supported. For the purpose of this documentation, they are to be taken as synonyms.
Coffee capsules undergo a slightly different process of preparation, but to maintain compatibility with the HTCPCP protocol we are keeping the BREW/POST nomenclature.
The coffee-machine has 2 possible states when it comes to processing capsules:
- start - add the capsule to the coffee-machine
- stop - stops the coffee-machine
Web forms are too formal - brewing coffee should be as easy as C U R L.
The BREW request body must contain a "coffee-message" field with either "start" or "stop" value, which determines what action the coffee-machine should take.
You can send as many BREW requests as you want (as long as you don't exceed your daily caffein limit).
Below you can find an example of a valid BREW request (the "flavor" field is optional and defaults to "traditional", if none is provided):
curl -X BREW http://localhost:8080/coffee/brew \
-H 'Content-Type: application/json' \
-d '{"flavor":"vanilla-sky", "coffee-message":"start"}'
An associated ID is generated for you whenever you send a request to start brewing coffee.
When you feel like your coffee is ready, to stop the coffee-machine, you must first provide the ID of the coffee capsule, along with a "stop" coffee-message.
Failing to do so yields no result, and can potentially damage the coffee-machine and cause leakings.
Below you can find an example of a valid BREW request to stop the coffee-machine (both the "id" and "coffee-message" fields are required):
curl -X BREW http://localhost:8080/coffee/brew \
-H 'Content-Type: application/json' \
-d '{"id": "${bson_id}", "coffee-message":"stop"}'
As previously mentioned, all the relevant coffee meta-data is stored in a Mongo-DB database.
The db name is coffeeshop and the collection name is coffee.
Coffee capsule data is stored in the following way:
| field | description | optional |
|---|---|---|
| ID | capsule id | no |
| Flavor | capsule flavor | yes |
| PreparationState | preparation state | yes |
| CoffeeMessage | sets the preparation state | no |
The PreparationState field is controlled by the CoffeeMessage field and any attempt by you to set the PreparationState via request body is overriden by the CoffeeMessage.
To get meta-data for a particular coffee capsule, all you need to do is send a GET request, setting the id as a parameter.
Below you can find an example of a valid GET request (needless to say, the "id" parameter is required):
curl http://localhost:8080/coffee/get?id={$bson_id}
Conversely, if you do not provide any id, the coffee-machine returns a list of all coffee capsules which have been requested.
Below you can find an example of such transaction:
curl http://localhost:8080/coffee/get
For a better user experience, use your web browser instead of CURL. Fresh go templates are served with your coffee.
As you know, teapots differ from coffee pots and coffee machines.
The /coffee/ route is the only safe way to brew and get coffee.
Any attempt to use a /teapot/ route results in http status code 418.
Below you can find an example of an unadverted attempt to use teapots to brew coffee:
curl http://localhost:8080/teapot/
Again, for a better experience, use your web browser instead of CURL.
If you want to check in real time how the data is populated into the database, you can connect to the database container through the following command:
docker exec -it mongo-on-the-go /bin/bash
Then, once inside the container, run the following command:
mongo -u ${user} -p --authenticationDatabase admin
Provide the password (as specified by the docker-compose.yml file) and TA DA! You are connected to the database.
Up next, let's do a simple query.
use coffeeshop
db.coffee.find().pretty()
The command above should output all the coffee capsules recorded into the database and confirm that it is, indeed, working.
Read on for more insightful Mongo commands.
Check out this article HERE for further information on how to package multiple libraries in Golang.
Check out THIS article for more interesting mongo commands and database queries.