Cara Merancang Arsitektur Aplikasi Web yang Mudah Dikembangkan

Dalam pengembangan aplikasi, menambahkan fitur baru sering kali bukan bagian tersulit. Tantangan sebenarnya muncul ketika sebuah aplikasi mulai berkembang, jumlah penggunanya bertambah, kebutuhan bisnis berubah, dan beberapa bagian sistem harus bekerja secara bersamaan. Tanpa perencanaan arsitektur yang tepat, perubahan kecil dapat memengaruhi banyak bagian aplikasi dan membuat proses pengembangan semakin sulit.

Arsitektur aplikasi web merupakan fondasi yang menentukan bagaimana komponen perangkat lunak saling berkomunikasi, bagaimana data dikelola, serta bagaimana setiap bagian sistem menjalankan tanggung jawabnya. Karena itu, merancang aplikasi tidak cukup hanya dengan menentukan framework atau bahasa pemrograman. Developer juga perlu memahami hubungan antara kebutuhan pengguna, proses bisnis, struktur database, keamanan, dan integrasi antarsistem.

Pendekatan tersebut menjadi salah satu pertimbangan dalam pengembangan MyFICC Church Management System, sebuah sistem pengelolaan administrasi gereja yang menggabungkan Admin Web berbasis Next.js dengan aplikasi Android berbasis Flutter. Sistem ini dikembangkan untuk mendukung pengelolaan anggota jemaat, jadwal ibadah, pengumuman, absensi menggunakan QR Code, notifikasi, serta pemantauan aktivitas melalui dashboard.

Melalui proyek ini, terdapat satu prinsip yang menjadi perhatian utama: aplikasi harus memiliki struktur yang memungkinkan pengembangan fitur baru tanpa harus terus-menerus mengubah keseluruhan sistem.

Cara Merancang Arsitektur Aplikasi Web Berdasarkan Kebutuhan Pengguna dan Proses Bisnis

Kesalahan yang sering terjadi ketika memulai pengembangan aplikasi adalah terlalu cepat menentukan teknologi sebelum memahami masalah yang ingin diselesaikan. Padahal, keputusan arsitektur seharusnya berangkat dari kebutuhan sistem, bukan sekadar mengikuti framework yang sedang populer.

Dalam MyFICC, kebutuhan utamanya bukan hanya menyediakan website administrasi. Sistem harus mampu menghubungkan aktivitas pengelolaan gereja melalui dua platform berbeda, yaitu website untuk kebutuhan administrasi dan Android untuk kebutuhan akses pengguna melalui perangkat mobile.

Kondisi tersebut menghasilkan beberapa kebutuhan teknis yang perlu dipertimbangkan sejak awal:

Manajemen pengguna: Sistem perlu mengelola identitas, profil, serta peran pengguna.
Pengelolaan informasi: Pengumuman dan jadwal ibadah harus dapat dikelola melalui sistem administrasi.
Pencatatan kehadiran: Sistem membutuhkan mekanisme absensi yang memanfaatkan QR Code.
Komunikasi: Pengguna perlu menerima pemberitahuan mengenai informasi atau aktivitas tertentu.
Pemantauan operasional: Administrator membutuhkan dashboard untuk melihat informasi yang relevan dengan aktivitas sistem.

Dari kebutuhan tersebut, saya memisahkan tanggung jawab aplikasi berdasarkan fungsi dan platform. Admin Web berfokus pada pengelolaan data dan operasional, sedangkan aplikasi Android menyediakan akses bagi pengguna melalui perangkat mobile.

Pemisahan ini bukan berarti kedua aplikasi berjalan sebagai sistem yang tidak berhubungan. Keduanya tetap membutuhkan sumber data dan aturan bisnis yang konsisten.

Sebelum menentukan struktur teknis, developer sebaiknya membuat pemetaan sederhana antara kebutuhan bisnis, fitur, data yang digunakan, dan pihak yang memiliki akses. Misalnya, fitur pengelolaan jadwal memiliki kebutuhan data jadwal, hak akses administrator, serta mekanisme agar perubahan informasi dapat diketahui pengguna Android.

Dengan pemetaan tersebut, setiap fitur memiliki batas tanggung jawab yang lebih jelas. Ketika kemudian muncul kebutuhan baru, seperti penambahan kategori kegiatan atau laporan kehadiran, developer dapat mengidentifikasi komponen yang perlu diperbarui tanpa langsung mengubah seluruh aplikasi.

Prinsip ini sejalan dengan separation of concerns, yaitu membagi sistem menjadi bagian-bagian berdasarkan tanggung jawabnya. Pemisahan yang baik membantu mengurangi ketergantungan antarkomponen dan membuat proses pemeliharaan lebih terarah.

Mengapa Arsitektur Next.js dan Flutter Membutuhkan REST API sebagai Penghubung Sistem?

Salah satu keputusan penting dalam pengembangan MyFICC adalah menggunakan Next.js untuk Admin Web dan Flutter untuk aplikasi Android. Keduanya memiliki lingkungan pengembangan, mekanisme antarmuka, serta kebutuhan interaksi yang berbeda.

Jika masing-masing aplikasi mengelola data secara terpisah, risiko inkonsistensi informasi akan semakin besar. Sebagai contoh, perubahan jadwal ibadah melalui website seharusnya dapat ditampilkan pada aplikasi Android tanpa administrator harus memasukkan informasi yang sama dua kali.

Untuk mengatasi kebutuhan tersebut, MyFICC menggunakan REST API sebagai lapisan komunikasi antara aplikasi dan backend.

Secara sederhana, arsitekturnya dapat digambarkan sebagai berikut:

Admin Web (Next.js) dan Android (Flutter) → REST API (Next.js API Routes) → Prisma ORM → PostgreSQL.

Dalam pendekatan ini, kedua platform tidak perlu mengetahui bagaimana database disusun atau bagaimana backend menjalankan proses internalnya. Aplikasi cukup mengirimkan permintaan melalui endpoint yang telah ditentukan dan menerima respons dalam format yang disepakati.

Contohnya, ketika administrator membuat pengumuman melalui Admin Web, alur prosesnya adalah:

Administrator mengisi formulir pengumuman.
Frontend mengirimkan data ke endpoint REST API.
Backend memvalidasi permintaan dan memeriksa hak akses pengguna.
Prisma ORM menjalankan operasi terhadap PostgreSQL.
Backend mengembalikan respons kepada frontend.
Informasi pengumuman dapat diakses oleh aplikasi Android melalui endpoint yang sama.

Keuntungan utama pendekatan ini adalah independensi platform. Backend tidak harus mengetahui apakah permintaan berasal dari browser, aplikasi Android, atau nantinya aplikasi lain.

Microsoft Azure Architecture Center menjelaskan bahwa RESTful API dapat menciptakan antarmuka yang bersifat loosely coupled, sehingga klien dan layanan dapat berkembang secara lebih independen. Standar HTTP, format pertukaran data, serta kontrak API yang jelas menjadi bagian penting dari pendekatan tersebut.

Dokumentasi : https://learn.microsoft.com/en-us/azure/architecture/best-practices/api-design

Namun, penggunaan REST API saja belum cukup. Developer juga perlu memperhatikan konsistensi penamaan endpoint, struktur respons, validasi request, kode status HTTP, pagination, serta penanganan error.

Sebagai contoh, endpoint untuk pengelolaan jadwal sebaiknya memiliki pola yang konsisten, seperti GET untuk mengambil data, POST untuk membuat data, PUT atau PATCH untuk memperbarui, dan DELETE untuk menghapus data.

Kontrak API yang konsisten akan mengurangi ketergantungan frontend terhadap implementasi internal backend. Ketika suatu saat struktur database berubah, frontend tidak harus ikut berubah selama kontrak API tetap kompatibel.

Inilah alasan REST API menjadi salah satu fondasi penting ketika aplikasi web dan mobile harus berkembang dalam satu ekosistem.

Cara Menyusun Database PostgreSQL dan Prisma ORM agar Mudah Dikembangkan

Database bukan hanya tempat menyimpan informasi. Struktur database menentukan bagaimana data saling berhubungan, bagaimana integritas informasi dipertahankan, dan seberapa mudah sistem menerima kebutuhan baru.

Dalam MyFICC, PostgreSQL digunakan sebagai sistem manajemen basis data, sedangkan Prisma ORM menjadi penghubung antara aplikasi backend dengan database.

Pemilihan PostgreSQL didasarkan pada kebutuhan pengelolaan data yang memiliki hubungan cukup beragam. Sistem administrasi gereja, misalnya, memiliki hubungan antara pengguna, profil anggota, peran, jadwal, pengumuman, absensi, dan notifikasi.

Jika seluruh informasi tersebut disimpan tanpa struktur yang jelas, perubahan pada satu jenis data berpotensi memengaruhi banyak proses lainnya.

Karena itu, struktur data perlu dirancang berdasarkan entitas dan hubungan antardata. Beberapa entitas yang relevan dalam MyFICC meliputi:

Users dan profiles untuk identitas serta informasi pengguna.
Roles dan permissions untuk pengelolaan hak akses.
Announcements untuk informasi dan pengumuman.
Schedules untuk jadwal kegiatan.
Attendances untuk pencatatan kehadiran.
Notifications dan devices untuk kebutuhan pemberitahuan.
Audit logs untuk pencatatan aktivitas sistem.

Pemisahan entitas tersebut membantu menjaga tanggung jawab setiap tabel. Sebagai contoh, informasi identitas pengguna tidak perlu dicampur dengan seluruh riwayat kehadirannya.

Hubungan antartabel kemudian dikelola menggunakan primary key, foreign key, serta aturan relasi yang sesuai. Pendekatan ini membantu menjaga integritas data dan mengurangi duplikasi informasi.

Di sisi implementasi, Prisma ORM memberikan pendekatan yang lebih terstruktur untuk mengakses database melalui model yang didefinisikan dalam schema. Developer dapat melakukan query menggunakan TypeScript dengan dukungan tipe data yang membantu mengurangi kesalahan saat pengembangan.

Salah satu manfaat pentingnya adalah perubahan struktur database dapat dikelola melalui migration. Misalnya, ketika sistem membutuhkan atribut baru pada data anggota, perubahan dapat direncanakan, diuji, dan diterapkan melalui mekanisme migrasi.

Prisma menyediakan dokumentasi mengenai schema, query, dan migration sebagai bagian dari pengelolaan siklus hidup database.

Dokumentasi: https://www.prisma.io/docs/orm

Namun, menggunakan ORM bukan berarti developer tidak perlu memahami SQL. Optimasi query, indexing, relasi, transaksi, dan konsistensi data tetap membutuhkan pemahaman terhadap karakteristik database yang digunakan.

Hal lain yang tidak kalah penting adalah menghindari desain database yang terlalu mengikuti kebutuhan tampilan. Struktur database seharusnya merepresentasikan kebutuhan data dan proses bisnis, bukan sekadar mengikuti bentuk formulir pada frontend.

Dengan begitu, ketika tampilan aplikasi berubah atau fitur baru ditambahkan, fondasi penyimpanan data tidak harus selalu dibangun ulang.

Bagaimana Menerapkan Authentication dan Role Based Access Control pada Aplikasi berbasis Web dan Aplikasi Mobile Android?

Semakin banyak fitur yang dimiliki aplikasi, semakin penting pula pengelolaan keamanan dan hak aksesnya. Tidak semua pengguna seharusnya memiliki kemampuan untuk melihat, mengubah, atau menghapus informasi yang sama.

Dalam MyFICC, kebutuhan tersebut ditangani melalui mekanisme autentikasi JWT dan otorisasi berbasis Role-Based Access Control (RBAC).

Autentikasi bertujuan memastikan identitas pengguna yang sedang mengakses sistem. Sementara itu, otorisasi menentukan tindakan apa saja yang diperbolehkan bagi pengguna tersebut.

Keduanya memiliki fungsi berbeda dan tidak boleh dianggap sebagai satu proses yang sama.

Sebagai contoh, pengguna yang berhasil login belum tentu memiliki hak untuk menghapus pengumuman atau mengubah jadwal kegiatan. Hak tersebut harus ditentukan berdasarkan peran dan permission yang dimiliki.

Secara konseptual, alur keamanannya meliputi:

Pengguna mengirimkan kredensial untuk proses login.
Backend memverifikasi kredensial menggunakan mekanisme penyimpanan password yang aman, termasuk hashing menggunakan bcrypt.
Setelah berhasil, sistem memberikan token autentikasi JWT.
Setiap permintaan ke endpoint yang dilindungi harus melewati pemeriksaan autentikasi.
Backend memeriksa permission sebelum menjalankan operasi yang diminta.

Penerapan RBAC membuat pengelolaan akses lebih fleksibel. Ketika terdapat kebutuhan peran baru, developer dapat mengatur hubungan antara role dan permission tanpa harus menulis ulang aturan akses pada setiap halaman.

Namun, pemeriksaan akses tidak boleh hanya dilakukan pada frontend. Menyembunyikan tombol atau menu berdasarkan role tidak otomatis membuat endpoint menjadi aman.

Backend tetap harus memeriksa identitas, kepemilikan data, dan hak akses pada setiap operasi yang relevan. Sebagai contoh, pengguna yang tidak memiliki izin mengelola anggota tidak boleh dapat mengubah data anggota hanya dengan memanggil endpoint secara langsung.

Hal ini berkaitan dengan risiko Broken Object Level Authorization dan Broken Function Level Authorization yang dibahas dalam OWASP API Security Top 10 2023.

OWASP menekankan bahwa kontrol akses harus diperiksa pada fungsi yang menggunakan identitas objek maupun operasi yang dijalankan melalui API.

Referensi: https://owasp.org/API-Security/

Selain autentikasi dan otorisasi, keamanan juga perlu memperhatikan masa berlaku token, penyimpanan kredensial, validasi input, pembatasan akses, pengelolaan secret, serta pencatatan aktivitas penting.

Pada aplikasi yang memiliki website dan Android, pendekatan keamanan harus konsisten di seluruh platform. Artinya, perbedaan perangkat tidak boleh menghasilkan perbedaan aturan bisnis maupun hak akses.

Strategi Mengembangkan Fitur Baru pada Aplikasi Web agar Tidak Mengganggu Sistem yang Sudah Berjalan

Arsitektur yang baik bukan hanya dinilai dari kemampuannya menjalankan fitur saat ini, tetapi juga dari seberapa mudah sistem menerima perubahan pada masa mendatang.

Dalam MyFICC, kebutuhan pengembangan tidak berhenti pada pengelolaan anggota, jadwal, pengumuman, dan absensi. Sistem juga membutuhkan komunikasi kepada pengguna melalui push notification.

Untuk kebutuhan tersebut, Firebase Cloud Messaging (FCM) digunakan sebagai layanan pengiriman notifikasi ke perangkat Android.

Integrasi ini memperlihatkan pentingnya memisahkan fungsi utama aplikasi dari layanan eksternal. Backend bertanggung jawab menentukan kapan notifikasi perlu dikirim dan kepada siapa, sedangkan FCM menangani mekanisme pengiriman pesan ke perangkat penerima.

Dengan pemisahan tersebut, apabila suatu saat mekanisme notifikasi perlu diperluas, perubahan dapat difokuskan pada komponen integrasi tanpa harus membangun ulang seluruh modul administrasi.

Dokumentasi resmi Firebase menjelaskan bahwa FCM melibatkan aplikasi klien, lingkungan server tepercaya, serta layanan pengiriman pesan. Server aplikasi bertanggung jawab membangun dan mengirimkan permintaan pesan melalui Firebase Admin SDK atau protokol HTTP yang disediakan.

Referensi: https://firebase.google.com/docs/cloud-messaging

Selain integrasi layanan eksternal, pemeliharaan aplikasi juga membutuhkan pengelolaan struktur kode yang konsisten.

Pada sisi Next.js, pemisahan komponen antarmuka, pengelolaan state, validasi formulir, serta komunikasi API membantu menjaga tanggung jawab setiap bagian aplikasi. Penggunaan React Query juga membantu pengelolaan server state dan proses pengambilan data pada frontend.

Next.js App Router menyediakan pendekatan Server Components dan Client Components. Server Components dapat digunakan untuk pengambilan data serta menjaga informasi sensitif tetap berada di lingkungan server, sedangkan Client Components digunakan ketika diperlukan interaksi pengguna dan browser API.

Dokumentasi: https://nextjs.org/docs/app/getting-started/server-and-client-components

Pada sisi Flutter, prinsip yang sama dapat diterapkan dengan memisahkan antarmuka, pengelolaan state, dan akses data. Dokumentasi resmi Flutter merekomendasikan pemisahan UI layer dan data layer, termasuk penggunaan View, ViewModel, Repository, dan Service sesuai kebutuhan kompleksitas aplikasi.

Referensi: https://docs.flutter.dev/app-architecture/guide

Pemisahan tersebut membuat perubahan pada satu bagian tidak selalu mengharuskan perubahan pada bagian lainnya. Misalnya, perubahan tampilan absensi tidak seharusnya mengharuskan developer mengubah keseluruhan mekanisme komunikasi API.

Hal lain yang perlu diperhatikan adalah pengujian sebelum perubahan diterapkan ke lingkungan produksi. Setiap penambahan fitur sebaiknya melewati validasi fungsional, pengujian integrasi API, pemeriksaan hak akses, dan pengujian regresi terhadap fitur yang sudah berjalan.

Dokumentasi teknis, pengelolaan migration, konsistensi kontrak API, serta pencatatan error juga menjadi bagian dari pemeliharaan jangka panjang.

Pada akhirnya, arsitektur yang mudah dikembangkan bukan berarti harus menggunakan sebanyak mungkin teknologi atau membagi aplikasi menjadi banyak layanan. Arsitektur yang baik justru mampu menjaga keseimbangan antara kebutuhan saat ini, kompleksitas implementasi, dan kemungkinan perubahan di masa depan.

Kesimpulan

Merancang arsitektur aplikasi web membutuhkan pemahaman yang menyeluruh terhadap kebutuhan pengguna, proses bisnis, pengelolaan data, komunikasi antarsistem, dan keamanan.

Melalui MyFICC Church Management System, pendekatan tersebut diterapkan dengan menggabungkan Next.js untuk Admin Web, Flutter untuk aplikasi Android, REST API sebagai lapisan komunikasi, PostgreSQL sebagai database, Prisma ORM untuk pengelolaan data, serta JWT dan RBAC untuk keamanan akses.

Setiap teknologi memiliki tanggung jawab yang berbeda, tetapi seluruhnya harus bekerja berdasarkan aturan dan kontrak yang konsisten.

Pelajaran terpentingnya adalah arsitektur aplikasi tidak dirancang hanya untuk membuat fitur dapat berjalan, tetapi untuk memastikan fitur tersebut dapat terus dikembangkan, diperbaiki, dan dipelihara tanpa menciptakan kompleksitas yang tidak perlu.

Karena pada akhirnya, kualitas sebuah aplikasi tidak hanya terlihat dari apa yang dapat dilakukan hari ini, tetapi juga dari seberapa siap sistem tersebut menghadapi kebutuhan berikutnya.