Inertia.js v3: Pengalaman SPA Tanpa Kompleksitas API Berlebih

Ada aplikasi yang memang membutuhkan REST atau GraphQL API publik. Ada juga dashboard internal yang hanya dipakai lewat satu web app, tetapi sejak hari pertama sudah dibebani dua proyek terpisah: backend API dan frontend SPA. Akibatnya, tim harus memikirkan kontrak endpoint, autentikasi ganda, transformasi error, dan deployment terpisah sebelum pengguna pertama menyelesaikan satu pekerjaan pun.

Inertia mengambil jalan tengah. Routing dan controller tetap berada di server, sementara React mengurus tampilan dan interaksi di browser. Perpindahan halaman terasa seperti SPA, tetapi data halaman tetap dikirim dari controller yang sudah memahami user, policy, dan aturan bisnis.

Seperti apa alurnya dalam pekerjaan nyata?

Saat staf membuka halaman invoice, controller mengambil invoice yang memang boleh ia lihat, menyiapkan data ringkas, lalu merender komponen React. Ketika form disimpan, validasi server mengembalikan error langsung ke form. Tidak ada kebutuhan membuat endpoint “khusus frontend” hanya untuk meniru alur yang sebenarnya sudah dimiliki aplikasi.

Photo by Luke Chesser on Unsplash

Apa yang terasa baru di v3?

• Built-in XHR client menggantikan ketergantungan default pada Axios untuk request yang berdiri sendiri.

• useHttp memberi cara yang rapi untuk request JSON yang tidak perlu memicu kunjungan halaman Inertia.

• Optimistic update dapat mengubah UI lebih dulu dan melakukan rollback otomatis jika server menolak perubahan.

• Deferred props membantu halaman tampil cepat sementara data berat dimuat lewat request berikutnya.

• Setup SSR dengan Vite menjadi lebih sederhana, dan layout props memudahkan data dibagikan ke layout persisten.

Fitur-fitur itu sebaiknya dipilih berdasarkan rasa sakit pengguna. Deferred props masuk akal untuk grafik besar yang berada di bawah fold. Optimistic update cocok untuk aksi kecil yang konsekuensinya mudah dibatalkan, seperti memberi tanda selesai. Untuk perubahan saldo atau persetujuan penting, lebih baik tunggu jawaban server dan tampilkan status yang jujur.

Kapan Inertia bukan pilihan terbaik?

1. Produk harus melayani mobile app, partner, dan banyak client yang memakai kontrak data yang sama.

2. Frontend dan backend dikembangkan serta dirilis oleh organisasi yang benar-benar terpisah.

3. Sebagian besar pengalaman harus berjalan offline dengan sinkronisasi kompleks.

4. API publik adalah produk utamanya, bukan sekadar jalur data untuk satu antarmuka web.

Tidak membuat API terpisah bukan berarti aplikasinya kurang modern. Bisa jadi itu justru keputusan arsitektur yang paling jujur terhadap kebutuhan produk.

Untuk portal pelanggan, admin panel, mini ERP, dan sistem operasional yang tumbuh sebagai satu aplikasi, Inertia v3 membuat tim bisa memakai kekuatan React tanpa membayar seluruh kompleksitas SPA tradisional. Ukurannya sederhana: jika arsitektur membuat perubahan form bisnis lebih cepat diuji dan lebih mudah dipahami, ia sedang melakukan pekerjaannya.

Untuk detail implementasi terbaru, lihat Inertia.js v3 Documentation.