Django structure for scale and longevity

Why

Django is great.

But as we add new features, as our dev team grows & the software needs to be stable on production, things can get quite messy.

We are going to look at some common patterns, derived from experience, on how to structure your Django project for scale and longevity.

What

Main topics are:

• Django service layer or where should business logic live?
• Using Django Rest Framework in a clean & repeatable way & combining it with the service layer.
• Testing everything that matters, without repeating ourselves in different tests.

We are going to talk about when to rely on existing abstraction so it’s actually helpful & when to avoid existing abstraction, and code things ourselves.

The examples showed in this talk are derived from working with Django in the last 5 years on projects with:

• Daily production usage & production deploys.
• Dozens of apps.
• Hundreds of models & APIs.
• Tens of integrations working simultaneously.
• Teams of 5 to 10 people.

Who

Key takeaways from the talk:

• Increased productivity when developing with Django.
• Deeper understanding of the software development process with Django.
• Demo project with everything mentioned in it.

The talk is great for all levels of Django knowledge - from beginners to advanced users & teams.

How

The main way of getting the point across is going to be by showing regular code, talking how it can get messy & then following up with examples of improving that code. Hopefully this talk will start a lot of discussion afterwards.

Breakdown of the talk:

• Django service layer
  • Fat models or fat views?
  • Where do I put my business logic?
  • What is a service & what goes into a service?
  • What is a selector & what goes into a selector?
• General Django structure
  • How many apps should I have?
  • Structuring your code so youр team can be more productive and have less conflicts.
  • Common modules & utilities.
• Doing APIs with Django Rest Framework
  • Splitting APIs in 2 groups - “giving data” and “taking data”
  • Using a lot of generics for “give data”
  • When do to selectors?
  • Using no generics for “take data” (APIView + Services)
  • Handling errors from services
  • Inlining serializers & avoiding serializers reuse
  • A neat inline_serializer util
  • Introducing general error formatting for your API
• Testing all of that - what should be & not be tested?