Hello, Django community! I’ve just been through the awesome “polls” tutorial series, and now I’m starting my first real project- a family tree website (that I’ve written years ago in another language, now rewriting in Django)
One thing I’m not sure about is the project structure, and how/whether I should break up the code into different apps. Reading around online, it sounds like people use separate apps that may be reusable in the future by another project. Do people also break up code into apps just for organization? Are there any basic rules, like keep closely-related models in the same app?
Conceptually, my family tree website has these parts:
- views for person detail and family detail, index views for people and families
- photo album, video album, a page with ‘family history’ blurbs telling the main 4 families’ migration story, and an ‘outline view’ going from the original families through all their descendants/families/etc
- a dashboard area with this month’s birthdays & anniversaries, activity feed with recent updates
- user account page showing updates that user made
- admin area where I can add/update records, see user activity, etc
(And there will be tables/classes for: people, families, images, videos, notes, users, and join tables to associate people with images/videos/notes)
I’m not sure how granular the apps organization should be. Should there be separate apps for families and people and users and everything? Or since they’re not meaningful by themselves, should this be one big app? Something in between? TIA!
For the work that we do, yes, sometimes we break code up into apps for organization.
tl;dr: I would caution against trying to split it out too far. When you have related tables (tables with Foreign Key relationships), managing the imports between apps can become a bit of a headache. I would probably caution against making this separate apps - at least at first.
Our “rule-of-thumb” is that if there are a set of views that are a “logical unit” of work, we consider moving it into an app.
For example, we have a timesheet app, where a person enters their time on one or more projects. Their functionality to enter time is a separate app from the code that lets the administrators add and remove projects from the list of available projects - which in turn is a separate app from the code that lets someone else manage which people can charge time against which projects.
So even though all three components are working with the same data (people, projects, assignments, timesheets), the set of views and the business rules around them are all different - and potentially independent. (e.g. The code behind assigning people to projects is a function that could be useful outside the context of a timesheet application - perhaps useful in a project planning application.)
(Side note - due to some complexities and intricacies of our particular needs, the table structure behind these apps is perhaps a little larger than you might expect. There are at least 10 models in each of these apps.)
So if I were to go out on a limb here, I could see that you might have two different apps that you were building, a general Family Tree app, and a User Profile (‘user account’) app. The User Profile / User Account app (“page showing updates that user made”) seems to me like a general function that could be applied in many different circumstances. All the rest of it, the creation and display of the Family Trees, seem like a set of different views on what’s effectively the same data - looking at it from different angles, so to speak.
The problems with having the multiple apps have appeared most often to us when we have tables in separate apps that are related to each other. You can create a situation where you end up with a circular import situation, and they’re never fun to resolve.
4 Likes
thank you, Ken- this is very helpful!
There was a massive discussion on the forums recently that’s worth reading: Why do we need apps?.
I side with the “use one ‘core’ app until it hurts” philosophy. It goes quite far.
3 Likes