Gain insights into clean architecture using Python. Delve into layered systems, design efficient applications, and integrate web components, error handling, and databases with test-driven development practices.

tarball.tar.gz

POSTGRES_USER

POSTGRES_PASSWORD

POSTGRES_HOSTNAME

APPLICATION_DB

POSTGRES_PORT

POSTGRES_DB

Python Execution

Flask

Flask + Postgres

Python Test

Clean architecture is a software design methodology that separates the processes of an application into discrete steps instead of presenting them as “spaghetti code.” With the versatility of Python, software engineers can build performant, modular applications quickly using the Flask framework.

This course will help you build better applications using the principles of clean architecture. You’ll start with an introduction to data flow in clean systems and learn about the advantages of layered architectures. Next, you’ll learn system components and the connections between application layers. You’ll then design and build a clean system using Python by layering components in guided coding exercises. Finally, you’ll learn how to add functional components for the web, handle errors, and work with external databases using both Postgres and MongoDB. At each step, you’ll use test-driven development practices to ensure robust functionality.

Clean Architecture in Python

We need a way to create tables that correspond to the objects defined in `rentomatic/repository/postgres_objects.py`.

# Alembic
 The best strategy when we use an ORM like SQLAlchemy is to create and run migrations. For this, we can use  [Alembic](https://alembic.sqlalchemy.org/).



## Perform migrations using Alembic

First of all, let’s initialize Alembic. In the project’s main directory (where `manage.py` is stored), let’s run the command below:

```
$ alembic init migrations
```

The command above creates a directory called `migrations` that contains Alembic’s configuration files and the migrations that will be created in `migrations/versions`. It also creates the `alembic.ini` file, which contains the configuration values. The name `migrations` is completely arbitrary, so we can also choose to use a different one if we prefer.



## Set environment variable requirement

The specific file we need to adjust to make Alembic aware of our models and our database is `migrations/env.py`.

import os

from logging.config import fileConfig

from sqlalchemy import engine_from_config
from sqlalchemy import pool

from alembic import context

# this is the Alembic Config object, which provides
# access to the values within the .ini file in use.
config = context.config

section = config.config_ini_section
config.set_section_option(
    section, "POSTGRES_USER", os.environ.get("POSTGRES_USER")
)
config.set_section_option(
    section, "POSTGRES_PASSWORD", os.environ.get("POSTGRES_PASSWORD")
)
config.set_section_option(
    section, "POSTGRES_HOSTNAME", os.environ.get("POSTGRES_HOSTNAME")
)
config.set_section_option(
    section, "APPLICATION_DB", os.environ.get("APPLICATION_DB")
)

# Interpret the config file for Python logging.
# This line sets up loggers basically.
fileConfig(config.config_file_name)

# add your model's MetaData object here
# for 'autogenerate' support
# from myapp import mymodel
# target_metadata = mymodel.Base.metadata
# target_metadata = None
from rentomatic.repository.postgres_objects import Base

target_metadata = Base.metadata

# other values from the config, defined by the needs of env.py,
# can be acquired:
# my_important_option = config.get_main_option("my_important_option")
# ... etc.


Through `config.set_section_option`, we add relevant configuration values to the main Alembic INI file section, `config.config_ini_section`, extracting them from the environment variables. We also import the file that contains the SQLAlchemy objects. 

## Configure Alembic
We can find documentation on configuring Alembic  at https://alembic.sqlalchemy.org/en/latest/api/config.html.

Once Alembic is configured, we need to change the `alembic.ini` file to use the new variables as follows:


# the output encoding used when revision files
# are written from script.py.mako
# output_encoding = utf-8

sqlalchemy.url = postgresql://%(POSTGRES_USER)s:%(POSTGRES_PASSWORD)s@%(POSTGRES_HOSTNAME)s/%(APPLICATION_DB)s

[post_write_hooks]
# post_write_hooks defines scripts or Python functions that are run
# on newly generated revision scripts.  See the documentation for further
# detail and examples


The `%(VARNAME)s` syntax is the basic variable interpolation used by `ConfigParser` (see the [documentation](https://docs.python.org/3.8/library/configparser.html#configparser.BasicInterpolation)).

At this point, we can run Alembic to migrate our database. In many cases, we can rely on Alembic’s autogeneration functionality to generate the migrations. We can employ this method to create the initial models. The Alembic command is `revision` with the `--autogenerate` flag, but we need to pass the environment variables on the command line. This is a job for `migrate.py`, but let’s first run it to see what happens to the database. Later, we’ll create a better setup to avoid passing variables manually.


## Autogenerate database versions
Run the command in the code widget below:
```
$ POSTGRES_USER=postgres\
  POSTGRES_PASSWORD=postgres\
  POSTGRES_HOSTNAME=localhost\
  APPLICATION_DB=application\
  alembic revision --autogenerate -m "Initial"
```

This generates the `migrations/versions/4d4c19952a36_initial.py` file. If we want, we can open that file and see how Alembic generates the table and creates the columns.

## Apply migrations

So far, we’ve created the migration, but we still need to apply it to the database. We have to be running the Docker containers (run `python3 manage.py compose up -d`), since Alembic is going to connect to the database and run using the following command in the code widget:

```
$ POSTGRES_USER=postgres\
  POSTGRES_PASSWORD=postgres\
  POSTGRES_HOSTNAME=localhost\
  APPLICATION_DB=application\
  alembic upgrade head
```

# Connect to the database

At this point, we can connect to the `application` database with user `postgres` and check the existing tables using the command below:

```
$ python3 manage.py compose exec db psql -U postgres -d application
/*
psql (13.4 (Debian 13.4-1.pgdg100+1))
Type "help" for help.
*/
application=# \dt
/*
              List of relations
 Schema |      Name       | Type  |  Owner   
--------+-----------------+-------+----------
 public | alembic_version | table | postgres
 public | room            | table | postgres
(2 rows)
*/
application=# 
```

Please note that we use the `-d` option of `psql` to connect directly to the database application. As we can see, we now have two tables. The first, `alembic_version`, is a simple table that Alembic uses to keep track of the state of the `db`, while `room` is the table that contains our `Room` entities.

## Check the Alembic version

We can double-check the Alembic version using the command below:

```SQL
application=# select * from alembic_version;
/*
 version_num  
--------------
 4d4c19952a36
(1 row)
*/
```

As we mentioned before, the hash given to the migration will be different in our case, but the value that we see in this table should be consistent with the name of the migration script.

## Select the `room` table

We can also see the structure of the `room` table below:

```SQL
application=# \d room
/*
                                     Table "public.room"
  Column   |         Type          | Collation | Nullable |             Default              
-----------+-----------------------+-----------+----------+----------------------------------
 id        | integer               |           | not null | nextval('room_id_seq'::regclass)
 code      | character varying(36) |           | not null | 
 size      | integer               |           |          | 
 price     | integer               |           |          | 
 longitude | double precision      |           |          | 
 latitude  | double precision      |           |          | 
Indexes:
    "room_pkey" PRIMARY KEY, btree (id)
*/
```
## Retrieve data from the `room` table
There are still no rows contained in the table. We can check this using the command below:


```SQL
application=# select * from room;
/*
 id | code | size | price | longitude | latitude 
----+------+------+-------+-----------+----------
(0 rows)
*/
```

Indeed, if we open http://localhost:8080/rooms with our browser, we'll see a successful response but no data.

## Data insertion and retrieval in the `room` table

To see some data, we need to write something in the database. This is normally done through a form in the web application and by using a specific endpoint, which makes the insertion of data simple. In our case, we can add data manually to the database by using the command below:

```SQL
application=# insert into room(code, size, price, longitude, latitude) VALUES ('f853578c-fc0f-4e65-81b8-566c5dffa35a', 215, 39, -0.09998975, 51.75436293);
/*
INSERT 0 1
*/
```

We can verify that the table contains the new room with a `SELECT` command:

```SQL
application=# SELECT * FROM room;
/*
 id |                 code                 | size | price |  longitude  |  latitude   
----+--------------------------------------+------+-------+-------------+-------------
  1 | f853578c-fc0f-4e65-81b8-566c5dffa35a |  215 |    39 | -0.09998975 | 51.75436293
(1 row)
*/
```
We can check our output section of the code editor for the updated output.


Let’s learn to perform migrations in databases.

Get Started

A Day in the Life of a Clean System

Components of Clean Architecture

A Simple Coding Example

Add a Web Application

Error Management

Integration with a Real External System Postgres

Integration with a Real External System MongoDB

Run a Production-ready System

Appendix

Migrations

Alembic

Perform migrations using Alembic