Simple Nginx-Uwsgi-Daphne reactive application. Part 1. The Big Picture.

Based on my hard process of learning how to build web applications, I’ve worked out an efficient learning strategy for myself. Basically, I realized that I cannot efficiently operate a project’s “big picture” in my head until I draw a nice scheme.

Creating a reactive web application that efficiently coordinates several docker services is not a trivial task. Celery periodic tasks can play crucial role in such orchestrations. For the project that I present here, I’ve come up with a lottery periodic task that randomly chooses a winner. The winner should get a coin and a notification on the frontend after each win. I consider Django Channels technology to be one of the best choices for such notification system.

Taking into account Django, Django Channels and Celery technologies, we can consider Nginx-uWSGI-Daphne-Celery docker services orchestration to be the core of our application. I would like to start form showing the scheme that I’ve built for this core.

Simple Nginx-Uwsgi-Daphne-Celery web app structure. The big picture.

In this application, which I named “Game Economy”, user interaction happens via browser as in any standard web application these days. To see a big picture of the project, we should clearly understand what happens when user start interacting with the app. On the top of the scheme it is shown that after the interaction via the address bar, browser can perform three different actions:

1. Fetch static files (Indicated by pink color). It is important to understand that static files (css, js, fonts files etc.) are usually fetched to the browser by Nginx directly from the file system. For this reason such files can be stored separately from the python source code in a location that allows quick and convenient fetch.
2. Open websocket (Showed by blue arrows). It is common practice to open a websocket connection with javascript code once the code is loaded. Such connections stays open as long as the page is open. Please, note, in this case the connection to Nginx is happening via websocket protocol.
3. All the requests with url not starting from ‘/ws/’ or ‘/static/’ are going to be redirected by Nginx to uWSGI server and processed by Python code. Python source code (Django) receives the request and renders the template to produce web document (initial html code, first red arrow).

These three actions usually happen at the same time, and user sees nice rendered page. The next step is letting user see the change in balance and a message with congratulations after each lottery win. Celery workers are commonly used for handing the code of such periodic tasks. Python code in the task chooses the winner and saves the record in the corresponding channel layer (this process is indicated by the green color in the scheme). The layers are accessible by Daphne and result of a lottery is sent to the browser as soon as it appears in layers. Finally, browser receives the message with the updated balance via websocket protocol and shows it as a pop-up (please see the picture below).

Pop-up message received by websocket protocol.

Now we see the big picture of this project and this is only the beginning. In the following stories I will make a detailed description of the other important parts of the Game Economy application and describe the steps required for the successful building.

All the code with all other services can be found in this repository. Please take a look at the deployed version of the app here.