We Keep Coding

Is a django project only meant to be for a single website or can the different apps be different sites. What is perferable and advisable?

I have been using django for a while, but there is something im not quite clear on.
How big should a django app be. If for example a django app should only be user authentication or if it should be an entire website in one app.
If I have a project with several apps and each app is a whole website with a lot of code, is that the way it suppose to be or should all apps related to a single site within a project ?
Im thinking of creating one django project for each site, but im now wondering if I should be creating one project where each app is one site. Can anyone please comment on this, what it the preferred way to do it ?
In the django documentation one app is only used for a poll, so it seems to be that, according to the documentation, that each app should be some part of functionality on the site.

An app is a submodule of a project which contains functionality (views, models, urls etc) for a specific part of the larger site and is as decoupled from the other apps as possible. The project as a whole is the website and your apps make up the separate parts of functionality for your site.
If your sites are going to basically contain the same functionality, it might be worth looking into the Sites framework which django provides.
So taking the polls example further.
Lets say the website is a survey site. There would be the polls app, which would contain the relevant models and views for creating and recording poll results. Then you might need to view the data, so you could create an analysis app, which would store the views for displaying dashboards and contain functions for data processing. Then we could take things a bit further, and have users be able to log in and see their own results (and give us the chance to link users to poll results), so you would make an accounts app, which would hold views for logging in/out, maybe a profile page etc.
So each of these different parts of functionality would be separated out into distinct apps, which would make up the project (site) as a whole.
If the apps have been decoupled properly, you could reuse the different apps in other projects (e.g. the accounts app could be dropped into a new project do provide logging in/out functionality)

In my experience so far, an app should be a reusable entity. There many guiding principles for choosing what to go and what not in an app. Separating authentication is one example. A projcet is one big collection of may apps and a reusable app can be in many projects.
Nowadays, there is a trend to move to micro service architecture, which is next level of separation of functionality with each service doing best one thing.
Each project is a unit in itself, not an individual app. So you host the project, not the app. I recommend using different project for each site and using micro-service architecture. A lot depends on your existing codebase too.

Django: How to properly handle two websites at the same time with a shared database?

I've researched on how to handle multiple websites with Django but nothing seemed really convincing to me: here, here and here
Here is what I have now:
A single Django project running on a server, with two apps. One for the API (with django REST Framework) and an other app which basically consumes the API and display the datas (retrieved directly in the database). My database is Oracle and on a separate server for robustness reasons.
Here is what I would like to have:
Two websites, one would be the API (certain users use only the API) and the other one would be the website (for the other users).
I obviously need those two websites to share the same database (but this shouldn't be to hard to handle in the settings.py file), and I also need to use the same Models, Admin, etc...
How can I handle that with being as DRY as possible ? If I make two django project, I'll have to duplicate my models, my admin, and certain business classes and functions... Which could be a pain to maintain.
The alternative would be to play around with virtualhosts and url redirections to make it seamless.
What do you think is the best solution ? And can you provide an example of implementation ?
Thanks!

There are few options:
Create 2 projects and a django application. You create the django application for the common code, like the models. Then you create 2 projects and use that application in both of them.
Create 1 project with 3 applications 1 application for common code, 1 for API and 1 for app. The API and app application will use the common code application.
Create just 1 project with 1 application. You'll have to create different views for the API and for the app and map a different url for each one.
The options are sorted by overhead while the first option has the most overhead, but it's the most organized solution.
Which is best? it depends on the size of your project. The bigger - the more the overhead will pay off. If you don't know what is going to be the size of the project in the future, then I would start with the third option, and as the project grows, move towards the second and first options.

Django app scope questions

I am fairly new to Django, having done the tutorial front to back and back to front with a website I am creating myself.
However, there are - currently - about two question that stop me from progressing. As background: I'm an enterprise java developer so I'm familiar with database design, foreign keys and the importance of entity/model scoping. Also, I created websites with php and mysql and was therefore familiar with including header/footers/menus etc. Switching to Django is difficult partially because of this, since Django uses template inheritance to 'include' pages, which is quite a bit different from including each footer/header/menu in each page.
For these questions, imagine someone who likes to recreate the youtube website with Django (just hypothetical! - who would want to do this anyway?)
How would one define the app scope? I read on multiple sources (among which the django website) that an app should be really small, in our example perhaps: comment app, video upload app, suggested videos app etc. However - in my view - comments should have a foreign key to a video and a foreign key to a user. If one would design a comment app, how would one solve those foreign key contraints/dependencies since they would need to point to a different app? Or perhaps, how SHOULD one scope the apps?
Related to question 1, about templates... Designing views and templates for a single app is not really a problem (yet). However how does one bring multiple apps together. For example, one could create a 'home' app that holds the menu, header, footer, login and such. But that means that other apps - like comments - need to extend that view creating yet another dependency to the home app. How would one do this in django?
Note that I'm not looking for full code - although code snippets might help explain the concepts - but these questions are more theoretical.

You're kind of over-thinking this. An app is really just a convenient grouping of code. There's nothing that stops apps having a foreign key to a model in another app: indeed, that's more or less required, especially in the case of linking to users since they are provided by the contrib.auth app.
As regards templates, this isn't specifically to do with apps, but with any template that needs to gather data from multiple places. The usual way to do this is by using custom template tags - probably inclusion tags - to query and render the data.

What exactly are Django Apps

I want to switch from Rails to Django, to broaden my mind, and a question has bobbed up in my mind.
My Rails app is quite a mess, since my hobby-based development approach is a patch-and-glue one. I have seen very early that Django divied between a project and an app. According to their site, a project is made of many apps, and one app can be used for many projects.
This intrigued me, since that would made the lines between my site's areas clearer. I tried to find some more examples and information on that, but I couldn't answer my question, which is:
How big/small is such an app? Are they able/supposed to interact closely?
It is, for example smart to have one app to deal with user's profiles, and another app to deal with blog-posts and comments, from those users? (In my site, a user can have several blogs, with different profiles). Or are they meant to be used otherwise?

A django App is a fancy name for a python package. Really, that's it. The only thing that would distinguish a django app from other python packages is that it makes sense for it to appear in the INSTALLED_APPS list in settings.py, because it contains things like templates, models, or other features that can be auto-discovered by other django features.
A good django app will do just one thing, do it well, and not be tightly coupled to any other app that might use it. A wide variety of apps are provided with django in the contrib namespace that follow this convention.
In your example, a good way to devise apps is to have one for user profiles (or use one of the many existing profile apps), one app for blog posts (or one of the many that already do this), one app for comments, separate from blog posts (again, you can use an existing app for this), and finally, a very tiny app that ties the three together, since they don't and shouldn't depend on each other directly.

The purpose of using app's is to make them reusable. Django likes DRY principle DRY stands for DO NOT repeat yourself
An app should be as small as it can, and loosely coupled. So, for an app should not need another app to work properly.
Django recommends writing an app for each table (well, not always, but as soon as you want to grow your app, you will definitely need to divide tables to pair apps. Or else you will have hard time for maintaining your code.)
You can, for example, create an app for users, an app for sales, an app for comments, an app for articles. It will be easier to maintain your code and if you have done it right, you can use the app in other project with a little (if any) modification in the app.
Project's are, compilation of app's. Users app, articles app, comments app can come together an make a project, or in other words, a website.
If you want to learn django, I suggest you to check out:
http://www.djangobook.com/
http://docs.djangoproject.com/
One word of advice, do not, in any case, copy/paste. Not only your code has great chance to fail, but you will not know what the code is doing. If you are going to use someone elses code in your project, at least type them, this will make you understand what the code is doing, or at least, it will give an idea.
Writing your own code is always better for maintance, but this does not mean that you should reinvent the world, you can use libraries, look at their documentation to use it properly.
Documentations, tutorials are you best friend.
Good luck.

A project is basically a place where your project lives...in your project you setup your url's, project settings, etc.
An app defines its own data models and views to be used within a project. You can move these between projects if you like.
I highly recommend running through the tutorials from the Django site as they will show you what a project and app are, how to manage both, how to use the admin panel, how to make the app usable in multiple projects, etc.

A portal = A django project
A ads system, gallery photos, catalog of products = Apps

How do you manage your Django applications?

I just wanted to try to build a project with django. Therefore I have a (basic) question on how to manage such a project. Since I cannot find any guidelines or so on how to split a project into applications.
Let's take a kind of SO as an example. Which applications would you use?
I'd say there should be the applications "users" and "questions". But what if there was a topic system with static articles, too. Maybe they also could receive votes.
How to build the apps structure then? One app for "questions", "votes" and "topics" or just one app "content"?
I have no idea what to do. Maybe it's because I know not very much about Django yet, but I'm interested either...

There aren't hard-and-fast rules, but I would say it's better to err on the side of more specialized applications. Ideally an application should handle just one functional concern: i.e. "tagging" or "commenting" or "auth/auth" or "posts." This type of design will also help you reuse available open source applications instead of reinventing the wheel (i.e. Django comes with auth and comments apps, django-tagging or django-taggable can almost certainly do what you need, etc).
Generic foreign keys can help you decouple applications such as tagging or commenting that might be applied to models from several other applications.

You should try and separate the project in as much applications as possible. For most projects an application will not contain more than 5 models. For example a project like SO would have separate applications for UsersProfiles, Questions, Tags (there's a ready one in django for this), etc. If there was a system with static pages that'd be a separate application too (there are ready ones for this purpose). You should also try and make your applications as generic as possible, so you may reuse them in other projects. There's a good presentation on reusable apps.

Just like any set of dependencies... try to find the most useful stand-alone aspects of the project and make those stand-alone apps. Other Django Apps will have higher level functionality, and reuse the parts of the lowest level apps that you have set up.
In my project, I have a calendar app with its own Event object in its models. I also have a carpool database set up, and for the departure time and the duration I use the calendar's Event object right in my RideShare tables. The carpooling database is calendar-aware, and gets all the nice .ics export and calendar views from the calendar app for 'free.'
There are some tricks to getting the Apps reusable, like naming the templates directory: project/app2/templates/app2/index.html. This lets you refer to app2/index.html from any other app, and get the right template. I picked that one up looking at the built-in reusable apps in Django itself. Pinax is a bit of a monster size-wise but it also demonstrates a nice reusable App structure.
If in doubt, forget about reusable apps for now. Put all your messages and polls in one app and get through one rev. You'll discover during the process what steps feel unnecessary, and could be broken out as something stand-alone in the future.

A good question to ask yourself when deciding whether or not to write an app is "could I use this in another project?". If you think you could, then consider what it would take to make the application as independent as possible; How can you reduce the dependancies so that the app doesn't rely on anything specific to a particular project.
Some of the ways you can do this are:
Giving each app its own urls.py
Allowing model types to be passed in as parameters rather than explicitly declaring what models are used in your views. Generic views use this principle.
Make your templates easily overridden by having some sort of template_name parameter passed in your urls.py
Make sure you can do reverse url lookups with your objects and views. This means naming your views in the urls.py and creating get_absolute_url methods on your models.
In some cases like Tagging, GenericForeignKeys can be used to associate a model in your app to any other model, regardless of whether it has ForeignKeys "looking back" at it.

I'll tell you how I am approaching such question: I usually sit with a sheet of paper and draw the boxes (functionalities) and arrows (interdependencies between functionalities). I am sure there are methodologies or other things that could help you, but my approach usually works for me (YMMV, of course).
Knowing what a site is supposed to be is basic, though. ;)