Backend Style Guidelines
This is a list of statements that describe how we do backend development in Superset. While they might not be 100% true for all files in the repo, they represent the gold standard we strive towards for backend quality and style.
- We use a monolithic Python/Flask/Flask-AppBuilder backend, with small single-responsibility satellite services where necessary.
- Files are generally organized by feature or object type. Within each domain, we can have api controllers, models, schemas, commands, and data access objects (DAO).
- API controllers use Marshmallow Schemas to serialize/deserialize data.
- Authentication and authorization are controlled by the security manager.
- We use Pytest for unit and integration tests. These live in the
testsdirectory. - We add tests for every new piece of functionality added to the backend.
- We use pytest fixtures to share setup between tests.
- We use SQLAlchemy to access both Superset's application database, and users' analytics databases.
- We make changes backwards compatible whenever possible.
- If a change cannot be made backwards compatible, it goes into a major release.
- See: Proposal For Semantic Versioning
- We use Swagger for API documentation, with docs written inline on the API endpoint code.
- We prefer thin ORM models, putting shared functionality in other utilities.
- Several linters/checkers are used to maintain consistent code style and type safety: pylint, mypy, black, isort.
__init__.pyfiles are kept empty to avoid implicit dependencies.
Code Organization
Domain-Driven Structure
Organize code by business domain rather than technical layers:
superset/
├── dashboards/
│ ├── api.py # API endpoints
│ ├── commands/ # Business logic
│ ├── dao.py # Data access layer
│ ├── models.py # Database models
│ └── schemas.py # Serialization schemas
├── charts/
│ ├── api.py
│ ├── commands/
│ ├── dao.py
│ ├── models.py