This page is a stub.


At present:

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

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

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

  • Each service’s Docker Compose file defines the containers for the backend, frontend and workers (if any).

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)