Django Project Structure

Gambaran Besar Yang Perlu Dipahami Sejak Awal

Di Django, ada pemisahan konsep yang strict antara project dan app. Ini salah satu konsep paling penting yang harus kita pahami sejak awal, karena ini akan mempengaruhi setiap keputusan kita terkait di mana kita harus meletakkan kode.

Begini cara membayangkannya: kotanya sendiri tidak menjalankan bisnis apapun. Tugas dari kota hanya menyediakan infrastruktur seperti jalan, zonasi, dan utilitas, supaya semua bisa bekerja sama satu sama lain. Gedung-gedung di dalam kota tersebut lah yang sebenarnya menjalankan proses bisnis. Sama persis di Django: project cuma menyambungkan semuanya, app-lah yang melakukan pekerjaan sesungguhnya.

Struktur Django Kita Saat Ini

Saat ini, setelah melakukan set up virtual environment, struktur folder kita adalah seperti ini:

my-drf-project/
├── .venv/
└── requirements.txt

Sekarang kita buat project Django di dalamnya. Jalankan perintah-perintah ini:

1
2
3

cd my-drf-project
source .venv/bin/activate
django-admin startproject config .

Tanda . (titik) pada akhir perintah django-admin startproject config . itu penting. Titik tersebut artinya adalah kita meminta Django untuk meletakkan manage.py di folder yang sama, bukan membuat folder baru di dalamnya. Menggunakan nama config adalah cara yang umum dan disarankan.

Setelah menjalankan perintah diatas, struktur folder kita akan seperti ini:

my-drf-project/
├── .venv/
├── requirements.txt
├── manage.py           <-- entry point dari project
└── config/             <-- project package
    ├── __init__.py
    ├── settings.py     <-- global configuration
    ├── urls.py         <-- router URL utama
    ├── asgi.py         <-- async server gateway
    └── wsgi.py         <-- sync server gateway

Perbedaan Folder Project dan App

Folder config/ (project package) adalah “otak” dari aplikasi Django kita. Di situ tidak ada business logic sama sekali dan hanya berisi:

• Global settings (settings.py)
• Tabel URL utama (urls.py)
• Entry point server (wsgi.py, asgi.py)

Anggap saja ini sebagai layer infrastruktur. Tugasnya cuma menyambungkan semua bagian, bukan membangun fitur apapun.

Folder app adalah tempat semua business logic berada. Setiap app harus mewakili satu area tanggung jawab yang spesifik. Misalnya, di API e-commerce kamu akan punya app terpisah untuk products, orders, dan users, bukan satu app raksasa yang mengurus semuanya.

Sekarang mari coba untuk buat app pertama kita:

1

python manage.py startapp books

Struktur folder kita sekarang jadi:

my-drf-project/
├── .venv/
├── requirements.txt
├── manage.py
├── config/
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   ├── asgi.py
│   └── wsgi.py
└── books/              <-- app kita
    ├── __init__.py
    ├── admin.py        <-- meregistrasi models ke django admin
    ├── apps.py         <-- class konfigurasi app
    ├── migrations/     <-- riwayat perubahan skema database
    │   └── __init__.py
    ├── models.py       <-- definisi tabel database
    ├── tests.py        <-- unit tests
    └── views.py        <-- request handlers (logika API)

Jika kita perlu menjelaskannya dalam satu kalimat: folder project untuk mengkonfigurasi sistemnya, folder app untuk membangun fitur.

Kenapa DRF Perlu Konfigurasi Khusus

Django sama sekali tidak tahu kalau DRF itu ada sampai kamu memberitahunya secara eksplisit. Ini karena DRF hanyalah package pihak ketiga, dan memang Django sengaja dirancang untuk bisa di-plug in sesuka hati.

Ketika kamu menambahkan 'rest_framework' ke INSTALLED_APPS, tiga hal terjadi:

1. Django mendaftarkan built-in views milik DRF – template API HTML yang browsable, view login/logout untuk tampilan di browser.
2. Django dapat menemukan template tags milik DRF – HTML renderer yang memberikan tampilan API browser interaktif yang menggunakan sistem template milik Django.
3. Dictionary settings REST_FRAMEWORK menjadi aktif – tanpa mendaftarkan 'rest_framework' ke INSTALLED_APPS, apapun yang ditulis pada REST_FRAMEWORK = {…} dalam settings.py akan diabaikan.

Hal yang sama berlaku untuk app books kita. Kalau kita sudah membuat models di books/models.py tapi lupa menambahkan 'books' ke INSTALLED_APPS, Django tidak akan pernah menjalankan migrations untuk books, dan tabel di database-nya pun tidak akan pernah dibuat.

Cara mengintegrasikan DRF di settings.py

Buka config/settings.py. Cari list INSTALLED_APPS dan ubah menjadi seperti ini:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',

    # Third-party
    'rest_framework',

    # My apps
    'books',
]

Urutan mengisi INSTALLED_APPS perlu diperhatikan agar mudah dibaca:

• App / Settings bawaan Django di paling atas
• Package pihak ketiga di tengah
• App buatan kita di paling bawah

Sekarang tambahkan konfigurasi dictionary REST_FRAMEWORK di dalam settings.py (sebaiknya diletakkan di bagian setelah settings bawaan Django):

1
2
3
4
5
6
7
8
9

REST_FRAMEWORK = {
    'DEFAULT_RENDERER_CLASSES': [
        'rest_framework.renderers.JSONRenderer',
        'rest_framework.renderers.BrowsableAPIRenderer',  # remove in production
    ],
    'DEFAULT_PARSER_CLASSES': [
        'rest_framework.parsers.JSONParser',
    ],
}

Untuk saat ini, Hal yang penting adalah memahami bahwa seluruh settingan default DRF disimpan di satu dictionary ini, tidak tersebar di file yang berbeda-beda.

Dimana Configuration Files Terletak

Ada 2 jawaban untuk pertanyaan ini. Begini penjelasannya:

Untuk belajar (yang sedang kita lakukan):

config/
└── settings.py     <-- semua di satu file, untuk belajar

Untuk project sebenarnya (satu file per keperluan):

config/
├── settings/
│   ├── __init__.py     <-- secara default import dari base.py
│   ├── base.py         <-- settings yang dipakai semua environment
│   ├── development.py  <-- override untuk local dev (DEBUG=True, dll.)
│   └── production.py   <-- override untuk prod (DEBUG=False, DB asli, dll.)

File __init__.py untuk project sebenarnya kira-kira seperti ini:

1
2

from .base import *
from .development import *  # ganti ke production.py saat deploy

File-file konfigurasi lain yang akan kita temui:

File urls.py di level app tidak ada secara default, kita perlu tambahkan sendiri di dalam folder app. Ini dilakukan agar URL routing-nya modular: saat kita sudah punya banyak app, masing-masing app mengurus route-nya sendiri, dan config/urls.py tinggal meng-include semuanya.

Memastikan Semua Berfungsi

Jalankan dua perintah ini:

1
2

python manage.py check
python manage.py runserver

python manage.py check memvalidasi konfigurasi kamu tanpa perlu menghidupkan server. runserver seharusnya berjalan di http://127.0.0.1:8000/.

Kalau ada pesan System check identified no issues, artinya struktur project dan settings kita sudah tersambung dengan benar.

Overview: Bagaimana Semuanya Terhubung

1
2
3
4
5

config/settings.py  →  apa yang ada di django (INSTALLED_APPS)
config/urls.py      →  bagaimana request di-route
books/models.py     →  bentuk data
books/views.py      →  yang dilakukan oleh API terhadap request
books/urls.py       →  URLs men-trigger views mana

Masing-masing file punya satu tugas. File A tidak mengurus tanggung jawab file B dan lainnya. Ini adalah filosofi dari Django, dan konsep inilah yang membuat project DRF yang besar tetap mudah di-maintain.

Foto cover oleh dqnguyen15 dari Unsplash