I think there are too many concepts in this, but rather than being negative, here are some tips:<p>Always keep your models slim. Don't stuff template related stuff in there. You need to look at those models often, so compact is a win. course_has_finished(course) is not much longer than course.has_finished(), and will allow you to expand the functionality as time goes on. Do precomputation if you need the information in a template - that keeps your templates simpler and allows you to easily expand the complexity of the precomputation.<p>Don't use class-based views, at least not outside very specific niches like the Django admin. Class-based views will transform a simple, composeable call stack into a ball of inheritance mud. Inheritance is not a good code reuse tool.<p>Don't make separate apps in the same project, unless the project actually consists of several different, completely independent projects. You can make subdirectories without making apps, and thus avoid dependency hell.<p>Also be wary of the formerly South, now built-in migrations stuff. It's built around a fragile model (perfect history representation), so has lots of foot guns.<p>And be wary of 3rd party libraries with their own models. You can spend a lot of time trying to built bridges to those models compared to just doing what makes sense for your particular project. I think 3rd party libraries are perhaps best implemented without concrete models - duck-typing in Python let us do this. This includes Django itself, by the way. User profiles didn't become good until Django allowed you to define the user model yourself.
I've been heavily inspired by this styleguide over the years, but I still think it's a bit too complex. A few random thoughts:<p><pre><code> - I think "services" is too much of a loaded term. I prefer "actions", and I always use the function-based style.
- I hate the naming of "APIs" in this document. They use the term "API" when they mean "endpoint" or "view".
- "Reuse serializers as little as possible" is the single best piece of advice when using DRF. The inline InputSerializer thing is brilliant.
- Having each each endpoint only handle a single HTTP verb is brilliant.
- URLs and views should be separate from all other business logic (models, actions etc).
- For read endpoints and associated business logic, I'd encourage https://www.django-readers.org/ (disclaimer: I'm the author).</code></pre>
Ah, the typical "where to put business logic in Django".<p>M in ActiveRecord MVC web frameworks is deeply misunderstood. M is not "data model" (it would be called DVC if that was the case). M is your <i>domain</i> model. It's the model of your business, model of the real world. It's the core of your application.<p>Another thing that I never understood, why are functions called services? Is it a subconscious desire to go back to enterprisey kingdom of nouns? (apparently it is [1])<p>A service is either something that lives on a network (e.g. database, payment gateway, microservice). Or a class that has a state. Your functions are neither of those, they are just functions.<p>You business logic should live in the "models" namespace. Whether you put it on Model classes, or onto custom Managers, or just dump them into the module is not important, as long as you keep it consistent and keep your apps fairly small and isolated from each other.<p>Django already gives you enough tools to support big "enterprise" applications. It is far from perfect, but you'll get much further if you embrace the framework instead of fighting it.<p>If you really are attached to this "services" mindset then Django API Domains [2] is your best option.<p>[1] <a href="https://www.b-list.org/weblog/2020/mar/16/no-service/" rel="nofollow">https://www.b-list.org/weblog/2020/mar/16/no-service/</a><p>[2] <a href="https://github.com/phalt/django-api-domains">https://github.com/phalt/django-api-domains</a>
> We use Celery for the following general cases:<p>><p>> Communicating with 3rd party services (sending emails, notifications, etc.)<p>> Offloading heavier computational tasks outside the HTTP cycle.<p>> Periodic tasks (using Celery beat)<p>Sigh. No mention of the trade-offs. There's simpler ways to do all these things. Celery is a big complex beast and it always pains me to see it as the default suggestion for simple tasks.
I have a long-running thread on the Django forums with a bunch of opinions about this topic: <a href="https://forum.djangoproject.com/t/structuring-large-complex-django-projects-and-using-a-services-layer-in-django-projects/1487" rel="nofollow">https://forum.djangoproject.com/t/structuring-large-complex-...</a>
In a similar fashion, for anybody interested I've written some of my guidelines on implementing Django apps: <a href="https://www.spapas.net/2022/09/28/django-guidelines/" rel="nofollow">https://www.spapas.net/2022/09/28/django-guidelines/</a>
I've been working on a project with flask + sqlalchemy. I have those sql queries returning a bit of rows (up to 20k) and that are quite slow. SQLalchemy does not seem to support caching the results and I've started to use flask-caching[1] with redis using the @cache.memoize() decorator.<p>Just wondering if I am taking the right path or if there is better alternative.<p>[1]<a href="https://flask-caching.readthedocs.io" rel="nofollow">https://flask-caching.readthedocs.io</a>
I found this useful being someone who was self taught django and hacked together a project with no idea of architecture. To this day I don't even know what a selector is referring to lol never used it<p>I'm learning node now for another mini project, is there anything similar? I know how it achieve certain tasks but to structure in a proper way I know nothing, all tutorials I've done never really go that deep
I've found it helpful in several projects to implement the "services layer" described here as a state machine, modeling state transitions for a central object (e.g. an article can be drafted, submitted, reviewed, published). The state machine enforces permissible transitions and handles side effects which touch other models.
HN comments are really disparaging, but after reading through I really liked the content and am going to pull out their service / serializer model to use in my project. Nice opinionated way to avoid structuring a program in a bad way.
Don't create apps just for the sake of project structure even when models from multiple apps are closely related.<p>Moving models from one app to another is doable but it is a pain. It's even worse if you are relying on GFKs.
Somewhat off-topic but django is fundraising over here <a href="https://www.djangoproject.com/fundraising/" rel="nofollow">https://www.djangoproject.com/fundraising/</a>
Hello everyone,<p>Radoslav here (one of the authors of the mentioned Django Styleguide).<p>First of all - I want to thank everyone to the comments The fact that someone took the time to read the styleguide & then write a comment / propose a different POV - is humbling.<p>I've read everything once & I'll do so at least couple more times. There are interesting ideas & comments that we can apply!<p>And finally, I want to add some more context:<p>1. That particular styleguide has served us, and it's still serving us well. It's basically a list of ideas that we found useful, thanks to the various Django projects that we've been exposed to at HackSoft.<p>2. One core philosophy of the style guide is the ability to cherry-pick whatever makes sense to you. Even at our company, it's very rare to have 2 Django projects following the exact same structure. The styleguide is rather a framework / direction for things that's been proven to work, from our experience.<p>3. And of course, the styleguide can use some more love from us. We are sitting on a lot of unshared knowledge that needs to be structured and applied back to the Django Styleguide & the corresponding Django Styleguide example project.<p>4. We try to keep it pragmatic, so you can actually build something. For example, DDD sounds great, but lacks pragmatism and slows you down by a lot (at least, for us).<p>5. And finally - this is not the "only right way" to do Django. As there is no "right way" to build software. Luckily, there are always options. We'll update the list of other suggested approaches, so people can have a choice / navigate the space better.<p>As an example of one of the big topics that we want to touch upon is nesting apps. Alongside the "services / selectors" layer (btw - you can call this whatever suits you best ), the ability to nest apps within apps is really powerful, when it comes to the structure and longevity of a Django project. Having 50+ flat apps is not the best experience.<p>Our current focus is around building the company (HackSoft). The Django Styleguide will be soon to follow. We are slowly gaining more speed & we'll eventually get there<p>All discussion around "How to do Django" are in fact really interesting. If we happen to meet at some future EuroPython / DjangoCon Europe - I'm always open to discuss in person. Otherwise, if you have specific comments / suggestions - you can submit it either as an issue / discussion, or just send an email to radorado@hacksoft.io<p>Cheers!
On testing, I think "one file & class per thing-to-test" is subtly bad advice. It's not harmful in the hands of someone that knows what they are doing, but it tends to point engineers towards a tightly-coupled test suite, which ends up making refactoring more painful and error prone down the road.<p>If you have one testclass per entity, then if you make any changes to the structure of your services/models/entities, you must restructure your tests too. This means you can't do the "dream refactor" where you don't touch your tests, and restructure your code without changing any behavior. If you rewrite your tests whenever your structure changes, how can you be sure you've not broken your tests?<p>Instead, I advocate for testing behaviors. In a tightly-integrated framework like Django, most of your tests are going to be integration tests (i.e. you have a database involved). You should bias those tests towards an integration-y approach that uses the public interfaces (Service Layer, if you have one) and asserts behavior. Ideally the tests should not change if the business logic has not changed. (In practice you'll often need to add some mapping/helper/setup code to make this true.)<p>If you have any fat-model type behavior that is explicitly scoped to a single model, then you can test that in isolation. Many Django projects call these "unit tests" even though they still involve reading and writing your model from the DB. I call them "focused integration tests". All that matters is that you have agreement on terminology inside your project. If you have extremely complex domain logic, it can be worthwhile to construct "true Unit Tests" that use dummy objects to test logic without hitting your DB. I've not found it worthwhile to mock the DB in most Django projects though.<p>To provide an example of where my "test behaviors not classes" advice differs from the OP's paradigm, let's say you split out a sub-object to provide a pluggable Strategy for a part of your Model's behavior -- you don't necessarily need to have detailed tests for that Strategy class if it's fully covered by the model's tests. Only the edge cases that are awkward to test at the higher level need to be tested at the granular level of the Strategy. Indeed, the first refactor that just creates a Strategy holding your existing behavior need not change any of your existing tests at all! Indeed, if you do need to change existing tests, that suggests your tests were improperly-coupled to the code under test, since a mere structural change like this should not affect the behavior of your application. Even after adding more Strategy logic, most of your old ModelTests are still good; they still test the high-level behavior, and now also test the integration between your model and the new Strategy class. Basically, test at the most-granular level that gives a clear, decoupled test for your behavior; resist testing every entity in isolation, because some entities have rich coreographies with other entites that make them hard to isolate. Sometimes you have to contort and tightly-couple in order to test things at the very-lowest-level possible.<p>Inspiration/further reading: <a href="https://blog.cleancoder.com/uncle-bob/2017/10/03/TestContravariance.html" rel="nofollow">https://blog.cleancoder.com/uncle-bob/2017/10/03/TestContrav...</a>. (Grit your teeth through the "Socratic dialog" style. The principle being described is extremely valuable.)
I hate making webpages, but Django makes it as bearable as it can be.<p>I hate python, but love Django.<p>I think I have some sort of emotional attachment to Django.