Beer tap dispenser API

Anyone who goes to a festival at least one time knows how difficult is to grab some drinks from the bars. They are crowded and sometimes queues are longer than the main artist we want to listen!

That's why some promoters are developing an MVP for new festivals. Bar counters where you can go and serve yourself a beer. This will help make the waiting time much faster, making festival attendees happier and concerts even more crowded, avoiding delays!

How it works?

The aim of this API is to allow organizers to set up these bar counters allowing the attendees self-serving.

So, once an attendee wants to drink a beer they just need to open the tap! The API will start counting how much flow comes out and, depending on the price, calculate the total amount of money.

You could find the whole description of the API in the OpenAPI description file and send request to a mock server with this URL

Workflow

The workflow of this API is as follows:

Admins will create the dispenser by specifying a flow_volume. This config will help to know how many liters of beer come out per second and be able to calculate the total spend.
Every time an attendee opens the tap of a dispenser to puts some beer, the API will receive a change on the corresponding dispenser to update the status to open. With this change, the API will start counting how much time the tap is open and be able to calculate the total price later
Once the attendee closes the tap of a dispenser, as the glass is full of beer, the API receives a change on the corresponding dispenser to update the status to close. At this moment, the API will stop counting and mark it closed.

At the end of the event, the promoters will want to know how much money they make with this new approach. So, we have to provide some information about how many times a dispenser was used, for how long, and how much money was made with each service.

⚠️ The promoters could check how much money was spent on each dispenser while an attendee is taking beer! So you have to control that by calculating the time diff between the tap opening and the request time

What are we looking for?

A well-designed solution and architecture. Avoid duplication, extract re-usable code where makes sense. We want to see that you can create an easy-to-maintain codebase.
Test as much as you can. One of the main pain points of maintaining other's code comes when it does not have tests. So try to create tests covering, at least, the main classes.
Document your decisions. Try to explain your decisions, as well as any other technical requirement (how to run the API, external dependencies, etc ...)

This repository is a Python skeleton with Django & PostgreSQL designed for quickly getting started developing an API. Check the Getting Started for full details.

Technologies

Getting Started

Within the Makefile you can handle the entire flow to get everything up & running:

Install make on your computer, if you do not already have it.
Build the Docker image: make build
Migrate any DB pending task: make migrate
Start the application: make up

Technical Decisions

Packages installed

drf-yasg swagger implementation easy to implement on Django projects, api docs available on -> http://0.0.0.0:5050/, this library was used to generate api docs

the api docs contains the schemes for all the projects

factory-boy to create mocked data using django models through factories
django-extensions for the aliases of the urls (to use reverse('api:url') instead of /api/url'), because is safer than use the link in the code, this package was used just on development (already removed)

aliases of urls in the console

pyproject.toml after finish development

Commands added

static command was added to the make file and to the up command also because we need to run this commands to see the api docs that requires static files