Django structure for scale and longevity
Aug 18 2021Why?\n\nDjango is great.\n\nBut as we add new features, as our dev team grows and the software needs to be stable on production, things can get quite messy.\n\nWe are going to look at some common patterns, derived from experience, on how to structure your Django project for scale and longevity.\n\nWhat?\n\nMain topics are:\n\n\nDjango service layer or where should business logic live?\nUsing Django Rest Framework in a clean and repeatable way and combining it with the service layer.\nTesting everything that matters, without repeating ourselves in different tests.\n\n\nWe 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.\n\nThe examples showed in this talk are derived from working with Django in the last 5 years on projects with:\n\n\nDaily production usage and production deploys.\nDozens of apps.\nHundreds of models and APIs.\nTens of integrations working simultaneously.\nTeams of 5 to 10 people.\n\n\nWho?\nKey takeaways from the talk:\n\n\nIncreased productivity when developing with Django.\nDeeper understanding of the software development process with Django.\nDemo project with everything mentioned in it.\n\n\nThe talk is great for all levels of Django knowledge - from beginners to advanced users and teams.\n\nHow\n\nThe 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.\n\nBreakdown of the talk:\n\n\nDjango service layer:\n\nFat models or fat views?\nWhere do I put my business logic?\nWhat is a service and what goes into a service?\nWhat is a selector and what goes into a selector?\n\nGeneral Django structure:\n\nHow many apps should I have?\nStructuring your code so youр team can be more productive and have less conflicts.\nCommon modules and utilities.\n\nDoing APIs with Django Rest Framework:\n\nSplitting APIs in 2 groups - "giving data" and "taking data"\nUsing a lot of generics for "give data"\nWhen do to selectors?\nUsing no generics for "take data" (APIView + Services)\nHandling errors from services\nInlining serializers and avoiding serializers reuse\nA neat inline_serializer util\nIntroducing general error formatting for your API\n\nTesting all of that - what should be and not be tested?