4 ms·

I work on a large Django codebase, and while this is a cool blog post, it's quite important once you reach a certain size that these things aren't actually done

I work on a large Django codebase, and while this is a cool blog post, it's quite important once you reach a certain size that these things aren't actually done in practice. If you wanted to _fundamentally_ build your product around this concept that's fine, but Django probably isn't the right framework, however no feature is worth the pain of this. For what it's worth, Django models and doing good relational design solve a huge number of problems. We've got ~380 Django apps and ~350 models and haven't yet needed dynamic models.

aldoushuxley001 8y ago
How is it possible to have 380 Django apps in a single codebase? That sounds insane. Is that not absurdly complex to manage? I can't even imagine.
- danpalmer 8y ago
  It actually works pretty nicely. Most of our apps are small and focused, and we nest apps within each other heavily. It's fairly common for example to see an app introduce some models, Python APIs to work with them, and business logic, and then to have a sub-app for the web API and bits relating to that, and a sub-app for the admin interfaces (we don't use the Django admin). Example: - orders - refunds - shipping - royal_mail - click_and_collect - fraud - fraud_blacklists - returns This means that working on our Click and Collect integration, one only needs to hold in their head the current app, and maybe some APIs provided by the apps above it. It's relatively uncommon to import across apps on different branches of the tree, and when we do that's typically only to top-level apps containing the most core models, or for very explicit public APIs provided to the whole site (which might be re-exported from an __init__.py up the tree anyway). I find it a pretty nice codebase to work on. We're hiring too https://www.thread.com/jobs/software-engineer https://www.thread.com/jobs/software-engineer
  - toyg 8y ago
    > We encourage applications from people who aren’t cis white men, who are currently over-represented on the engineering team at Thread. ...
jstarfish 8y ago
> For what it's worth, Django models and doing good relational design solve a huge number of problems. I agree, but the main demand for something like this is going to be a client who wants to create their own forms on demand without touching Model code. It is very much a hack-- the technical debt of it just gets kicked down the road for someone else to correct, the first of which is the unfortunate analyst who used to churn out weekly reports with a handful of SQL statements but now has to run an entire ETL pipeline/data science marathon to correct all the inconsistencies.
- danpalmer 8y ago
  > I agree, but the main demand for something like this is going to be a client who wants to create their own forms on demand without touching Model code. I can see the use-cases, but I think that level of dynamism should be built into the data model, not built by building a dynamic data model. To take an extreme example, if you had a single table with the columns "key" and "value", you'd be able to encode any structure you wanted at the application level. This would likely be a bad idea (at least for general purposes), but there are levels in between that would work. Models like "Form" and "Form Item", and maybe even "FormItemType" and "FormItemField", things like that, could represent fairly complex dynamic structures.

aldoushuxley001 8y ago

How is it possible to have 380 Django apps in a single codebase? That sounds insane. Is that not absurdly complex to manage? I can't even imagine.

danpalmer 8y ago
It actually works pretty nicely. Most of our apps are small and focused, and we nest apps within each other heavily. It's fairly common for example to see an app introduce some models, Python APIs to work with them, and business logic, and then to have a sub-app for the web API and bits relating to that, and a sub-app for the admin interfaces (we don't use the Django admin). Example: - orders - refunds - shipping - royal_mail - click_and_collect - fraud - fraud_blacklists - returns This means that working on our Click and Collect integration, one only needs to hold in their head the current app, and maybe some APIs provided by the apps above it. It's relatively uncommon to import across apps on different branches of the tree, and when we do that's typically only to top-level apps containing the most core models, or for very explicit public APIs provided to the whole site (which might be re-exported from an __init__.py up the tree anyway). I find it a pretty nice codebase to work on. We're hiring too https://www.thread.com/jobs/software-engineer https://www.thread.com/jobs/software-engineer
- toyg 8y ago
  > We encourage applications from people who aren’t cis white men, who are currently over-represented on the engineering team at Thread. ...

jstarfish 8y ago

> For what it's worth, Django models and doing good relational design solve a huge number of problems. I agree, but the main demand for something like this is going to be a client who wants to create their own forms on demand without touching Model code. It is very much a hack-- the technical debt of it just gets kicked down the road for someone else to correct, the first of which is the unfortunate analyst who used to churn out weekly reports with a handful of SQL statements but now has to run an entire ETL pipeline/data science marathon to correct all the inconsistencies.

danpalmer 8y ago
> I agree, but the main demand for something like this is going to be a client who wants to create their own forms on demand without touching Model code. I can see the use-cases, but I think that level of dynamism should be built into the data model, not built by building a dynamic data model. To take an extreme example, if you had a single table with the columns "key" and "value", you'd be able to encode any structure you wanted at the application level. This would likely be a bad idea (at least for general purposes), but there are levels in between that would work. Models like "Form" and "Form Item", and maybe even "FormItemType" and "FormItemField", things like that, could represent fairly complex dynamic structures.