Monolit Inertia vs Decoupled SPA: Evaluasi Biaya, Skala & Kompleksitas

Memilih antara monolit modern berbasis Inertia.js dan arsitektur decoupled Single Page Application (SPA) berbasis REST atau GraphQL bukan sekadar preferensi sintaks, melainkan keputusan yang berdampak langsung pada Total Cost of Ownership (TCO), kecepatan rilis tim, dan batas skalabilitas sistem. Kedua pendekatan menyelesaikan masalah UI reaktif, namun mendistribusikan kompleksitas pada lapisan yang berbeda.

1. Beban Infrastruktur dan Biaya Operasional

Perbedaan paling mendasar terlihat pada topologi deployment dan alokasi sumber daya komputasi.

Monolit Inertia.js

Inertia mempertahankan arsitektur monolit klasik. Backend (seperti Laravel, Ruby on Rails, atau Django) bertindak sebagai pengendali rute tunggal. Frontend (Vue, React, atau Svelte) dikompilasi menjadi aset statis murni yang dilayani langsung oleh web server (Nginx, Caddy) atau Object Storage.

• Topologi Deployment: Single-host atau auto-scaling group tunggal. Tidak memerlukan layer perantara.
• Kebutuhan SSR: Jika membutuhkan Server-Side Rendering (SSR) untuk SEO, proses Node.js internal kecil dijalankan di localhost backend untuk merender string HTML awal. Beban operasional tetap berada dalam satu boundary infrastruktur.
• State & Otentikasi: Memanfaatkan sesi berbasis cookie HTTP-only standar. Tidak membutuhkan otentikasi token terdistribusi atau microservice auth server.

Decoupled SPA

Arsitektur decoupled memisahkan repository, pipeline CI/CD, dan hosting frontend dari API backend.

• Topologi Deployment: Terdistribusi. Frontend di-host pada penyedia edge (Vercel, Netlify, Cloudflare Pages, atau AWS S3 + CloudFront). Backend API beroperasi di kluster compute terpisah (Kubernetes, AWS ECS, atau VM pool).
• Overhead SSR / Node Pool: Framework seperti Next.js atau Nuxt dalam mode SSR memerlukan kluster server Node.js aktif untuk merender halaman sebelum mengambil data dari API backend. Ini menciptakan network hop ganda: Pengguna → SSR Node → Internal API → Database.
• Biaya Jaringan: Egress cost meningkat akibat transfer data JSON mentah bolak-balik antara kluster frontend SSR dan backend API jika tidak berada dalam private VPC yang sama.

2. Maintainability: Eliminasi API Layer vs Boundary Decoupling

Kompleksitas pemeliharaan kode berakar dari seberapa banyak abstraksi yang harus dikelola pengembang untuk menyajikan data ke layar.

Inertia: Tanpa Serializer dan API Versioning

Inertia menghilangkan kebutuhan membuat REST controller, API resources, endpoint routing terpisah, dan client-side state fetching layer. Controller backend langsung meneruskan data ke props komponen frontend.

// Laravel Controller dengan Inertia
public function edit(Order $order)
{
    return inertia('Orders/Edit', [
        'order' => [
            'id' => $order->id,
            'total' => $order->total_amount,
            'status' => $order->status,
        ],
        'payment_methods' => PaymentMethod::active()->get(['id', 'name']),
    ]);
}

Perubahan struktur data hanya dilakukan di satu tempat: controller backend. Komponen frontend langsung mengonsumsinya via props tanpa layer sinkronisasi seperti TanStack Query atau Axios interceptors. Routing terpusat di backend, mengeliminasi kebutuhan versioning API untuk UI internal web.

Decoupled SPA: Kontrak DTO dan Sinkronisasi State

Pendekatan terpisah membutuhkan pendefinisian kontrak API formal yang harus dipatuhi kedua belah pihak.

// Backend: API Resource / DTO
class OrderResource extends JsonResource
{
    public function toArray($request)
    {
        return [
            'id' => $this->id,
            'total' => $this->total_amount,
            'status' => $this->status,
        ];
    }
}

// Frontend: TypeScript Interface & Fetching
interface Order {
    id: number;
    total: number;
    status: string;
}

export function useOrder(orderId: number) {
    return useQuery<Order>({
        queryKey: ['order', orderId],
        queryFn: () => api.get(`/api/v1/orders/${orderId}`).then(res => res.data),
    });
}

Pendekatan ini memicu DTO duplication: struktur data ditulis ulang di backend schema dan frontend types. Jika API berubah, frontend berisiko mengalami runtime error kecuali tim mengimplementasikan automated contract testing atau code generation via OpenAPI/tRPC.

Kelebihannya, boundary yang ketat memungkinkan tim frontend dan backend bekerja secara independen berdasarkan mock API selama kontrak data tidak berubah.

3. Karakteristik Skala dan Bottleneck Kinerja

Arsitektur menentukan komponen mana yang lebih dahulu jenuh saat traffic meningkat tajam.

Bottleneck Monolit Inertia

• Stateful Session I/O: Inertia bergantung pada server-side session. Skalabilitas horizontal monolit mensyaratkan session store terpusat (umumnya Redis). Ketika koneksi concurrent melonjak, Redis session store dan pooling koneksi database menjadi titik jenuh utama.
• JSON Serialization Overhead: Setiap navigasi Inertia menghasilkan payload JSON props yang diserialisasi langsung oleh worker runtime (misal PHP-FPM worker atau Ruby thread), memakan siklus CPU yang signifikan dibanding melayani file statis dari CDN edge.
• Caching Terbatas: Karena request Inertia membawa header X-Inertia: true dan data sering kali terikat sesi pengguna terotentikasi, caching full-page di level CDN edge jauh lebih sulit diterapkan dibanding aplikasi JAMstack murni.

Skalabilitas Decoupled SPA

• Stateless API: Otentikasi menggunakan token stateless (seperti JWT atau short-lived bearer tokens) mengurangi beban I/O session store backend.
• Edge Caching Aset Statis: Seluruh aplikasi shell (HTML statis, JS chunks, CSS) didistribusikan 100% dari CDN edge secara global dengan zero computation backend. Worker backend hanya menerima request data API mentah.
• Independent Horizontal Scaling: Kluster API dapat di-scale berdasarkan endpoint beban komputasi tinggi tanpa perlu memperbanyak container yang melayani aset UI.

4. Matriks Evaluasi: Kapan Bertahan vs Migrasi

Keputusan arsitektur harus didasarkan pada batasan organisasi, jenis produk, dan profil traffic, bukan tren teknologi.

Kriteria Bertahan dengan Monolit Inertia

• Aplikasi berfokus pada pengalaman authenticated (portal pengguna, CRM, back-office, ERP, B2B SaaS).
• Tim engineering terdiri dari pengembang generalist atau full-stack yang menguasai ekosistem backend monolit pilihan.
• Tidak ada kebutuhan mendesak untuk merilis API publik atau aplikasi mobile native dengan antarmuka yang sama dalam jangka pendek.
• Fokus utama adalah time-to-market dan minimnya biaya pemeliharaan infrastruktur.

Kriteria Rasional Transisi ke Decoupled SPA

• Perusahaan mengembangkan aplikasi mobile (Flutter/React Native/Swift) yang membutuhkan 90% endpoint API yang identik dengan platform web.
• Skala organisasi menuntut pemisahan domain kerja: tim frontend harus dapat mendeploy perubahan antarmuka tanpa menyentuh deployment backend monolith.
• Aplikasi memiliki volume traffic anonim masif yang membutuhkan rendering di edge global untuk meminimalkan Time to First Byte (TTFB) dan menjaga SEO publik.