Introduction | Backend | Fluid Attacks Help


codecov - backend

Integrates' backend is an HTTP web service written in Python, served with Hypercorn and built with Starlette.


  • Functional: The codebase favors functions over classes and avoids direct mutations.
  • No need to reinvent the wheel: Leveraging third-party packages when available.

Getting started

To view changes reflected as you edit the code, you can run:

  m . /integrates


The back uses Prospector and Mypy to enforce compliance with a defined coding style.

To view linting issues, run:

  m . /lintPython/dirOfModules/integrates/name of the module

To view and auto-fix formatting issues, run:

  m . /formatPython/default


The back-end uses pytest as a test runner.

To execute unit tests on your computer, run:

  m . /integrates/back/test/unit 'changes_db'
  m . /integrates/back/test/unit 'not_changes_db'

To execute a functional test on your computer, run:

  m . /integrates/back/test/functional 'name of the test'


The back-end codebase consists of several modules, classified into three layers: API, business logic, and data access.

Web server

The back-end is served by Hypercorn, a program with two sides:

  • 🌐 On one side it speaks the HTTP protocol, receiving requests and sending responses.
  • 🐍 On the other it speaks Python (ASGI), passing request data to Python code for processing.

This is lower-level functionality is challenging to build an application directly on top of, which is where Starlette comes in handy.

Starlette abstracts requests handling, and provides utilities for building web applications, such as declaring routes, middlewares, and managing sessions and cookies.

API layer

This layer provides an external interface for interacting with services implemented as a GraphQL API. You can learn more here.

You can find it in the back/src/api directory.

Business logic layer

Implements core functionality of the application, processing inputs and producing outputs based on business requirements.

You can find it across modules in files usually named

Data access layer

Declares the structure of each entity used in the application and interacts with database-specific modules to read from and write to a data store.

It provides functions to perform CRUD operations for each entity, taking care of batching and caching using dataloaders. Designed to be agnostic fir easy swapping of the underlying data store.

You can find it in the back/src/db_modelback/src/dynamodb and back/src/search directories.