Selamat Datang di Seri Fleet Management
Ini adalah Part 1 dari seri tutorial 8 bagian di mana kita membangun Sistem Manajemen Armada dari nol — jenis sistem yang digunakan oleh perusahaan logistik energi dan distribusi untuk melacak ratusan truk BBM, mengelola pengemudi, dan mengoptimalkan rute pengiriman secara real-time.
Di akhir seri ini, Anda akan memahami cara berpikir developer senior dalam membangun aplikasi enterprise. Kita tidak hanya menulis kode — kita akan membuat keputusan arsitektur, menjelaskan mengapa kita memilih setiap teknologi, dan menunjukkan kesalahan yang tidak pernah dibahas kebanyakan tutorial.
Apa yang Akan Kita Bangun
Bayangkan Anda bekerja di perusahaan distribusi energi. Setiap hari, 200+ truk BBM meninggalkan gudang untuk mengirimkan bahan bakar ke SPBU di seluruh Indonesia. Anda perlu:
- 🗺️ Melacak setiap truk secara real-time di peta
- 👨✈️ Mengelola pengemudi — jadwal, sertifikasi, performa
- 📦 Melacak pengiriman — truk mana membawa apa, ke mana tujuannya
- ⛽ Memantau level BBM — mencegah pencurian, deteksi kebocoran
- 📊 Menghasilkan laporan — untuk compliance, billing, optimisasi
- 🔔 Mengirim alert ke operator — ketika sesuatu tidak beres
Ini bukan proyek mainan. Ini jenis sistem yang perusahaan bayar miliaran rupiah.
Apa itu Arsitektur Sistem?
Jika Anda baru mengenal arsitektur software, pikirkan seperti membangun rumah.
Anda bisa langsung pukul paku. Tapi pembangun profesional membuat denah terlebih dahulu: di mana dinding, di mana pipa air, bagaimana listrik mengalir. Arsitektur adalah denah dari software Anda.
Mengapa Arsitektur Penting
Inilah yang terjadi ketika tim melewatkan arsitektur:
Bulan 1: "Ayo bangun semuanya dalam satu app Next.js!"
Bulan 3: "API mulai lambat... ayo tambah caching"
Bulan 6: "Kita tidak bisa deploy admin panel tanpa merusak halaman tracking"
Bulan 9: "Semuanya terjerat satu sama lain, kita harus rewrite"
Saya sudah melihat ini terjadi di tiga perusahaan berbeda. Rewrite selalu menghabiskan biaya 3-5x lebih mahal daripada merancang arsitektur dengan benar dari awal.
Pertanyaan Kunci: Monolith atau Microservices?
Sebelum kita mendesain apapun, kita perlu menjawab pertanyaan ini. Mari saya jelaskan kedua pendekatan dengan sederhana:
Monolith = Semua dalam satu aplikasi
┌─────────────────────────────┐
│ Satu Aplikasi Besar │
│ ┌──────┐ ┌──────┐ ┌─────┐ │
│ │Track │ │Admin │ │API │ │
│ │ ing │ │Panel │ │ │ │
│ └──────┘ └──────┘ └─────┘ │
│ Satu Database │
└─────────────────────────────┘
Microservices = Beberapa aplikasi kecil, masing-masing mengerjakan satu hal
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Tracking │ │ Admin │ │ Telemetry│
│ Service │ │ Service │ │ Service │
│ (Next.js)│ │(Laravel) │ │ (NestJS) │
└────┬─────┘ └────┬─────┘ └────┬─────┘
│ │ │
┌────▼─────┐ ┌────▼─────┐ ┌────▼─────┐
│ MySQL │ │ MySQL │ │PostgreSQL│
└──────────┘ └──────────┘ └──────────┘
Keputusan Senior: Mana yang Harus Kita Pilih?
Inilah yang membedakan pemikiran junior dan senior:
Pemikiran junior: "Microservices itu modern dan keren, ayo pakai!"
Pemikiran senior: "Apa kebutuhan aktual kita? Seberapa besar tim? Berapa timeline deployment?"
Untuk sistem fleet management kita, saya memilih pendekatan hybrid — dan inilah alasannya:
| Faktor | Situasi Kita | Keputusan |
|---|---|---|
| Ukuran tim | 4-6 developer | Terlalu kecil untuk full microservices |
| Domain | Sangat berbeda (real-time tracking vs business admin) | Layanan terpisah masuk akal |
| Performa | Telemetri butuh throughput tinggi | Layanan khusus diperlukan |
| Time to market | 3-4 bulan untuk MVP | Tidak bisa membangun 10 microservices |
Arsitektur kita: 3 layanan, bukan 30.
Arsitektur Sistem Kita
Berikut arsitektur yang akan kita bangun sepanjang seri ini:
┌─────────────────────┐
│ Pengguna/Operator │
└──────────┬──────────┘
│
┌──────────▼──────────┐
│ Next.js Frontend │
│ (Aplikasi Dashboard)│
│ - Peta Armada │
│ - Laporan │
│ - Manajemen Driver│
└──────────┬──────────┘
│ HTTPS
┌──────────▼──────────┐
│ Nginx Reverse │
│ Proxy │
└──────────┬──────────┘
│
┌────────────────┼────────────────┐
│ │ │
┌─────────▼────────┐ ┌────▼─────────┐ ┌────▼──────────┐
│ NestJS API │ │ Laravel API │ │ NestJS │
│ (Backend Utama) │ │ (Admin) │ │ (Telemetri) │
│ │ │ │ │ │
│ - Auth │ │ - Filament │ │ - GPS Ingest │
│ - Fleet CRUD │ │ - Invoice │ │ - Monitor BBM │
│ - Perencanaan │ │ - Jadwal │ │ - Alert │
└────────┬─────────┘ └──────┬───────┘ └───────┬───────┘
│ │ │
┌────────▼─────────┐ ┌─────▼────────┐ ┌───────▼───────┐
│ MySQL │ │ MySQL │ │ PostgreSQL │
│ (Data Utama) │ │ (Data Admin) │ │ (Telemetri) │
└──────────────────┘ └──────────────┘ └───────────────┘
│
┌──────▼───────┐
│ Redis │
│ (Cache + │
│ Pub/Sub) │
└──────────────┘
Mengapa Stack Ini? (Matriks Keputusan Tech Stack)
Setiap pilihan teknologi harus punya alasan. Berikut matriks keputusan kita:
Frontend: Next.js (TypeScript)
Mengapa Next.js? Dashboard kita membutuhkan server-side rendering untuk performa loading awal (operator membukanya pertama kali di pagi hari dengan WiFi kantor yang lambat). Ekosistem React memberikan kita library peta, library chart, dan dukungan WebSocket real-time.
Backend Utama: NestJS (TypeScript)
Mengapa NestJS? Express.js cukup untuk API kecil, tapi untuk aplikasi enterprise dengan 50+ endpoint, Anda butuh struktur. NestJS memberikan kita modules, dependency injection, dan decorators — pola-pola yang menjaga kode tetap terorganisir saat tim bertumbuh.
Layanan Admin: Laravel (PHP)
Mengapa Laravel bersamaan dengan NestJS? Ini mungkin tampak aneh — mengapa pakai dua bahasa backend? Jawabannya pragmatis: Laravel + Filament memberikan kita admin panel siap produksi dalam hitungan hari, bukan minggu. Developer senior memilih alat yang tepat untuk setiap pekerjaan, bukan satu alat untuk semua.
Database: PostgreSQL + MySQL + Redis
| Database | Digunakan Untuk | Mengapa |
|---|---|---|
| PostgreSQL | Telemetri GPS, data sensor | Ekstensi PostGIS untuk query geospasial |
| MySQL | User, driver, invoice, jadwal | Bagus untuk data bisnis transaksional |
| Redis | Caching, real-time pub/sub, sesi | Pembacaan mikro-detik, sempurna untuk "di mana truk X sekarang?" |
Pengumpulan Kebutuhan: Skill Senior
Kebanyakan tutorial langsung ke npx create-next-app. Tapi di perusahaan nyata, Anda menghabiskan 1-2 minggu pertama memahami apa yang Anda bangun.
Pertanyaan yang Saya Ajukan Sebelum Menulis Kode
- Siapa penggunanya? — Dispatcher, manajer armada, pengemudi, akuntan
- Apa alur kritisnya? — Tracking real-time tidak boleh pernah down
- Berapa skalanya? — 200 truk, 50 operator bersamaan, 1000+ GPS ping/menit
- Apa persyaratan compliance? — Pengiriman BBM harus punya audit trail
- Apa lingkungan deployment? — VPS di data center lokal, bukan AWS
SDLC: Bagaimana Kita Membangun Ini
Kita akan mengikuti pendekatan Agile yang disederhanakan:
| Sprint | Durasi | Deliverable | Bagian Seri |
|---|---|---|---|
| Sprint 1 | Minggu 1-2 | Arsitektur + Shell Frontend | Part 1-2 |
| Sprint 2 | Minggu 3-4 | API Utama + Admin panel | Part 3-4 |
| Sprint 3 | Minggu 5-6 | Database + Data layer | Part 5 |
| Sprint 4 | Minggu 7-8 | Kualitas kode + Refactoring | Part 6 |
| Sprint 5 | Minggu 9-10 | Split Microservices + Scaling | Part 7 |
| Sprint 6 | Minggu 11-12 | Security + CI/CD + Deploy | Part 8 |
Kesalahan Umum yang Harus Dihindari
Kesalahan 1: Microservices Prematur
Jangan mulai dengan 15 microservices. Mulai dengan 2-3 layanan dengan batasan yang jelas. Anda selalu bisa memecah kemudian — tapi menggabungkan microservices kembali itu menyakitkan.
Kesalahan 2: Memilih Teknologi untuk CV
Jangan pakai Kubernetes, Kafka, dan GraphQL hanya karena terlihat bagus di CV. Pilih teknologi yang menyelesaikan masalah nyata Anda.
Kesalahan 3: Tidak Ada Architecture Decision Records
Lakukan dokumentasi mengapa Anda memilih setiap teknologi. Enam bulan dari sekarang, ketika anggota tim baru bertanya "mengapa kita pakai dua framework backend berbeda?", Anda ingin jawaban tertulis.
Selanjutnya
Di Part 2, kita akan membangun frontend Next.js — dashboard tracking armada real-time dengan tampilan peta, kartu status kendaraan, dan layout responsif.
Ini adalah Part 1 dari seri Fleet Management System. Ikuti perjalanan kita membangun aplikasi enterprise production-grade dari nol, mencakup setiap aspek pengembangan full-stack senior.
