Hacker News Reader

Comment by theptip | Hacker News Reader

If you do this a lot you should look into ‘startapp —-template’ which lets you bake in boilerplate like this.

https://docs.djangoproject.com/en/4.0/ref/django-admin/#cmdo...

One minor point on app names. They are really hard/annoying to change once you have production data, because your DB tables will always be appname_modelname, and renaming tables is a real PITA. You can set the model to point to a nonstandard table, but then your project has a confusing non-Djangonic wart that will annoy you forever more. For this reason I think ‘core’ is a safer option, unless you are certain what your app should be named. Naming after one domain model is likely to be too specific. (I strongly recommend against multiple apps until you have functionality you need to commonize between projects, as refactoring models between apps is a nightmare if you get the boundaries wrong.)

View on HN

Regarding apps, I was just thinking you could create a directory structure like this, essentially eschewing the whole concept of Django "apps":

    <project>
        src/
            <package>/
                models/
                    __init__.py    # Import all model classes (necessary for Django to find them)
                    some_model.py  # Define SomeModel class
                views/
                    __init__.py
                    some_view.py   # Views for SomeModel
                settings.py        # Add "<package>" to INSTALLED_APPS
                urls.py

You still need to register the top level package as an app for Django to find things, but then you don't have to deal with Django's concept of apps beyond that. All your tables will be named <package>_<model> by default, which seems nice.

If it turns out later you need resusable "apps" for some reason, you could always add an apps/ subpackage for them.

I haven't tried this in a real project, so I don't know if there are any downsides, but it seems like a decent approach.

Yeah I've played around with this approach in the past while prototyping service boilerplates, I think it's viable. I never got it polished enough to publish as a startproject --template and ultimately went with Flask for microservices, so I didn't finish the prototype.

I found this article useful while I was experimenting: https://simpleisbetterthancomplex.com/article/2017/08/07/a-m...

There are a few different places where little things break and then you need to use an obscure settings.py variable to fix them, which makes me a little nervous since it will cause a little cognitive friction for Django-fluent developers joining your project. But I do think it's worth experimenting with.

> For this reason I think ‘core’ is a safer option, unless you are certain what your app should be named.

Yep, this is what I do. It’s rare that I make anything that can be shared cross-app (most Django apps I make are super simple CRUD-types), so every one of my Django apps has a ‘core’. I also recommend this approach.

Reply on news.ycombinator.com