Building a Multi-App Django Project: A Tech Attachee's Journey

As a tech attachee, understanding modern web development frameworks is crucial. One of the most powerful and versatile is Django, a high-level Python web framework that encourages rapid development and clean, pragmatic design. My recent task was to demonstrate Django's modularity by creating a single project with two distinct applications, each serving its own unique web page. This article outlines the step-by-step process I followed to achieve this.

The Vision: Modularity and Clarity

The core idea behind this exercise was to showcase how Django projects can be broken down into smaller, manageable applications. This approach promotes reusability, simplifies maintenance, and allows different functionalities to live in their own self-contained environments. My goal was to build a my_project that housed a first_app and a second_app, each with a dedicated browser page.

Phase 1: Setting the Foundation
The journey began with the fundamental steps of any Django project:

• Installing Django: First, ensuring Django was installed in my environment was paramount. A simple pip install django got the framework ready.
• Project Initialization:With Django installed, I created the main project directory using django-admin startproject my_project. This command laid out the essential project structure, including the core settings.pyand urls.pyfiles.

my_project/
├── my_project/
│   ├── __init__.py
│   ├── asgi.py
│   ├── settings.py  
│   ├── urls.py      
│   └── wsgi.py
└── manage.py 

• Navigating into the Project:I then cd my_project to move into the newly created project root, ready for the next steps.

Phase 2: Crafting the Applications
The next crucial step was to generate the individual applications within my main project. Django's startapp command makes this straightforward:

• Creating first_app: I executed python manage.py startapp first_app. This command generated the basic directory structure and files for my first independent application.
• Creating second_app**: **Following the same pattern, python manage.py startapp second_app brought my second application into existence. At this point, my project directory began to take shape, clearly showing the core folder alongside the first_app and second_app directories, all within the main MY_PROJECT root.

my_project/
├── my_project/
│   ├── __init__.py
│   ├── asgi.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── first_app/
│   ├── migrations/
│   ├── templates/
│   │   └── first_app/
│   │       └── index.html
│   ├── __init__.py
│   ├── admin.py
│   ├── apps.py
│   ├── models.py
│   ├── tests.py
│   ├── urls.py
│   └── views.py
├── second_app/
│   ├── migrations/
│   ├── templates/
│   │   └── second_app/
│   │       └── home.html
│   ├── __init__.py
│   ├── admin.py
│   ├── apps.py
│   ├── models.py
│   ├── tests.py
│   ├── urls.py
│   └── views.py
└── manage.py

NOTE:
So, while the name my_project is repeated, they represent two different things: one is the top-level directory, and the other is the actual Python package that contains your project's main configuration.

To avoid the repetition in the folder name, when you initially create a Django project, you can use a slightly different command:

django-admin startproject config .

(You can name that inner folder anything that is a valid Python package name. Common alternatives you'll see in the Django community include:

core: Often used for central or core project settings and utilities.

project: A straightforward name indicating it holds the project-level files.

main: Another simple and descriptive option.)

If you run this command from an empty directory, it will create the manage.py and the config (inner project folder) directly inside your current directory, avoiding the outer my_project folder name. However, the default django-admin startproject my_project is very common and usually doesn't cause issues once you understand the distinction.

Phase 3: Connecting the Pieces (Configuration)
A raw project and applications don't work together automatically. They need to be configured:

• Registering Apps in settings.py: I opened my_project/my_project/settings.py. Under the INSTALLED_APPS list, I added 'first_app' and 'second_app'. This tells Django to recognize and load these applications within the project. I also verified APP_DIRS: True was set in the TEMPLATES configuration, ensuring Django would look for templates inside each app's templates folder.

• Routing URLs in Project urls.py: The my_project/my_project/urls.py file is the project's central traffic controller. I modified it to include the URL patterns of my new applications:

# my_project/core/urls.py
from django.urls import path, include

urlpatterns = [
    path('admin/', admin.site.urls),
    path('first-app/', include('first_app.urls')),
    path('second-app/', include('second_app.urls')),
]

This setup ensures that any request starting with /first-app/ is directed to first_app's own URL patterns, and similarly for /second-app/.

Phase 4: Building App-Specific Pages
Each application needed its own view and template to display a unique page:

• first_app Logic and Display:

• I created my_project/first_app/urls.py to define the specific URL for this app (e.g., path('', views.index, name='index')).
• In my_project/first_app/views.py, I wrote a simple index function that renders a template: return render(request, 'first_app/index.html').
• Finally, I created the index.htmlfile inside my_project/first_app/templates/first_app/. This HTML included a welcoming message.

• second_app Logic and Display:

• I followed the same pattern, creating my_project/second_app/urls.py with a path('', views.home, name='home').
• The my_project/second_app/views.py contained a home function to render its template: return render(request, 'second_app/home.html')
• The home.html file was placed in my_project/second_app/templates/second_app/, similar to the first app, ensuring clear separation and containing a link back to the first app.

Phase 5: Bringing it All to Life
With all the code in place, the final steps were to get the server running:

• Database Migrations: Running python manage.py makemigrations and python manage.py migrate ensured Django's built-in database setup was complete, even though my apps didn't use models yet.
• Starting the Development Server:From the my_project root, python manage.py runserver launched Django's development server.

The Outcome: Two Live Applications!

Upon navigating to http://127.0.0.1:8000/first-app/ and http://127.0.0.1:8000/second-app/ in my browser, I was greeted with two distinct web pages, each served by its respective Django application. The navigation links between them worked , confirming the successful integration of components within a single Django project.

This exercise solidified my understanding of Django's project structure, URL routing(How web addresses work), view logic, and template rendering(how different parts of a website can show their own pages) – essential skills for any aspiring tech attaché. It highlighted how Django empowers developers to build scalable and organized web applications by embracing a modular design.