4 ms·

You bet. Still the easiest (IMO) for websites, perhaps of any language.

ipaddr 2y ago
It easy but having separate app spaces by default instead of just one like Laravel makes it slightly harder for just a website case.
- the__alchemist 2y ago
  Concur. The multiple app paradigm doesn't fit any site I've built in Django. I make one called main.
  - hellojesus 2y ago
    Idk if it's best practice, but I usually like to make apps similar to components, where I have an app for accounts which handles user accounts, and a files app which handles all the dimension and fact tables around user uploads, and a social app for social features, etc. It makes it easy to compartmentalize the business logic in terms of module imports.
    - globular-toast 2y ago
      This sounds similar to a modular monolith design. But you have to be careful not to directly import things between apps and especially not to make foreign keys between the models of different apps. We ended up doing that and just wishing it was one big app. Modular monolith is a good idea and if you want to do it in Django then make small apps that just expose services to each other (ie. high-level business functions). Then have a completely separate app just for the UI that uses those services.
      - hellojesus 2y ago
        Yeah. I was thinking a modular monolith since it's a django project, and I think that's django's sweet spot since it comes with so many things bundled. For a true modular design I'd probably step away from django to a less comprehensive framework or just write in golang.
        alganet 2y ago
        Have you tried the monolithic composite approach instead?
        hellojesus 2y ago
        I haven't heard of this, and my searches are failing for an exact hit. Do you have a link or can you give a brief explanation please?
        alganet 2y ago
        It is quite vanguard technology. A composite is a structure of many pieces that work together. Thus, a composite monolith is this arrangement of components in a way that they work together as a monolith. Separate modules, but working together as a single thing.
        globular-toast 2y ago
        That's the same as what people are calling a modular monolith, no? The key thing with composition is the bits sit next to each other, there's no inheritance or dependencies between the components. In my idea you'd have a bunch of "pure service" apps that are focused on individual areas of the business or processes. Then you'd have one or more UI apps (either user-facing HTML or APIs) that compose those services to do what needs to be done, e.g. a "create order" endpoint might compose the create order service from fulfilment and the send notification service from comms to put an order on the fulfilment backlog and send notifications. Is this what you had in mind?
        2y ago
- imjonse 2y ago
  You can use a single app, and it is probably the best way to go for the majority of projects - definitely the case for simple ones.

It easy but having separate app spaces by default instead of just one like Laravel makes it slightly harder for just a website case.

the__alchemist 2y ago
Concur. The multiple app paradigm doesn't fit any site I've built in Django. I make one called main.
- hellojesus 2y ago
  Idk if it's best practice, but I usually like to make apps similar to components, where I have an app for accounts which handles user accounts, and a files app which handles all the dimension and fact tables around user uploads, and a social app for social features, etc. It makes it easy to compartmentalize the business logic in terms of module imports.
  - globular-toast 2y ago
    This sounds similar to a modular monolith design. But you have to be careful not to directly import things between apps and especially not to make foreign keys between the models of different apps. We ended up doing that and just wishing it was one big app. Modular monolith is a good idea and if you want to do it in Django then make small apps that just expose services to each other (ie. high-level business functions). Then have a completely separate app just for the UI that uses those services.
    - hellojesus 2y ago
      Yeah. I was thinking a modular monolith since it's a django project, and I think that's django's sweet spot since it comes with so many things bundled. For a true modular design I'd probably step away from django to a less comprehensive framework or just write in golang.
      - alganet 2y ago
        Have you tried the monolithic composite approach instead?
        hellojesus 2y ago
        I haven't heard of this, and my searches are failing for an exact hit. Do you have a link or can you give a brief explanation please?
        alganet 2y ago
        It is quite vanguard technology. A composite is a structure of many pieces that work together. Thus, a composite monolith is this arrangement of components in a way that they work together as a monolith. Separate modules, but working together as a single thing.
        globular-toast 2y ago
        That's the same as what people are calling a modular monolith, no? The key thing with composition is the bits sit next to each other, there's no inheritance or dependencies between the components. In my idea you'd have a bunch of "pure service" apps that are focused on individual areas of the business or processes. Then you'd have one or more UI apps (either user-facing HTML or APIs) that compose those services to do what needs to be done, e.g. a "create order" endpoint might compose the create order service from fulfilment and the send notification service from comms to put an order on the fulfilment backlog and send notifications. Is this what you had in mind?
        2y ago
imjonse 2y ago
You can use a single app, and it is probably the best way to go for the majority of projects - definitely the case for simple ones.