Hacker News Reader

Part of it is that Django has been around for quite a while now. It's maybe _the_ most succesful Python framework out there, so there are some paradigms that aren't common anymore but are hold-overs from years past. In particular, it pre-dates the current "microservice" trend and assumes a fairly monolithic environment.

And I think "apps" _do_ make sense in certain contexts. Consider this situation:

- I start a "polls" app like the Django docs example.

- I get a lot of users and they like my functionality, so I want to engage the community.

- I decide to start publishing blog posts, but I'm too lazy to spin up a whole new Wordpress install

- I find a "blog" app and drop that into my project with the '/blog' URL prefix.

Now I can start writing blog posts right away and anyone can go to my site '/blog' and see it. There are no cross-app database dependencies to worry about.

The same would be true for adding a basic "social" app that shows a user-profile page for django Users at '/users/<id>' or something like that.

The polls app example is given in the introductory Django tutorial...

Yes, that's what I said...?

Sorry, misread that line.

Point being, how many examples do you have where someone writing a Django site is going to reuse their own apps?

I reuse my own apps constantly, whenever I do new sites.

Excellent - could you give some examples of what you reuse?

I'm interested in whether this is a worthwhile abstraction in the general case, or whether for most people (like me and the post) it's an unhelpful complication.

It's a worthwhile abstraction for any generic feature that isn't specific to the one project you're working on:

- User profiles

- Content management/publishing

- Messaging and chat

- Searching your database

- Admin

- Analytics on your database

Segmenting into apps makes the most sense when there are no cross-app dependencies on migrations: additional read-only capabilities on your existing models in another app, or new capability using entirely new, stand-alone models.

Is it actually possible to find and drop in apps like you suggest? And have it just work? Is a repository of various blog apps out there? What if one of them does something nasty to your database?

It seems like it'd be easier to spin up a Wordpress instance...

Yes, there's a whole universe of them.

Here's a good place to start looking for things to help make development easier:

https://djangopackages.org/

Thanks!

> What if one of them does something nasty to your database?

Same question is valid for Wordpress plugins.

Wordpress has already done nasty stuff to your database...

Wordpress is a CMS more comparable to something like django-cms (haven't used it). Django is more generic than Wordpress.

An example is worth 1000 words? Here's my app setup for the website I've been developing for 5 years.

    # these are the "drop-in" apps we've been discussing    
    THIRD_PARTY_APPS = (
        # django-allauth
        'allauth',
        'allauth.account',
        'allauth.socialaccount',
        #'allauth.socialaccount.providers.facebook', # to add later on
        'django_hosts',
        
        'bootstrap3',
        'imagekit', # for thumbnails
        'paypal.standard.ipn',
        'template_debug',
        'import_export', # CSV import and export
        'jfu',
        'extra_views',
        
        'post_office',
        'django_xworkflows',
        'markdown_deux',
        
        'django_mobile_app_distribution',
        'hijack',
        'compat',
    )
    
    # Ones I've written...
    LOCAL_APPS = (
        'membership',
        'awards',
        'reports',
        'entryhandling',
        'folio',
        'judging_console',
        'email_manager',
        'printing',
        'judges',
        'logs',
        'honours',
        'api',
        'questions',
    )
    
    INSTALLED_APPS = DJANGO_APPS + THIRD_PARTY_APPS + LOCAL_APPS

Where app directories are incredibly useful is in Django library development. They're a really convenient way to hook in models, static files, template helpers, etc. to an existing Django site, without forcing users to do a bunch of setup work when integrating your library. It's not a coincidence that most Django libraries have a very similar setup:

1. Install the package 2. Add the package to settings.INSTALLED_APPS (and middleware, etc). 3. Profit!

For an instance of a Django site, apps are less useful, and the article's recommendation to be more careful when splitting your site into multiple apps is great advice.

Yeah, I agree. Makes sense for libraries. So keep that separate for library writers, don't expose me to the complexity of that.

The benchmark I use is "Is it probable that this app might become shared between projects?"

Using a Django 'app' for this makes sense. If it's generic enough that I might consider moving it into it's own repo then it's probably not going to be heavily intertwined with the rest of the project.

Have you checkout out O'Reilly's Lightweight Django book? It basically goes through all of this, starting with a single file Django app.

No! I read a lot of books, but missed that. Thanks!

+1 for Lightweight Django. I had the pleasure of working with one of the authors. The book is well laid out and covers some really great topics that aren't always covered well elsewhere in the context of Django (i.e. Websocket services with Django). It's a great companion for Two Scoops of Django.

In my opinion that book should be the starting point. The official tutorials have you way deep in the weeds with database migrations and stuff before you even have a basic understanding of where you're at and why. Worst "hello world" ever.

>I'm so glad to see the mention of "app" directories here. I've only dabbled in Django development, but I've always thought the desire to divide things into apps didn't really make any sense. It felt like the developers of Django had said "well, intuitively, there must be some unit of reuse at this level" and then stuck the notion of apps in there in an attempt to provide that reuse.

Yes, let's say you install a module that has a specific Django functionality from pypi, it will typically be installed as an app.

It confuses newbies sometimes who think that they need to worry about how to divide up their application into different applications. 99% of the time they don't and shouldn't (putting everything in a single app called 'core' in your project is a pretty common pattern).

Unfortunately the docs were never very clear on this.

>This seems to me to be somewhat unpythonic, unnecessary complexity introduced right from the start - why not make the reuse optional?. The file system layout becomes confusing as a result. More generally, I would expect that the most minimal Django site would be a single file, that would seem most Pythonic, but it isn't designed like that.

It can be made to behave like that if you really want:

http://olifante.blogs.com/covil/2010/04/minimal-django.html

Most people aren't using Django for that though, so it's not widely advertised nor known.

>It's heartening, however, to see I'm at least not _entirely_ wrong for having a gut unease about this,

It's not like the framework is perfect. There's plenty wrong with it, but it largely managed not to fuck everything up, which is pretty rare.

You could write a Django site in a single file if you wanted to.

See this for an example: https://www.safaribooksonline.com/library/view/lightweight-d...

A good rule of thumb is that a Django "app" should be (1) standalone and (2) reusable.

If you were to write a Django project to automate some complicated internal process at your particular company, it's likely that you'd break up the code into separate Python modules to help give it an easy to understand structure. But it's unlikely that any other company would necessarily benefit from any of those separate modules by themselves.

However, let's say you come up with a clever idea about how to log errors in your project. Now, that's the sort of thing that other people might want to use in their own projects. If you were to restructure your code a bit and make it a bit more abstract then you could create a separate "app" that could be dropped into other Django projects.

I'm not affiliated with them, but you think seriously about Django, you should take a look at the book https://www.twoscoopspress.com/products/two-scoops-of-django...

I still have the 1.5 edition, but it helped me a lot. I'm think about upgrading. Do you recommend?

It depends what you're doing. It shines on low level features like authentication and image cropping, where I need ways to do these things, and I can use them across the board.

It breaks down when you have a lot of views and urls that are trying to stay close to their related models, but are too interconnected to have any real kind of separation of concerns.

I find myself using all of the above. There's nothing wrong with building a small site in a single app, or nesting apps to provide a little more structure for how they're connected or separated.

> why not make the reuse optional?

Well, it is optional. You can just not divide you stuff and place everything inside the main app. But notice the article recreates the same layer of reuse inside the main app, and got some extra problems because of it (renaming the tables is probably caused by this).

Django may need an extra paragraph at the tutorial, telling how it is ok to place everything on the main app when everything is application specific software, and how you should break generic functionality on other apps.

By the way, what would be reverse Dunning-Kruger?

> Well, it is optional

What I mean is, you still have to have a "main" app. Why? I don't want to reuse it. So I don't want an "app". I just want to build my website. Stop making me put things in an unnecessarily complicated directory hierarchy. If it were Java, I wouldn't think twice about it, but it doesn't seem Pythonic.

> reverse Dunning-Kruger

Good question! Probably... illusory inferiority AKA imposter syndrome. I assumed Django knows best, but maybe it doesn't.

Sure. One of the Djangoesque opinions is that if you're building a site, you'd like it to be maintainable, and that you'll probably add on to it.

If you've been working in the Python ecosystem long enough to know that you're building a site that doesn't have those assumptions, you'll probably pick something different to start out with, like Flask or Bottle.

> you still have to have a "main" app

Well, it has to be organized some way. It happens to have the organization that gives you more flexibility, instead of forcing something that only fits very small sites onto you. That means you'll have an extra directory on your tree.

Anyway, nobody uses only the main app. The article creates a big amount of problems by trying to only write on it, but I bet that even them use the Django's builtin apps.

> AKA imposter syndrome

Oh. Dunning-Kruger study detected that one too. It's within the effect: people tend to self evaluate into a small band near (but often under) the top, whatever their real evaluation is.