Django structure for scale and longevity
Why? Django is great. But as we add new features, as our dev team grows and 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 and repeatable way and 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 and 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 and production deploys. Dozens of apps. Hundreds of models and 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 and teams. How The main way of getting the point across is going to be by showing regular code, talking how it can get messy and 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 and what goes into a service? What is a selector and 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 and 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 and avoiding serializers reuse A neat inline_serializer util Introducing general error formatting for your API Testing all of that - what should be and not be tested?
Aug 18 2021