Setiap tahun ada framework baru yang menjanjikan kecepatan dan kemudahan. Saya sudah mencoba banyak di antaranya. Tapi ketika harus mengirim produk yang benar-benar dipakai orang — bukan demo, bukan proyek akhir pekan — saya selalu kembali ke Django.
Autentikasi, ORM, migrasi, admin panel, proteksi CSRF, manajemen sesi. Semuanya sudah ada sejak menit pertama. Waktu yang biasanya habis untuk merakit potongan-potongan itu bisa langsung dipakai membangun fitur yang sebenarnya.
Ini terdengar sepele sampai kamu pernah menghabiskan tiga hari hanya untuk menyambungkan sistem login yang aman di framework minimalis.
ORM Django bukan yang paling canggih. Tapi setelah bertahun-tahun memakainya, saya hampir selalu bisa menebak query SQL apa yang akan dihasilkan sebuah baris kode. Itu jauh lebih berharga daripada kepintaran yang tidak terduga.
Teknologi yang membosankan adalah teknologi yang bisa kamu andalkan jam tiga pagi.
Keberatan lama soal Django — "tidak bisa async" — sudah tidak berlaku. View async, ORM async, dan dukungan ASGI penuh sudah tersedia sejak beberapa versi lalu. Untuk aplikasi yang banyak menunggu I/O, seperti memanggil API LLM, ini penting.
async def ringkas(request):
async for artikel in Artikel.objects.filter(status="draft"):
await proses(artikel)
return JsonResponse({"ok": True})Hampir setiap masalah umum sudah ada paketnya, dan paket itu biasanya sudah teruji bertahun-tahun di lingkungan produksi orang lain. Ketika ada masalah pukul dua pagi, kemungkinan besar sudah ada orang yang mengalaminya dan menulis solusinya.
Kalau yang kamu bangun murni API tanpa halaman HTML, tanpa admin, tanpa form — FastAPI kemungkinan lebih pas. Kalau butuh WebSocket sebagai inti produk, ada pilihan yang lebih tepat.
Tapi untuk aplikasi web yang punya database, pengguna, dan aturan bisnis, Django masih sulit dikalahkan.
""", }, { "title": "FastAPI atau Django? Cara Saya Memutuskan", "category": "Python & Django", "tags": ["fastapi", "django", "python", "api"], "excerpt": "Bukan soal mana yang lebih baik. Ini soal bentuk masalah yang sedang kamu selesaikan.", "content": """Pertanyaan ini muncul hampir di setiap proyek baru, dan jawabannya jarang sesederhana "pakai yang lebih cepat".
Bukan "mana yang lebih cepat" — keduanya cukup cepat untuk 99% kasus nyata. Pertanyaan yang benar adalah: berapa banyak yang harus saya bangun sendiri?
Kalau tiga dari lima poin di atas kamu butuhkan, Django menghemat berminggu-minggu kerja.
from fastapi import FastAPI
from pydantic import BaseModel
app = FastAPI()
class Permintaan(BaseModel):
teks: str
bahasa: str = "id"
@app.post("/ringkas")
async def ringkas(req: Permintaan):
hasil = await panggil_llm(req.teks, req.bahasa)
return {"ringkasan": hasil}Validasi, dokumentasi, dan type safety — semuanya dari satu deklarasi class. Untuk API, ini memang menyenangkan.
Di beberapa proyek saya menjalankan Django untuk aplikasi utama — pengguna, data, admin — lalu FastAPI terpisah untuk beban kerja AI yang butuh streaming dan konkurensi tinggi. Keduanya berbagi database yang sama.
Ini bukan kompromi. Ini memakai alat sesuai bentuk pekerjaannya.
Orang memilih FastAPI karena "lebih modern", lalu tiga bulan kemudian menghabiskan waktu membangun sistem admin, autentikasi, dan migrasi — persis yang sudah gratis di Django.
Kecepatan framework hampir tidak pernah jadi hambatan. Yang jadi hambatan biasanya query database yang buruk dan panggilan API eksternal yang lambat.
""", }, { "title": "Otomasi Tanpa Coding dengan n8n: Panduan Mulai", "category": "AI & Automation", "tags": ["n8n", "automation", "ai"], "excerpt": "Tidak semua otomasi layak ditulis dengan kode. Kadang seret-lepas sudah cukup — dan jauh lebih mudah dirawat.", "content": """Sebagai developer, refleks pertama saya selalu menulis kode. Tapi setelah beberapa kali membangun skrip integrasi yang akhirnya tidak ada yang berani menyentuh, saya belajar: tidak semua otomasi layak jadi kode.
n8n adalah alat otomasi berbasis alur visual. Kamu menyusun node — pemicu, aksi, kondisi — lalu menyambungkannya. Mirip Zapier, dengan tiga perbedaan penting: bisa di-self-host, bisa menjalankan kode JavaScript atau Python di tengah alur, dan tidak menagih per eksekusi.
docker run -d --name n8n \\
-p 5678:5678 \\
-v n8n_data:/home/node/.n8n \\
-e GENERIC_TIMEZONE="Asia/Jakarta" \\
n8nio/n8nBuka http://localhost:5678 dan alurmu sudah bisa dibuat.
Contoh nyata yang saya pakai: setiap ada pesan masuk di form kontak website, ringkas isinya dengan LLM, tentukan tingkat prioritasnya, lalu kirim ke Slack — hanya kalau prioritasnya tinggi.
Webhook (pesan masuk)
↓
HTTP Request (kirim ke LLM untuk diringkas + dinilai)
↓
IF (prioritas == "tinggi")
↓ ↘
Slack Simpan ke SheetsMembangun ini dengan kode butuh sekitar 150 baris plus penanganan error. Di n8n: sepuluh menit, dan siapa pun di tim bisa mengubah ambang prioritasnya sendiri.
Pola yang paling sering saya pakai: Django menangani data dan aturan bisnis, lalu mengirim webhook ke n8n untuk urusan integrasi.
import httpx
async def kirim_ke_n8n(pesan):
async with httpx.AsyncClient() as client:
await client.post(
settings.N8N_WEBHOOK_URL,
json={"nama": pesan.name, "isi": pesan.message},
timeout=10,
)Django tetap bersih. Integrasi yang berubah-ubah tinggal diatur di n8n tanpa deploy ulang.
""", }, { "title": "Menyambungkan LLM ke Aplikasi Django", "category": "Tutorial", "tags": ["django", "llm", "ai", "python"], "excerpt": "Pola praktis untuk memanggil model bahasa dari Django tanpa membuat aplikasimu jadi lambat.", "content": """Menambahkan LLM ke aplikasi Django itu mudah. Menambahkannya tanpa merusak pengalaman pengguna — itu bagian yang perlu dipikirkan.
Panggilan ke LLM bisa memakan 2 sampai 30 detik. Kalau kamu melakukannya di dalam view biasa, pengguna menatap layar kosong dan koneksi HTTP-mu tertahan selama itu.
Ada tiga pola untuk mengatasinya.
Untuk tugas ringan seperti klasifikasi atau ekstraksi, async view sudah cukup.
from anthropic import AsyncAnthropic
from django.http import JsonResponse
client = AsyncAnthropic()
async def klasifikasi(request):
pesan = request.POST.get("pesan", "")
respons = await client.messages.create(
model="claude-opus-5",
max_tokens=1024,
messages=[{
"role": "user",
"content": f"Klasifikasikan pesan ini sebagai keluhan/pertanyaan/pujian. "
f"Jawab satu kata saja.\\n\\n{pesan}",
}],
)
teks = next(b.text for b in respons.content if b.type == "text")
return JsonResponse({"kategori": teks.strip()})Kalau hasilnya panjang, jangan buat pengguna menunggu sampai selesai. Alirkan per potongan.
from django.http import StreamingHttpResponse
async def tulis_draf(request):
async def aliran():
async with client.messages.stream(
model="claude-opus-5",
max_tokens=8000,
messages=[{"role": "user", "content": request.GET["topik"]}],
) as stream:
async for teks in stream.text_stream:
yield teks
return StreamingHttpResponse(aliran(), content_type="text/plain")Teks mulai muncul dalam hitungan detik, bukan puluhan detik. Perbedaan yang dirasakan pengguna sangat besar.
Untuk pekerjaan yang butuh menit — menganalisis dokumen, memproses banyak baris — jangan tahan permintaan HTTP sama sekali. Lempar ke antrean.
@shared_task
def analisis_dokumen(dokumen_id):
dok = Dokumen.objects.get(pk=dokumen_id)
respons = client.messages.create(
model="claude-opus-5",
max_tokens=16000,
thinking={"type": "adaptive"},
output_config={"effort": "high"},
messages=[{"role": "user", "content": dok.isi}],
)
dok.ringkasan = next(b.text for b in respons.content if b.type == "text")
dok.save(update_fields=["ringkasan"])View-nya cukup memanggil analisis_dokumen.delay(dok.pk) dan langsung membalas. Pengguna dapat notifikasi ketika selesai.
Simpan hasilnya. Panggilan LLM tidak gratis dan tidak cepat. Kalau pertanyaan yang sama bisa muncul lagi, simpan jawabannya di database atau Redis.
Batasi lajunya. Tanpa rate limit, satu pengguna iseng bisa menghabiskan kuota API-mu dalam hitungan menit.
Siapkan jalur gagal. API eksternal bisa lambat, penuh, atau menolak permintaan. Tentukan apa yang terjadi pada pengguna ketika itu terjadi — jangan biarkan halamannya sekadar error.
try:
hasil = panggil_llm(teks)
except Exception:
logger.exception("LLM gagal")
hasil = None # tampilkan versi tanpa AI, jangan matikan fiturnyaPertanyaan yang paling sering saya dengar dari klien: "Bisa nggak AI-nya menjawab berdasarkan dokumen kami sendiri?"
Bisa. Namanya RAG — Retrieval-Augmented Generation. Dan ini jauh lebih sederhana daripada kedengarannya.
Sebelum bertanya ke model, cari dulu potongan dokumen yang paling relevan, lalu selipkan potongan itu ke dalam pertanyaan.
Itu saja. Tidak ada pelatihan ulang, tidak ada fine-tuning, tidak ada GPU.
Dokumen → dipotong → jadi embedding → disimpan di database
↓
Pertanyaan → jadi embedding → cari yang mirip →┘
↓
Potongan relevan + pertanyaan → LLM → JawabanMenyuapkan seluruh dokumen 200 halaman ke setiap pertanyaan itu mahal dan justru menurunkan kualitas jawaban — informasi pentingnya tenggelam di antara yang tidak relevan.
Potong per bagian yang bermakna. Untuk dokumen berstruktur, potong per heading. Untuk teks mengalir, sekitar 500–1000 kata dengan sedikit tumpang tindih supaya konteks di batas potongan tidak hilang.
Embedding mengubah teks jadi deretan angka, di mana teks yang maknanya mirip menghasilkan angka yang berdekatan. Ini yang membuat pencarian bekerja berdasarkan makna, bukan kecocokan kata.
Pertanyaan "bagaimana cara refund" akan menemukan bagian berjudul "Pengembalian Dana" — meski tidak ada satu kata pun yang sama.
Banyak orang langsung memasang Pinecone atau Weaviate. Untuk kebanyakan kasus, itu berlebihan. PostgreSQL dengan ekstensi pgvector sudah lebih dari cukup.
CREATE EXTENSION vector;
CREATE TABLE potongan (
id SERIAL PRIMARY KEY,
dokumen_id INT,
isi TEXT,
embedding vector(1536)
);
CREATE INDEX ON potongan
USING hnsw (embedding vector_cosine_ops);Mencari yang paling mirip:
SELECT isi
FROM potongan
ORDER BY embedding <=> %s
LIMIT 5;def jawab(pertanyaan):
vektor = buat_embedding(pertanyaan)
potongan = cari_terdekat(vektor, limit=5)
konteks = "\\n\\n---\\n\\n".join(p.isi for p in potongan)
respons = client.messages.create(
model="claude-opus-5",
max_tokens=4000,
messages=[{
"role": "user",
"content": (
"Jawab pertanyaan berikut HANYA berdasarkan konteks di bawah. "
"Kalau jawabannya tidak ada di konteks, katakan tidak tahu.\\n\\n"
f"KONTEKS:\\n{konteks}\\n\\nPERTANYAAN: {pertanyaan}"
),
}],
)
return next(b.text for b in respons.content if b.type == "text")Kualitas RAG hampir seluruhnya ditentukan oleh tahap pencarian, bukan modelnya. Kalau potongan yang diambil salah, model sepintar apa pun akan menjawab salah.
Jadi ketika hasilnya mengecewakan, jangan langsung ganti model. Cek dulu: potongan apa yang sebenarnya diambil? Sembilan dari sepuluh kali, masalahnya ada di sana.
Satu instruksi kecil yang sangat penting: "kalau jawabannya tidak ada di konteks, katakan tidak tahu". Tanpa itu, model akan mengarang dengan percaya diri.
""", }, { "title": "Async Python: Kapan Benar-benar Berguna", "category": "Python & Django", "tags": ["python", "async", "django"], "excerpt": "Async bukan tombol ajaib pembuat cepat. Ini alat untuk satu masalah spesifik — dan sering dipakai di tempat yang salah.", "content": """Ada kesalahpahaman yang sangat umum: menambahkan async membuat kode jadi lebih cepat. Tidak begitu cara kerjanya.
Async tidak membuat satu tugas selesai lebih cepat. Async membuat programmu bisa mengerjakan hal lain sambil menunggu.
Kalau programmu menghabiskan waktu menghitung, async tidak menolong sama sekali — malah menambah beban. Kalau programmu menghabiskan waktu menunggu, async bisa mengubah segalanya.
Menunggu (async menolong): panggilan API, query database, baca-tulis file, permintaan HTTP.
Menghitung (async tidak menolong): mengolah gambar, kalkulasi berat, parsing data besar, kompresi.
Memanggil lima API secara berurutan:
import httpx, time
def ambil_semua(urls):
hasil = []
with httpx.Client() as client:
for url in urls:
hasil.append(client.get(url).json())
return hasil
# 5 API × 2 detik = 10 detikVersi async:
import asyncio, httpx
async def ambil_semua(urls):
async with httpx.AsyncClient() as client:
tugas = [client.get(url) for url in urls]
respons = await asyncio.gather(*tugas)
return [r.json() for r in respons]
# 5 API bersamaan = ~2 detikLima kali lebih cepat. Bukan karena Python jadi lebih kencang, tapi karena waktu tunggunya ditumpuk, bukan diantre.
Django mendukung async view dan async ORM. Tapi jangan asal mengubah semua view jadi async.
# Berguna: view yang memanggil layanan eksternal
async def dashboard(request):
cuaca, kurs, berita = await asyncio.gather(
ambil_cuaca(),
ambil_kurs(),
ambil_berita(),
)
return render(request, "dashboard.html", {...})# Tidak berguna: view yang cuma query database sederhana
async def daftar_produk(request):
produk = [p async for p in Produk.objects.all()]
return render(request, "produk.html", {"produk": produk})
# Versi sync-nya sama cepat, dan lebih mudah dibacaMemanggil kode sync yang lambat di dalam fungsi async. Ini memblokir seluruh event loop — bukan cuma satu permintaan, tapi semua permintaan yang sedang ditangani proses itu.
# BAHAYA — memblokir semuanya
async def view(request):
time.sleep(5) # salah
requests.get(url) # salah, requests itu sync
hasil = query_berat() # salah
# BENAR
async def view(request):
await asyncio.sleep(5)
await httpx_client.get(url)
hasil = await sync_to_async(query_berat)()Pakai async kalau kode kamu banyak menunggu jaringan. Lewati kalau tidak. Kompleksitas tambahannya nyata, dan hanya sepadan kalau kamu benar-benar mendapat manfaatnya.
""", }, { "title": "Celery: Memindahkan Pekerjaan Berat ke Belakang Layar", "category": "Tutorial", "tags": ["celery", "django", "python", "automation"], "excerpt": "Kalau ada pekerjaan yang butuh lebih dari beberapa detik, jangan biarkan pengguna menunggunya.", "content": """Aturan sederhana: kalau sebuah pekerjaan butuh lebih dari dua atau tiga detik, jangan kerjakan di dalam permintaan HTTP.
Kirim email, olah gambar, buat laporan, panggil LLM — semuanya masuk kategori ini.
Permintaan HTTP yang lama menahan worker server. Kalau semua worker tertahan, situsmu berhenti melayani siapa pun. Browser juga punya batas waktu sendiri — pengguna melihat error meski pekerjaannya sebenarnya berhasil.
pip install celery redisconfig/celery.py:
import os
from celery import Celery
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "config.settings")
app = Celery("config")
app.config_from_object("django.conf:settings", namespace="CELERY")
app.autodiscover_tasks()config/__init__.py:
from .celery import app as celery_app
__all__ = ("celery_app",)settings.py:
CELERY_BROKER_URL = "redis://localhost:6379/0"
CELERY_RESULT_BACKEND = "redis://localhost:6379/1"
CELERY_TASK_TIME_LIMIT = 30 * 60
CELERY_TASK_ACKS_LATE = Truefrom celery import shared_task
@shared_task(bind=True, max_retries=3)
def kirim_laporan(self, pengguna_id):
try:
pengguna = Pengguna.objects.get(pk=pengguna_id)
berkas = susun_laporan(pengguna)
kirim_email(pengguna.email, berkas)
except Exception as exc:
raise self.retry(exc=exc, countdown=60)Memanggilnya dari view:
def minta_laporan(request):
kirim_laporan.delay(request.user.pk)
return JsonResponse({"pesan": "Laporan sedang dibuat, kami kabari lewat email."})View-nya membalas seketika. Pekerjaannya jalan di belakang layar.
1. Kirim ID, bukan objek.
kirim_laporan.delay(pengguna.pk) # benar
kirim_laporan.delay(pengguna) # salah — objek harus diserialisasiObjek yang diserialisasi bisa jadi basi sebelum tugasnya jalan.
2. Buat tugasnya aman diulang. Celery bisa menjalankan ulang tugas yang gagal. Kalau tugasmu mengirim email, pastikan tidak mengirim dua kali.
3. Selalu pasang batas waktu. Tanpa itu, satu tugas yang macet bisa menahan worker selamanya.
from celery.schedules import crontab
app.conf.beat_schedule = {
"bersihkan-sesi-harian": {
"task": "core.tasks.bersihkan_sesi",
"schedule": crontab(hour=3, minute=0),
},
}Celery butuh Redis atau RabbitMQ, plus proses worker terpisah. Untuk kebutuhan sederhana, itu berlebihan.
Kalau tugasmu sedikit dan tidak kritis, django-q2 atau huey lebih ringan. Kalau cuma butuh satu hal jalan tiap malam, cron biasa memanggil manage.py sudah cukup — tidak semua hal butuh antrean.
Setiap kali topik pencarian semantik muncul, saran pertama yang keluar selalu: pasang Pinecone, Weaviate, atau Qdrant.
Untuk kebanyakan proyek, itu menambah satu layanan lagi untuk dirawat, dibayar, dan dimonitor — padahal PostgreSQL yang sudah jalan bisa melakukannya.
CREATE EXTENSION IF NOT EXISTS vector;Sebagian besar layanan Postgres terkelola sudah menyediakannya. Untuk server sendiri, satu perintah instalasi paket.
pip install pgvector djangofrom django.db import models
from pgvector.django import VectorField, HnswIndex
class Potongan(models.Model):
dokumen = models.ForeignKey("Dokumen", on_delete=models.CASCADE)
isi = models.TextField()
embedding = VectorField(dimensions=1536)
class Meta:
indexes = [
HnswIndex(
name="potongan_embedding_idx",
fields=["embedding"],
m=16,
ef_construction=64,
opclasses=["vector_cosine_ops"],
),
]from pgvector.django import CosineDistance
def cari_mirip(vektor_pertanyaan, jumlah=5):
return (
Potongan.objects
.annotate(jarak=CosineDistance("embedding", vektor_pertanyaan))
.order_by("jarak")[:jumlah]
)Bisa digabung dengan filter biasa. Ini kelebihan terbesarnya. Kamu bisa mencari berdasarkan makna sekaligus menyaring dengan kolom biasa, dalam satu query.
Potongan.objects
.filter(dokumen__pemilik=request.user)
.filter(dokumen__dibuat__gte=bulan_lalu)
.annotate(jarak=CosineDistance("embedding", vektor))
.order_by("jarak")[:5]Di vector database terpisah, hal ini biasanya berarti dua query dan penggabungan manual di sisi aplikasi.
Ikut transaksi database. Kalau penyimpanan gagal, semuanya di-rollback bersama. Tidak ada kondisi di mana dokumen tersimpan tapi embedding-nya hilang.
Ikut backup yang sudah ada. Tidak ada layanan tambahan yang perlu dicadangkan terpisah.
Jujur soal batasannya: kalau kamu punya puluhan juta vektor dan butuh latensi di bawah sepuluh milidetik, vector database khusus memang lebih unggul. Mereka dibangun untuk itu.
Tapi kalau jumlahnya di bawah satu juta — dan itu mencakup hampir semua aplikasi internal, dokumentasi produk, dan basis pengetahuan perusahaan — pgvector cepat dan jauh lebih sederhana.
Mulai dengan pgvector. Ukur. Pindah kalau memang terbukti tidak cukup. Jangan menambah layanan untuk masalah yang belum kamu miliki.
""", }, { "title": "Membangun AI Agent yang Benar-benar Dipakai", "category": "AI & Automation", "tags": ["ai", "llm", "automation", "python"], "excerpt": "Kebanyakan proyek AI agent gagal bukan karena modelnya kurang pintar, tapi karena masalahnya salah pilih.", "content": """Saya sudah membangun beberapa AI agent. Sebagian dipakai setiap hari. Sebagian lagi ditinggalkan dalam dua minggu.
Perbedaannya hampir tidak pernah soal model.
Sebelum membangun agent, jawab empat hal ini dengan jujur:
if-else, tulis saja sebagai kode. Lebih murah, lebih cepat, dan bisa dites.Kalau ada satu saja yang jawabannya "tidak", pertimbangkan ulang.
1. Satu panggilan. Klasifikasi, ringkasan, ekstraksi. Satu permintaan, satu jawaban. Ini menyelesaikan lebih banyak masalah nyata daripada yang orang kira.
2. Alur terkendali. Beberapa langkah, tapi kamu yang menentukan urutannya. Model mengerjakan bagian yang butuh pemahaman bahasa; kode mengurus alurnya.
def proses_tiket(tiket):
kategori = klasifikasi(tiket.isi) # LLM
if kategori == "teknis":
konteks = cari_dokumentasi(tiket.isi) # kode
balasan = susun_balasan(tiket, konteks) # LLM
else:
balasan = teruskan_ke_manusia(tiket) # kode
return balasanSebagian besar yang orang sebut "AI agent" sebenarnya cukup di tingkat ini. Bisa diprediksi, bisa dites, bisa di-debug.
3. Agent sebenarnya. Model yang memutuskan sendiri langkah apa berikutnya, memakai alat yang kamu sediakan, sampai tugasnya selesai. Paling fleksibel, paling sulit dikendalikan.
Kualitas agent sangat ditentukan oleh alat yang kamu berikan. Beberapa prinsip yang saya pegang:
Deskripsinya harus menjelaskan kapan dipakai, bukan cuma apa fungsinya. "Cari data pelanggan berdasarkan email — gunakan ketika pengguna menyebut alamat email atau menanyakan riwayat akun" jauh lebih efektif daripada "Cari pelanggan".
Alat yang berbahaya harus dipisah dan dijaga. Jangan beri satu alat jalankan_sql. Buat alat spesifik: cari_pesanan, ubah_status — masing-masing dengan validasi sendiri.
Sedikit tapi jelas lebih baik daripada banyak. Dua puluh alat membuat model bingung memilih.
from anthropic import Anthropic, beta_tool
client = Anthropic()
@beta_tool
def cari_pesanan(email: str) -> str:
\"\"\"Cari pesanan terakhir seorang pelanggan.
Gunakan ketika pengguna menanyakan status pesanan
dan menyebutkan alamat email.
Args:
email: Alamat email pelanggan.
\"\"\"
pesanan = Pesanan.objects.filter(email=email).order_by("-dibuat")[:5]
if not pesanan:
return "Tidak ada pesanan untuk email tersebut."
return "\\n".join(f"{p.kode}: {p.get_status_display()}" for p in pesanan)
runner = client.beta.messages.tool_runner(
model="claude-opus-5",
max_tokens=8000,
tools=[cari_pesanan],
messages=[{"role": "user", "content": pertanyaan_pengguna}],
)
for pesan in runner:
...Agent pertama saya diberi akses tulis ke database sejak hari pertama. Berhasil sembilan dari sepuluh kali. Yang kesepuluh menghabiskan satu hari penuh untuk membereskannya.
Sekarang aturannya tetap: mulai dari hanya-baca. Amati keputusannya selama beberapa minggu. Baru berikan izin menulis satu per satu, masing-masing dengan konfirmasi.
Kecerdasan model bukan bagian yang sulit. Yang sulit adalah membangun pagar pengaman di sekelilingnya.
""", }, { "title": "Deploy Aplikasi Python: Dari Laptop ke Server", "category": "Tutorial", "tags": ["deployment", "python", "django", "docker"], "excerpt": "Jalan di laptop bukan berarti jalan di server. Ini yang berubah, dan kenapa.", "content": """Perbedaan terbesar antara aplikasi Python dan aplikasi PHP terlihat justru saat deploy. PHP tinggal ditaruh; Python butuh proses yang hidup terus.
manage.py runserver dirancang untuk pengembangan. Satu proses, tanpa optimasi, dengan peringatan keamanan yang jelas di dokumentasi Django.
Untuk produksi kamu butuh server WSGI — biasanya Gunicorn — dan di depannya reverse proxy seperti Nginx.
Pengunjung → Nginx → Gunicorn → Django
│
└─ melayani /static/ dan /media/ langsungNginx menangani koneksi lambat, HTTPS, dan berkas statis. Gunicorn menjalankan kode Python-mu di beberapa proses sekaligus.
pip install gunicorn
gunicorn config.wsgi:application \\
--bind 127.0.0.1:8000 \\
--workers 3 \\
--timeout 60 \\
--access-logfile -Aturan umum jumlah worker: (2 × jumlah CPU) + 1. Untuk VPS 1 CPU, tiga sudah pas.
Proses yang dijalankan manual akan mati saat kamu keluar dari SSH. Serahkan ke systemd.
[Unit]
Description=Gunicorn untuk situs saya
After=network.target
[Service]
User=www-data
WorkingDirectory=/var/www/situs
Environment="PATH=/var/www/situs/venv/bin"
ExecStart=/var/www/situs/venv/bin/gunicorn \\
config.wsgi:application --bind 127.0.0.1:8000 --workers 3
Restart=always
[Install]
WantedBy=multi-user.targetsudo systemctl enable --now situs
sudo systemctl status situsDEBUG=False — wajib. Dengan True, pesan error menampilkan isi settings-mu ke publikSECRET_KEY baru, berbeda dari yang di laptopALLOWED_HOSTS diisi domain aslimucollectstaticSatu hal yang sering mengejutkan: begitu DEBUG=False, Django berhenti melayani berkas statis. Kalau Nginx belum diatur, situsmu tampil tanpa CSS sama sekali. WhiteNoise adalah jalan pintas yang baik untuk ini.
python manage.py check --deploy
python manage.py migrate
python manage.py collectstatic --noinput
python manage.py createsuperuserPerintah pertama akan menyebutkan pengaturan keamanan yang belum aktif. Perhatikan semuanya.
Docker menyelesaikan masalah "jalan di laptop saya". Tapi menambah satu lapisan lagi untuk dipelajari dan di-debug.
Untuk satu aplikasi di satu VPS, deploy langsung sering kali lebih sederhana. Docker mulai sepadan ketika kamu punya beberapa layanan, beberapa lingkungan, atau tim yang perlu setup identik.
Backup database. Bukan "nanti", tapi sebelum pengguna pertama masuk. Satu cron harian yang menyimpan dump ke tempat lain sudah menyelamatkan banyak orang.
Pemantauan. Kamu perlu tahu situsmu mati sebelum penggunamu yang memberitahu.
Rencana rollback. Suatu saat deploy akan gagal. Tahu cara kembali ke versi sebelumnya dalam dua menit, bukan dua jam.
""", }, ] class Command(BaseCommand): help = "Bersihkan konten contoh dan isi blog dengan tulisan AI automation & Python." def handle(self, *args, **options): # ------------------------------------------------------------ bersihkan hapus = [ ("Komentar", Comment), ("Postingan", Post), ("Tag", Tag), ("Kategori", Category), ("Proyek", Project), ("Pengalaman kerja", Experience), ("Pendidikan", Education), ("Sertifikat", Certificate), ("Skill", Skill), ("Pesan masuk", ContactMessage), ] self.stdout.write(self.style.WARNING("Membersihkan konten lama...")) for label, model in hapus: jumlah = model.objects.count() model.objects.all().delete() if jumlah: self.stdout.write(f" - {label}: {jumlah} dihapus") # ---------------------------------------------------------------- skill for urutan, (nama, kategori, level, unggulan) in enumerate(SKILLS): Skill.objects.create( name=nama, category=kategori, level=level, order=urutan, is_featured=unggulan, ) # ------------------------------------------------------- kategori & tag kategori_map = {} for nama, warna, deskripsi in CATEGORIES: kategori_map[nama] = Category.objects.create( name=nama, color=warna, description=deskripsi ) tag_map = {nama: Tag.objects.create(name=nama) for nama in TAGS} # -------------------------------------------------------------- artikel sekarang = timezone.now() total = len(ARTICLES) for i, data in enumerate(ARTICLES): post = Post.objects.create( title=data["title"], post_type="article", excerpt=data["excerpt"], content=data["content"].strip(), category=kategori_map[data["category"]], status="published", # Terbit mundur beberapa hari supaya urutannya wajar. published_at=sekarang - timezone.timedelta(days=(total - i) * 4), is_pinned=data.get("pinned", False), allow_comments=True, ) post.tags.set([tag_map[t] for t in data["tags"] if t in tag_map]) # ------------------------------------------------------------- ringkasan self.stdout.write(self.style.SUCCESS("\nKonten baru siap:")) self.stdout.write(f" Skill : {Skill.objects.count()}") self.stdout.write(f" Kategori : {Category.objects.count()}") self.stdout.write(f" Tag : {Tag.objects.count()}") self.stdout.write(f" Artikel : {Post.objects.count()}") self.stdout.write( self.style.SUCCESS( "\nProyek, pengalaman, pendidikan, dan sertifikat sengaja dikosongkan.\n" "Profil dan social links tidak disentuh." ) )