How to Design and Plan a Simple Live Notification System
In this and the next post, I will discuss how to use Django channels to implement “push based” user notification and content update function in a Django framework based application. Unlike all my past posts, I have decided to break it into two parts: the first part is for the planning and the second part will discuss the specific implementation. In this post, I will focus on goal gathering and tasks creations by using the user-story map as a methodology which is often used by many of Agile processes.
Planning
Goal
Our goal is to make a simple live notification system that can send, receive, and show new messages lively.
Design and Architecture
The main architecture can be split into two components. One is the publisher. The other is the subscriber. Publisher can be either implemented in the Django application through a WSGI server or developed outside of the application (e.g., a simple script). Publisher sends messages to the channel layer for which we are going to use Redis. Subscriber is implemented in the application through an ASGI server and watches messages on the channel layer. The user interface renders the message in whichever form it should be. In our case, it would increase the number in the badge by 1. The architecture is illustrated below.
Map User Stories
We are going to map from IT’s perspective. Thus, the user is IT.
Based on the goal, two activities “Build publisher”, and “Build subscriber” can be created. An activity represents a high-level task. I think we need three more activities. They are “Design”, “Production practice” and “Deployment”. Ok. Activities are done. Actually, we’ve completed the design activities in the previous section.
Next, we need to brainstorm and write down detailed tasks/stories. Align them in order underneath each activity. On top of that, each detailed story needs acceptance criteria. For example, the acceptance criteria for “Configure application for setting up Django channels” could be 1. Update channels in the requirements.txt 2. The application can route ASGI request. While in the Agile practice the acceptance criteria are part of a user story, I don’t think it is required since the story title sometimes can explain itself obviously. Thus, let’s reduce some administrative work here. =)
Finally, we draw a horizontal line that represents the scope of MVP (minimum viable product) or different phases. In our case, everything above the line is going to be built in this article. Everything below the line is for phase 2 that we can work on in the future.
The result of the story maps is illustrated below. I use CardBoard to draw it. Note that the number in the brackets is a story point which represents the amount of effort to complete it. I use a scale of 1–5. In the real world, those detailed stories will be managed in an Agile tool like Jira. If you prefer the old-school, then sticky notes and a whiteboard should work too. If you are a project lead/manager, you may tag stories so that it’s easy to group them for various purposes. Some scenarios I can think of are to produce reports for the executive team and financial department.
Recap
In this article, we went through task planning and requirement gathering. I have also demonstrated the process of user-story mapping. We discussed the design and tech architecture as well. These are the processes, methodologies, and approaches we have been using in our organization. I would love to hear from you on what processes and methodologies you are using in your development process. Let me know how you would plan this project. Please feel free to leave your comments. Finally, I would like to thank our team since adapting a successful engineering process takes the entire team’s effort. Thanks for reading.