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.

ASAB Architecture
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, use it in your own software or, even better: contribute to it. You can get in touch with us at or on Gitter chat. We will be happy to hear your thoughts and feedback!

Continue to next article

About the Author

Premysl Cerny

Software Developer at TeskaLabs

You Might Be Interested in Reading These Articles

SeaCat Tutorial - Chapter 5: Using with REST Integration (iOS)

As the market with Cloud Computing and Mobile devices is getting bigger, there is another specific option available. It's called (Mobile)Backend-As-A-Service (BAAS) and it is extremely useful in situations we want to subscribe a complex backend service (alongside the core backend solution, there is usually a lot of additional functionality and statistics) and primary focus on development of client part of mobile apps for instance.

Continue reading ...

tech tutorial ios osx

Published on January 31, 2015

5 Things to Look for in an Enterprise Mobile Development Platform Solution

Today many enteprises are looking to have their own mobile applications. With the right solution, you can build a mobile app that will fit your organization’s needs like a glove and be in the driver’s seat of the development.

Continue reading ...

mobile development

Published on September 01, 2015

Entangled ways of product development in the area of cybersecurity #3 -

At that time I lived in Prague for a short time, which is not a very friendly place to live, but it allowed me to go to the office almost every day. A bigger surprise awaited Vlaďka and Aleš when I told them that I was going to move to a house almost eighty kilometres from the office and that I would need to be mainly at the home office.

Continue reading ...

development tech premek

Published on January 15, 2023