Web Application Architecture

Kamu baru saja menyelesaikan fitur baru untuk aplikasi internal perusahaan. Semua pengujian di laptopmu berjalan lancar. Sekarang saatnya membagikannya ke tim lain. Kamu copy folder project ke server, install dependensi, jalankan aplikasi, dan minta rekan kerja mencoba dari browser mereka. Besoknya, ada tiga orang yang melaporkan error. Ternyata mereka pakai versi browser berbeda. Salah satu dari mereka bahkan membuka aplikasi dari tablet.

Situasi seperti ini akrab bagi siapa pun yang pernah membangun aplikasi web sendiri tanpa arsitektur yang jelas. Aplikasi berjalan, tetapi setiap kali ada perubahan, kamu harus turun tangan langsung. Setiap pengguna baru berarti potensi masalah baru. Yang paling melelahkan: tidak ada satu tempat pun yang bisa kamu tunjuk sebagai pusat kendali aplikasi.

Masalah yang Muncul Saat Aplikasi Mulai Dipakai Banyak Orang

Ketika aplikasi hanya dipakai sendiri atau oleh dua tiga orang di jaringan lokal, arsitektur terasa tidak penting. Yang penting aplikasi berjalan. Tapi begitu pengguna mulai banyak—apalagi jika mereka mengakses dari perangkat dan lokasi berbeda—kamu mulai merasakan tekanan.

Pertama, setiap pengguna harus punya cara yang sama untuk mengakses aplikasi. Kedua, ketika ada bug atau pembaruan, kamu tidak bisa mendatangi satu per satu komputer pengguna. Ketiga, data yang disimpan di laptop masing-masing pengguna akan kacau—siapa punya versi data terbaru? Keempat, aplikasi harus tetap aman meskipun diakses dari jaringan publik.

Semua masalah ini punya satu akar: tidak ada pemisahan yang jelas antara tampilan, logika, dan data. Ketiganya tercampur di satu tempat, sehingga setiap perubahan berisiko merusak bagian lain.

Tiga Lapisan yang Memisahkan Tugas

Arsitektur web application yang umum memecah aplikasi menjadi tiga lapisan. Masing-masing punya tanggung jawab yang berbeda, dan komunikasi antar lapisan terjadi melalui protokol yang sudah standar.

Presentation Tier adalah lapisan yang langsung dilihat pengguna. Di sinilah browser dan web client bekerja. Tugasnya hanya satu: menampilkan antarmuka dan menangani interaksi pengguna. Lapisan ini tipis—ia tidak menyimpan logika bisnis atau data. Ia hanya mengirim permintaan HTTP dan menunggu jawaban.

Application Tier adalah lapisan paling dominan dalam arsitektur ini. Di sinilah web server dan application server bekerja bersama. Web server menerima permintaan dari browser, lalu meneruskannya ke application server yang menjalankan business logic. Lapisan ini juga mengelola session—siapa pengguna yang sedang login, apa yang sudah mereka lakukan, dan data apa yang perlu diingat selama kunjungan.

Data Tier adalah tempat penyimpanan. Database menyimpan data terstruktur, sementara file storage menampung file seperti gambar atau dokumen. Lapisan ini tidak peduli bagaimana data ditampilkan atau diproses. Ia hanya bertugas menyimpan dan mengambil data saat diminta.

Alur Kerja dari Browser ke Database

Ketika seseorang mengetik alamat website di browser, rangkaian kerja dimulai. Browser mengirim HTTP request ke web server. Web server—yang bisa berupa Apache, Nginx, atau perangkat lunak serupa—menerima permintaan ini dan menentukan ke mana harus meneruskannya.

Permintaan yang membutuhkan logika bisnis dikirim ke application server. Di sinilah validasi dilakukan: apakah pengguna punya hak akses? Apakah data yang dikirim lengkap? Apakah session masih valid? Setelah semua diperiksa, application server mungkin perlu membaca atau menulis data ke database.

Database mengembalikan hasil yang diminta. Application server mengambil hasil ini, membungkusnya dalam halaman HTML bersama CSS dan JavaScript, lalu mengirimkannya kembali ke browser melalui web server. Browser kemudian merender halaman tersebut untuk ditampilkan ke pengguna.

Inilah yang disebut request-response cycle. Setiap interaksi pengguna—klik tombol, kirim formulir, buka halaman baru—mengulangi siklus ini. Karena HTTP adalah protokol stateless, setiap permintaan berdiri sendiri. Session management-lah yang membuat server bisa mengenali bahwa beberapa permintaan datang dari pengguna yang sama.

Kapan Pola Ini Cocok Dipakai

Arsitektur tiga lapis ini paling cocok untuk aplikasi yang mengutamakan konten dan logika di sisi server. Situs e-commerce tradisional, sistem manajemen konten, intranet perusahaan, dan blog adalah contoh yang pas.

Keunggulan utamanya adalah kemudahan pengelolaan. Karena logika bisnis terpusat di application tier, pembaruan cukup dilakukan di satu tempat. Semua pengguna langsung mendapatkan versi terbaru saat mereka memuat ulang halaman. Tidak perlu menginstal apa pun di sisi klien.

Arsitektur ini juga unggul untuk situs yang mengandalkan SEO. Karena halaman di-render di server, mesin pencari bisa membaca konten tanpa perlu menjalankan JavaScript. Ini penting untuk toko online atau portal berita yang ingin muncul di hasil pencarian.

Trade-off dan Risiko yang Perlu Diperhitungkan

Tidak ada arsitektur yang sempurna. Pola ini punya kelemahan yang perlu kamu sadari sebelum memutuskan menggunakannya.

Beban server bertambah seiring bertambahnya pengguna. Setiap kali pengguna berpindah halaman, server harus memproses ulang permintaan, menjalankan logika, dan merender halaman. Jika pengguna banyak dalam waktu bersamaan, server bisa kewalahan.

Manajemen session juga bisa menjadi rumit. Karena HTTP stateless, server perlu menyimpan informasi session entah di memori atau di database. Jika kamu menambah server baru di belakang load balancer, session yang tersimpan di server lama tidak otomatis tersedia di server baru. Inilah mengapa session affinity kadang diperlukan—atau solusi seperti menyimpan session di Redis yang bisa diakses semua server.

Pengalaman pengguna juga terasa kurang responsif dibanding aplikasi modern. Setiap interaksi yang membutuhkan data baru akan memicu reload halaman penuh. Ini terasa lambat, terutama di koneksi yang tidak stabil. Aplikasi juga tidak bisa berfungsi offline karena semua logika ada di server.

Implikasi Praktis untuk Tim Engineering

Jika tim kamu memilih arsitektur ini, ada beberapa keputusan yang perlu diambil sejak awal.

Pertama, pastikan application tier bisa berjalan tanpa state. Semakin sedikit data session yang disimpan di memori server, semakin mudah aplikasi diskalakan secara horizontal. Kamu cukup menambah server di belakang load balancer tanpa khawatir session hilang.

Kedua, siapkan strategi caching. Database hampir selalu menjadi bottleneck dalam arsitektur ini. Cache seperti Redis di depan database bisa mengurangi beban baca yang berulang. Cache juga bisa dipakai untuk menyimpan halaman yang jarang berubah, sehingga web server bisa melayani permintaan tanpa perlu memanggil application server.

Ketiga, jangan abaikan keamanan. Karena semua logika berjalan di server, server-side validation adalah keharusan. Lindungi aplikasi dari SQL injection, cross-site scripting (XSS), dan cross-site request forgery (CSRF). Gunakan HTTPS untuk semua koneksi. Pertimbangkan Web Application Firewall (WAF) dan rate limiting untuk melindungi dari serangan.

Keempat, pikirkan strategi deployment. Karena aplikasi adalah satu kesatuan yang di-deploy ke server, proses rilis harus terotomatisasi. Gunakan pipeline CI/CD untuk membangun, menguji, dan mengirim versi baru. Pastikan ada mekanisme rollback jika versi baru bermasalah.

Arsitektur web application tiga lapis bukanlah yang paling modern atau paling canggih. Tapi ia adalah fondasi yang terbukti andal untuk banyak jenis aplikasi. Selama kamu memahami batasannya—server load, state management, dan interaktivitas—pola ini bisa melayani kebutuhan dengan baik. Yang terpenting, ia memberi pemisahan tanggung jawab yang jelas, sehingga tim bisa bekerja pada lapisan yang berbeda tanpa saling menginjak.