For the past 20 hours, I have been trying to pick up Firebase Firestore and to build a queue system consisting only the View-layer of a typical MVC/MVT architecture, which is named ‘Schlange’. Schlange is a queue system that works similarly to the one we typically encounter in banks, government agencies, etc. However, instead of getting a small piece of paper with your queue number on it, you now capture your queue number from the screen.
I build Schlange primarily for these purposes:
There are 3 views of Schlange, a Display Panel view, an Agent view and a New Number Panel. The left window is the Display panel showing the queue to be served. The top right window is the Agent view for queue server and the top bottom right window is the panel for users to request for queue number.
Whenever a new queue number is requested (by using the New Number Panel at the bottom right window), a read of latest next queue number is performed, the number is then enqueued into the ‘pending’ list. The ‘pending’ list is reflected in the ‘Next’ column of the display panel. Simple enough.
My focus is not on the queue system but its architectural design.
In the case of Schlange, Vue.js is used as the View-layer framework. For real-time data store, I use Firebase Firestore. The users of Schlange interact with the 3 panels of Schlange and any IO operation to the data store is handled by the panels themselves.
In Schlange, a new number request is a ‘creation of element’ in the ‘pending’ list. In Firestore, there isn’t any straightforward way to store a list. Instead, the ‘pending’ list is stored as a Firestore Collection. The real-time synchronicity of Firestore allows any changes to be reflected in no time. Since there is no complex logic in Schlange, the logic to perform this operation doesn’t have to be separated. Oh! It’s fat-client-thin-server architecture!
These are the data models of Schlange.
"pending":{ 1005: { "number": 1005 }, 1006: { "number": 1006 }}"serving":{ 1004: { "number": 1004 }, 1003: { "number": 1003 }}"served": { 1002:{ "number": 1002 }, 1001: { "number": 1001 }}
To enqueue, simply add a new Document into Firestore so the “pending” collection looks like:
"pending":{ 1005: { "number": 1005 }, 1006: { "number": 1006 }, 1007: { "number": 1007 }}
Whenever there is an update to the data store, it will be synchronized to the display panel.
You can learn about the data model in Firestore from their documentation.
A data-centric application is an application that relies heavily on the connection to a database. Schlange is nothing different from many conventional systems dealing with data all the time. If there is a network failure, the disconnect of the data store is going to break the system. Therefore, the weakness of a data-centric is pretty obvious. Once the connection is down, the system is down.
According to Martin Fowler’s explanation on Serverless architecture, he describes a serverless application as an application that runs its logic in a stateless container or application that uses vast ecosystem of cloud accessible databases or services. He even exemplifies it with a client application that interacts directly with the data store. So, Schlange is one of it.
I will be posting this topic in near future and I will add a link here once it’s done. Stay tuned! 😊
So, these are what I’ve learnt based on my purposes:
I have posted about promisifying callback API in a native way, you can check it out here.
You can find the demo at http://schlangeplayground.herokuapp.com.
Your clap will definitely drive me further. Give me a clap if you like this post.