This page is a stub.


At present:

  • Each of our services can run on a single server.

  • A service has at most 2 repositories: backend and frontend, excluding non-service dependencies.

  • A service’s codebase has at most 3000 relevant lines, according to Coveralls.

  • A service’s Docker Compose file defines the containers for the backend, frontend and any workers.

When using Django, the workers are written as Django management commands. In other cases, the workers are written as Click commands, sharing code with other commands.

In other words, nothing is a microservice, where a microservice means a sub-service that is developed and deployed independently of others, as part of a service.

Instead, we achieve loose coupling and proper encapsulation by other means: dividing program logic by UI responsibility (e.g. Model Template View); organizing a set of features into an application, when using Django; and otherwise organizing code carefully.

Fat models

If a function performs CRUD operations and accepts only a database session and instance values as arguments, add this function as a method on the model’s class.

Code smells for skinny models:

  • Calling database session methods outside a model’s class (for example, COMMIT)