Dockerizing Flask and Celery with Microservice Project Architecture Part I: The Core

Background

Dockerizing Flask and Celery with Microservice Project Architecture Part I: The Core - When I created API for my project and integrated it with celery and docker, I didn’t find a suitable reference to create a scalable project structure and apply the SOLID principle, until I found the 12 Factor App methodology.

I read about Django Golden App in Daniel Roy Greenfeld’s Two Scoop of Django 3 book, I applied the concept using flask + flask-restx + celery and automation using makefile and docker-compose to fit the 12-factor app methodology.

Why Use Django Golden App in Flask?

I use the Django golden app because its structure is easy to understand and implement the twelve-factor app, and scalable.

Getting Started

for the first step, create a repository on GitHub or fork this repo https://github.com/perymerdeka/flask-microservice-boilerplate

repository

The Core Application

The core Application is a core of a project and is used as a controller of a project let’s check the project structure

project structure

The Breakdown

Let’s break down the project structure to understand how it works and how to modify that and use it for your work project

The Core Modules

the core modules are used to control your main application for example there are many sensitive files to configure and used to integrate various libraries and modules that will be used in applications using either monolithic or microservice architecture.

Let’s take some example implementation of the project

GitHub - perymerdeka/news-portal-flaskr: Remote Worker Indonesia Live Coding Project

take a look at the core module

core modules

The Config file

The Config file is a core configuration on flask applications, on this project the sample configuration is on the database and celery

config file

The Factory

factory file is a runner of web services on the flask, based on documentation https://flask.palletsprojects.com/en/2.2.x/patterns/appfactories/

there are a couple of really nice ways to further improve the experience. A common pattern is creating the application object when the blueprint is imported. But if you move the creation of this object into a function, you can then create multiple instances of this app later.

So why would you want to do this?

1. Testing. You can have instances of the application with different settings to test every case.
2. Multiple instances. Imagine you want to run different versions of the same application. Of course, you could have multiple instances with different configs set up in your web server, but if you use factories, you can have multiple instances of the same application running in the same application process which can be handy.

Let’s see the sample below

the factory code

The Extension

Extension used by the app to integrate third-party packages with the application