What is the difference between a site and an app in Django?

Question

I know a site can have many apps but all the examples I see have the site called "mysite". I figured the site would be the name of your site, like StackOverflow for example.

Would you do that and then have apps like "authentication", "questions", and "search"? Or would you really just have a site called mysite with one app called StackOverflow?

Answer 1

As you said, you'd have a site called StackOverflow with an auth app, questions app, etc.

You should have a look at the Pinax project to see how they lay things out. It's one of the better ways to do it since it will increase the modularity and portability of your apps.

Answer 2

From the Django documentation:

Projects vs. apps

What’s the difference between a project and an app? An app is a Web application that does something — e.g., a weblog system, a database of public records or a simple poll app. A project is a collection of configuration and apps for a particular Web site. A project can contain multiple apps. An app can be in multiple projects.

From this link:

Projects versus applications

This is really more of a separate (though related) question, but understanding the distinction Django draws between a “project” and an “application” is a big part of good code layout. Roughly speaking, this is what the two terms mean:

• An application tries to provide a single, relatively self-contained set of related functions. An application is allowed to define a set of models (though it doesn’t have to) and to define and register custom template tags and filters (though, again, it doesn’t have to).

• A project is a collection of applications, installed into the same database, and all using the same settings file. In a sense, the defining aspect of a project is that it supplies a settings file which specifies the database to use, the applications to install, and other bits of configuration. A project may correspond to a single web site, but doesn’t have to — multiple projects can run on the same site. The project is also responsible for the root URL configuration, though in most cases it’s useful to just have that consist of calls to include which pull in URL configurations from inidividual applications.

Views, custom manipulators, custom context processors and most other things Django lets you create can all be defined either at the level of the project or of the application, and where you do that should depend on what’s most effective for you; in general, though, they’re best placed inside an application (this increases their portability across projects).

Answer 3

Django actually has 3 concepts here:

• Project (I think this is what you're calling site): This is the directory that contains all the apps. They share a common runtime invocation and can refer to each other.

• App: This is a set of views, models, and templates. Apps are often designed so they can be plugged into another project.

• Site: You can designate different behaviour for an app based on the site (ie: URL) being visited. This way, the same "App" can customize itself based on whether or not the user has visited 'StackOverflow.com' or 'RackOverflow.com' (or whatever the IT-targeted version will be called), even though it's the same codebase that's handling the request.

How you arrange these is really up to your project. In a complicated case, you might do:

Project: StackOverflowProject
    App: Web Version
        Site: StackOverflow.com
        Site: RackOverflow.com
    App: XML API Version
        Site: StackOverflow.com
        Site: RackOverflow.com
    Common non-app settings, libraries, auth, etc

Or, for a simpler project that wants to leverage an open-source plugin:

Project: StackOverflowProject
    App: Stackoverflow
        (No specific use of the sites feature... it's just one site)
    App: Plug-in TinyMCE editor with image upload
        (No specific use of the sites feature)

Aside from the fact that there needs to be a Project, and at least one app, the arrangement is very flexible; you can adapt however suits best to help abstract and manage the complexity (or simplicity) of your deployment.

Answer 4

The answer to would you have a project with a single app called StackOverflow is an unequivocal no. A site like this might have 20+ apps.

See James Bennett's "DjangoCon 2008: Reusable Apps" video presentation which explains this nicely.