The Birth of Application Server Boilerplate
One of the most exciting tasks for our team in the last month was to create a new application server “boilerplate” that would be used as a basis for most of our growing data-processing products, as well as for other people and companies who are interested in implementing an asynchronous server in Python to their products. And, as you will learn, the result lies beyond our original expectations.
First, it is important to know that we were facing difficulties in deciding what to do with the backend of the SeaCat Admin Panel and the Black Swan Pump (aka BSPump), which started to go in separate directions, each with its own application background. Both of them are successful products focused on asynchronous and secure data processing, which need to be carefully maintained in order to stay up-to-date and allow us to promptly respond to our clients when an anomaly or other incident occurs.
After a series of discussions, the decision was finally made by our leader, Ales, who suggested we do a common one-day workshop to create an application server, which is then going to be used by most of our products and utilize most of today’s asynchronous programming capabilities. After a brainstorming session, the meeting for the workshop was planned and appointed.
Picture: ASAB Architecture
When the workshop started at our TeskaLabs Prague office in the morning (around 10 AM), we (the four developers on the Green Team) were all working together to create the basic application object, which would then hold other modules and services that every right application boilerplate needs. Personally, I then decided to create a publish-subscribe messaging object that would notify registered listeners from other components when a specified event occurred, i.e., if the application was initialized, the output data queue is full, etc.
In the meantime, other developers from our Green Team were assigned tasks to create the remaining basic components. Mila took care of the logging object, which is particularly necessary for our ITGuard product. Honza was focusing on the configuration object, which would keep settings of all the application’s components. When we were coding the application, Ales explained to us how the asynchronous part of the application is going to be implemented. We were having quite a fun time trying to manage all the asynchronous coroutines that are crucial for future implementations of real-time stream processors.
From day one, we decided to implement this piece on the GitHub as an open-source project so you can see our progress in Git history :-) Personally, I enjoyed the coding and testing of the publish-subscribe class together with all the coroutines, awaits, and other Python asyncio stuff. Our job was proceeding surprisingly smoothly, especially since we were helping one another.
After a few days, using our freshly baked Asynchronous Server Application Boilerplate (ASAB), we started implementing the Black Swan Pump—the big data real-time stream processor, which is open-source and public as well. Not only was expanding the ASAB to match the BSPump needs successful, it was also fast and organized to the extent that an outsider programmer might immediately learn what all the newly created modules and services actually do.
When a new version of Python or its libraries is available, it is just a matter of seconds to modify necessary dependencies in the ASAB section and all of our products will be instantly updated. The asynchronous part is also fast and can be instantiated on multiple CPU cores or even computers. That’s the advantage of modern asynchronous programming, which dwells in the fact that there is no need to spend time and computing resources on handling race conditions, deadlocks, and other pesky confusing stuff that goes with parallel thread programming. I was surprised how easy it had been to create such a flexible and modern boilerplate that can be used by lots of successive products.
You now probably excited to learn more about what we have been doing with the ASAB server, so next time I will focus on the previously mentioned BSPump project, how it came to be, along with related stream data analysis, transformations, and data mining.
If you are more interested in the ASAB boilerplate and its features, please see our code at GitHub https://github.com/TeskaLabs/asab, use it in your own software or, even better: contribute to it. You can get in touch with us at email@example.com or on Gitter chat. We will be happy to hear your thoughts and feedback!
Continue to next article
You Might Be Interested in Reading These Articles
Using scalable and reliable software is vital for the success of any large-scale IT project. As increasing numbers of transactions are made, application infrastructure needs to stand strong and support that growth, and not be another source of problems.
Published on January 17, 2017
What compiled language for a backend development is the right one to move our technological stack to the next level? We've started to look around for a compiled computer language that will enable us to build microservices with higher performance. Now, don't get me wrong, we don't depart from Python at all. It is the extension of the portfolio.
Published on November 15, 2021
I've recently received an interesting question from one software architect: Why should he consider embedding SeaCat in his intended mobile application? This turned into a detailed discussion and I realised that not every benefit of SeaCat technology is apparent at first glance. Let me discuss the most common challenges of a software developer in the area of secure mobile communication and the way SeaCat helps to resolve them. The initial impulse for building SeaCat was actually out of frustration of repeating development challenges linked with implementation of secure mobile application communication. So let's talk about the most common challenges and how SeaCat address them.
Published on April 16, 2014