We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Django structure for scale and longevity

Formal Metadata

Title
Django structure for scale and longevity
Title of Series
Number of Parts
132
Author
License
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
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?