Apa itu Arsitektur Aplikasi Web? Menghancurkan Aplikasi Web

Dunia telah berpindah ke internet, dan aplikasi web telah menjadi tempat kerja dan toko komersial baru. Untuk mengakomodasi berbagai tujuan yang dilayani oleh aplikasi web modern, masing-masing aplikasi perlu dirancang untuk kinerja tinggi dan kemampuan penyesuaian.

Arsitektur aplikasi web memecahkan masalah ini.
Ingin mempelajari lebih lanjut tentang arsitektur aplikasi web? Anda telah datang ke tempat yang tepat Klik untuk Tweet
Arsitektur aplikasi web mendefinisikan bagaimana berbagai komponen aplikasi berbasis web terstruktur. Arsitektur ini sangat spesifik untuk sifat dan tujuan aplikasi web. Memilih arsitektur yang salah untuk aplikasi web Anda dapat mendatangkan malapetaka pada bisnis Anda.

Dalam panduan ini, kami akan menguraikan konsep arsitektur aplikasi web dan memahami bagaimana hal itu memengaruhi pengalaman pengguna akhir aplikasi Anda. Menjelang akhir, kami juga akan melihat beberapa praktik terbaik yang dapat Anda terapkan untuk mendapatkan hasil maksimal dari aplikasi web Anda.

Apa itu Arsitektur Aplikasi Web?

Untuk memulai diskusi, mari kita mulai dengan definisi arsitektur aplikasi web.

Dengan kata sederhana, arsitektur aplikasi web adalah garis besar tentang bagaimana berbagai komponen aplikasi web Anda berinteraksi satu sama lain.

Ini bisa sesederhana mendefinisikan hubungan antara klien dan server. Ini juga bisa serumit mendefinisikan hubungan timbal balik antara segerombolan server backend kemas, penyeimbang beban, gateway API, dan frontend satu halaman yang menghadap pengguna.

Meskipun demikian, ini jarang tentang memilih bahasa pemrograman di mana Anda akan menulis kode Anda.

Bagaimana Anda mendesain aplikasi web Anda memainkan peran kunci dalam kegunaannya dan pengoptimalan biaya Anda. Inilah contoh arsitektur aplikasi web di atas kertas:

Mengapa Arsitektur Aplikasi Web Penting?

Arsitektur aplikasi web, tanpa diragukan lagi, adalah salah satu bagian terpenting dari aplikasi web Anda. Jika Anda memilih untuk mengembangkan aplikasi web Anda dengan mempertimbangkan arsitektur tertentu, Anda pasti akan menerima banyak manfaat dalam hal memelihara dan mengembangkan aplikasi Anda.

Namun, memilih arsitektur yang tepat memperkuat manfaat ini lebih lanjut.

Berikut adalah beberapa alasan utama Anda harus serius mempertimbangkan untuk mengadopsi arsitektur aplikasi web.

Beradaptasi Dengan Kebutuhan Bisnis dengan Mudah

Aplikasi Anda adalah pintu gerbang utama ke bisnis Anda, dan kebutuhan bisnis berkembang seiring dengan perubahan pasar. Untuk mengikutinya, Anda ingin aplikasi Anda cukup fleksibel untuk beradaptasi dengan perubahan kebutuhan bisnis Anda. Dan jika Anda membuat aplikasi tanpa mempertimbangkan fleksibilitas bawaan, Anda pasti akan menghabiskan lebih banyak waktu dan upaya untuk membuat penyesuaian kecil di aplikasi Anda nantinya.

Arsitektur aplikasi web yang tepat sudah memperhitungkan beberapa perubahan yang mungkin dibutuhkan bisnis Anda di masa mendatang. Misalnya, jika Anda tahu Anda sedang membangun aplikasi e-niaga yang akan menskalakan dan melayani berbagai layanan ke sejumlah besar pelanggan suatu hari nanti, memilih arsitektur layanan mikro daripada yang monolitik akan memberi Anda lebih banyak fleksibilitas.

Di sisi lain, jika Anda membuat aplikasi internal untuk perusahaan Anda dengan hanya satu atau dua persyaratan tetap, Anda dapat memilih monolit yang lebih sederhana untuk mempercepat pengembangan dan menjaga basis kode Anda tetap bersih.

Pembangunan Terorganisir

Seperti yang kami sebutkan sebelumnya, arsitektur aplikasi web yang tepat memberi Anda peta jalan yang lebih nyaman untuk pengembangan. Arsitektur menyediakan cukup modularitas dalam sistem Anda untuk mengisolasi komponen seperlunya, dan Anda mendapatkan kebebasan untuk memilih struktur proyek yang tepat untuk setiap modul dan komponen Anda sebagaimana diperlukan.

Jika Anda terjun ke dalam pengembangan aplikasi tanpa mempertimbangkan arsitektur, Anda berisiko membuang waktu dan uang untuk mengatur ulang komponen Anda dan menyusun aturan baru untuk membantu memfasilitasi kolaborasi antara anggota tim Anda — waktu dan uang yang seharusnya bisa dihabiskan di tempat lain.

Manajemen Basis Kode yang Lebih Baik

Selain menulis kode aplikasi, Anda juga akan menghabiskan banyak waktu untuk mengelolanya. Mengatur file proyek Anda, memecah aplikasi Anda menjadi beberapa modul, dan menyiapkan saluran khusus hanyalah beberapa tugas yang memerlukan pemeliharaan aktif untuk memastikan pengembangan yang lancar.

Arsitektur aplikasi web yang tepat memudahkan Anda melakukan perubahan. Anda dapat menerapkan praktik terbaik khusus komponen, memisahkan titik nyeri aplikasi Anda satu sama lain, dan menjaga agar setiap fitur tetap independen dan digabungkan secara longgar. Bukannya hal-hal ini tidak dapat dilakukan tanpa arsitektur; hanya saja arsitektur yang tepat membuat semuanya menjadi lebih sederhana.

Mengikuti arsitektur yang telah ditentukan sebelumnya juga memudahkan Anda mengembangkan aplikasi lebih cepat. Arsitektur yang tepat dikombinasikan dengan strategi kontrol versi yang baik dapat memungkinkan pengembang Anda untuk bekerja secara paralel satu sama lain dan membangun fitur lebih cepat.

Arsitektur aplikasi web juga membuktikan aplikasi Anda di masa depan. Setelah Anda menentukan strategi yang solid seputar cara mengatur komponen aplikasi, Anda dapat dengan mudah memigrasikan komponen tersebut ke teknologi yang lebih baru satu per satu tanpa harus mengulang seluruh aplikasi Anda.

Keamanan yang Ditingkatkan

Sebagian besar arsitektur aplikasi web memperhitungkan keamanan saat menyusun komponen. Pengembang dapat merencanakan, sebelumnya, tindakan dan praktik yang akan diterapkan untuk meningkatkan keamanan aplikasi sebelum diluncurkan ke pengguna.

Misalnya, membuat aplikasi streaming video OTT yang menawarkan konten berbayar dan gratis menggunakan layanan mikro lebih masuk akal karena arsitektur layanan mikro memungkinkan Anda membagi aplikasi menjadi komponen yang ramah bisnis, seperti autentikasi pengguna dan streaming konten gratis atau berbayar. Jika modul autentikasi pengguna Anda down, Anda dapat dengan mudah mengonfigurasi aplikasi Anda untuk membatasi akses ke modul konten berbayar hingga auth aktif sementara modul konten gratis masih tersedia untuk pengguna Anda.

Dalam kasus alternatif di mana aplikasi yang sama ini dirancang sebagai monolit yang dipasangkan dengan erat, layanan autentikasi yang diturunkan berarti aplikasi yang diturunkan atau konten berbayar yang tersedia secara gratis — hasil yang ingin Anda hindari dengan cara apa pun.

Bagaimana Arsitektur Aplikasi Web Bekerja?

Sebelum kita berbicara tentang cara kerja arsitektur aplikasi web, penting untuk memahami cara kerja situs web sederhana:

1. Pengguna memasukkan URL aplikasi Anda di bilah alamat browser atau mengklik tautan.
2. Browser mencari URL di server DNS dan mengidentifikasi alamat IP aplikasi Anda.
3. Browser mengirimkan permintaan HTTP ke aplikasi Anda.
4. Aplikasi Anda merespons dengan konten yang benar (biasanya halaman web).
5. Browser merender halaman web di layar.

Jika Anda ingin menyelam lebih dalam, inilah cara aplikasi web menangani permintaan:

1. Pengguna mengirimkan permintaan ke aplikasi Anda melalui antarmuka pengguna frontend Anda.
2. Jika Anda memiliki cache yang relevan, aplikasi pertama-tama akan memeriksanya untuk melihat apakah memiliki catatan valid yang dapat dikirim kembali ke klien secara langsung. Jika ya, konten yang di-cache akan dikirim kembali, dan permintaan akan ditandai sebagai selesai.
3. Jika tidak ada cache, permintaan diteruskan ke penyeimbang beban.
4. Penyeimbang beban mengidentifikasi instance server yang tersedia untuk menangani permintaan dan meneruskannya.
5. Instance server memproses permintaan dan memanggil API eksternal apa pun jika diperlukan.
6. Setelah hasil dikumpulkan di satu tempat, server mengirimkan kembali respons ke penyeimbang beban.
7. Penyeimbang beban mengembalikan respons ke gateway API, yang pada gilirannya mengirimkannya ke pengguna di klien frontend. Permintaan tersebut kemudian ditandai sebagai selesai.

Jenis Arsitektur Aplikasi Web

Sekarang setelah Anda memiliki gagasan dasar tentang apa itu arsitektur aplikasi web, mari kita lihat secara mendetail beberapa jenis arsitektur aplikasi web populer yang digunakan di seluruh web.

Arsitektur Satu Halaman

Arsitektur untuk aplikasi satu halaman (SPA) sesederhana namanya: Seluruh aplikasi didasarkan pada satu halaman. Setelah pengguna membuka aplikasi Anda, mereka tidak perlu menavigasi ke halaman web lain. Aplikasi dibuat cukup dinamis untuk mengambil dan merender layar yang memenuhi persyaratan pengguna saat mereka menavigasi melalui aplikasi itu sendiri.

SPA sangat bagus dalam hal memberikan pengalaman yang cepat dan mulus kepada pengguna akhir atau konsumen. Namun, mereka tidak memiliki sentuhan situs web tradisional, dan mereka bisa sulit untuk dioptimalkan untuk SEO.

Kelebihan Arsitektur SPA

Beberapa kelebihan arsitektur SPA meliputi:

• Anda dapat membuat aplikasi web yang sangat interaktif.
• SPA mudah untuk diukur.
• Mengoptimalkan SPA untuk kinerja tidak memerlukan banyak usaha.

Kontra Arsitektur SPA

Beberapa kelemahan arsitektur SPA adalah:

• SPA membatasi fleksibilitas dengan hyperlink dan SEO.
• Render awal biasanya lambat.
• Navigasi melalui aplikasi bisa jadi tidak intuitif.

Arsitektur Aplikasi Web Progresif

Arsitektur Progressive Web Application (PWA) dibangun di atas Arsitektur Halaman Tunggal dengan menyediakan kemampuan offline untuk aplikasi web Anda. Teknologi seperti Capacitor dan Ionic digunakan untuk membangun PWA yang dapat memberikan pengalaman yang seragam kepada pengguna di seluruh platform.

Mirip dengan SPA, PWA mulus dan mulus. Dengan kemampuan tambahan untuk diinstal pada perangkat pengguna (melalui pekerja layanan), pengguna Anda mendapatkan pengalaman yang lebih seragam dengan aplikasi Anda.

Pada saat yang sama, mungkin sulit untuk mengoptimalkan aplikasi semacam itu untuk SEO, dan pembaruan pada aplikasi yang diinstal bisa sulit untuk didorong.

Kelebihan Arsitektur PWA

Ada banyak manfaat dari arsitektur PWA, antara lain:

• Aplikasi berjalan sangat lancar dan menawarkan kompatibilitas lintas platform.
• Skalabilitasnya sederhana.
• Akses offline dan API asli perangkat seperti pekerja latar belakang dan pemberitahuan push dapat diakses oleh pengembang.

Kontra Arsitektur PWA

Beberapa kontra arsitektur PWA dapat mencakup:

• Ada dukungan terbatas untuk manajemen tautan dan SEO.
• Mendorong pembaruan ke PWA offline lebih kompleks daripada dengan aplikasi asli.
• Ada dukungan terbatas untuk PWA di seluruh browser web dan sistem operasi.

Arsitektur yang dirender sisi server

Dalam rendering sisi server (SSR), halaman web frontend dirender di server backend setelah diminta oleh pengguna. Ini membantu mengurangi beban pada perangkat klien karena menerima halaman web HTML, CSS, dan JS statis.

Aplikasi SSR sangat populer di kalangan blog dan situs web e-niaga. Ini karena mereka membuat manajemen tautan dan SEO cukup sederhana. Selain itu, render pertama untuk aplikasi SSR cukup cepat karena klien tidak perlu memproses kode JS apa pun untuk merender layar.

Kelebihan Arsitektur RSK

Beberapa kelebihan arsitektur SSR tercantum di bawah ini:

• Aplikasi ini sangat bagus untuk situs web yang berat SEO.
• Pemuatan halaman pertama hampir instan dalam banyak kasus.
• Anda dapat memasangkannya dengan layanan caching untuk lebih meningkatkan kinerja aplikasi Anda.

Kontra Arsitektur RSS

Beberapa kelemahan menggunakan arsitektur SSR meliputi:

• Tidak disarankan untuk halaman web yang kompleks atau berat karena server dapat membutuhkan waktu untuk menghasilkan halaman sepenuhnya yang mengakibatkan render pertama tertunda.
• Ini sebagian besar direkomendasikan untuk aplikasi yang tidak terlalu fokus pada antarmuka pengguna dan hanya mencari peningkatan skalabilitas atau keamanan.

Arsitektur Aplikasi yang Dirender sebelumnya

Arsitektur aplikasi pra-render juga dikenal sebagai arsitektur pembuatan situs statis. Dalam arsitektur ini, halaman web frontend aplikasi dibuat sebelumnya dan disimpan sebagai file HTML, CSS, dan JS biasa di server. Setelah pengguna meminta halaman, halaman tersebut langsung diambil dan ditampilkan kepada mereka. Ini membuat aplikasi web menjadi sangat cepat, dengan waktu muat minimal dalam jenis apa pun. Namun, arsitektur ini menambah waktu pembuatan aplikasi karena halaman web dirender selama proses pembuatan.

Aplikasi web pra-render sangat bagus ketika Anda ingin menghasilkan konten statis seperti blog atau detail produk yang tidak sering berubah. Anda juga dapat menggunakan template untuk menyederhanakan desain halaman web Anda. Namun, hampir tidak mungkin untuk membangun aplikasi web dinamis dengan arsitektur ini. Jika Anda ingin membuat halaman pencarian yang mengambil kueri di jalurnya (seperti https://myapp.com/search/foo+bar ), Anda berada di tempat yang salah.

Karena setiap kemungkinan rute aplikasi dirender sebelumnya selama proses pembuatan, tidak mungkin untuk memiliki rute dinamis seperti di atas karena ada kemungkinan tak terbatas yang tidak dapat dirender sebelumnya selama pembuatan (dan tidak masuk akal untuk dilakukan jadi juga).

Kelebihan Arsitektur Pra-rendered

Beberapa manfaat utama dari arsitektur aplikasi pra-render adalah:

• Halaman web dibuat dalam HTML, CSS, dan JS murni; karenanya kinerjanya mirip dengan aplikasi yang dibangun menggunakan vanilla JS.
• Jika Anda mengetahui semua kemungkinan rute aplikasi Anda, SEO menjadi sangat mudah.

Kontra Arsitektur Pra-rendered

Seperti model arsitektur lainnya, pra-render memiliki kekurangannya sendiri:

• Konten dinamis tidak dapat disajikan dengan aplikasi ini.
• Membuat perubahan apa pun pada aplikasi web berarti membangun kembali dan menerapkan aplikasi sepenuhnya dari awal.

Arsitektur Aplikasi Isomorfik

Aplikasi isomorfik adalah aplikasi yang merupakan campuran dari aplikasi dan SPA yang dirender sisi server. Ini berarti bahwa aplikasi tersebut pertama kali dirender di server sebagai aplikasi yang dirender sisi server normal. Setelah diterima oleh klien, aplikasi menghidrasi dirinya sendiri dan melampirkan DOM virtual untuk pemrosesan klien yang lebih cepat dan efisien. Ini pada dasarnya mengubah aplikasi menjadi aplikasi satu halaman.

Isomorphic menyatukan yang terbaik dari kedua dunia. Anda mendapatkan pemrosesan super cepat dan antarmuka pengguna pada klien, berkat SPA. Anda juga mendapatkan render awal yang cepat dan dukungan SEO serta penautan yang lengkap, berkat rendering sisi server.

Kelebihan Arsitektur Isomorfik

Berikut adalah beberapa manfaat menggunakan arsitektur aplikasi isomorfik:

• Aplikasi isomorfik memiliki rendering awal yang sangat cepat dan dukungan penuh untuk SEO.
• Aplikasi ini juga berkinerja baik di klien karena berubah menjadi SPA setelah dimuat.

Kontra Arsitektur Isomorfik

Beberapa kontra dari arsitektur aplikasi isomorfik dapat berupa:

• Menyiapkan aplikasi semacam itu membutuhkan bakat yang terampil.
• Pilihan tumpukan teknologi terbatas dalam hal merancang aplikasi isomorfik. Anda hanya dapat memilih dari beberapa (kebanyakan) perpustakaan dan kerangka kerja berbasis JS.

Arsitektur berorientasi layanan

Arsitektur berorientasi layanan adalah salah satu alternatif paling populer untuk cara monolit tradisional dalam membangun aplikasi. Dalam arsitektur ini, aplikasi web dipecah menjadi layanan yang mewakili unit fungsional bisnis masing-masing. Layanan ini secara longgar digabungkan bersama dan berinteraksi satu sama lain melalui media penyampaian pesan.

Arsitektur berorientasi layanan menambahkan stabilitas dan skalabilitas ke tumpukan teknologi aplikasi Anda. Namun, ukuran layanan di SOA tidak didefinisikan dengan jelas dan biasanya terkait dengan komponen bisnis, bukan komponen teknis; maka pemeliharaan kadang-kadang bisa menjadi masalah.

Kelebihan Arsitektur Berorientasi Layanan

Manfaat utama arsitektur berorientasi layanan meliputi:

• Arsitektur ini membantu membangun aplikasi yang sangat skalabel dan andal.
• Komponen dapat digunakan kembali dan digunakan bersama untuk meningkatkan upaya pengembangan dan pemeliharaan.

Kontra Arsitektur Berorientasi Layanan

Berikut daftar potensi kelemahan menggunakan arsitektur berorientasi layanan:

• Aplikasi SOA masih belum 100% fleksibel karena ukuran dan cakupan setiap layanan tidak tetap. Mungkin ada layanan seukuran aplikasi perusahaan yang sulit dipelihara.
• Berbagi komponen memperkenalkan ketergantungan antar layanan.

Arsitektur Layanan Mikro

Arsitektur layanan mikro dirancang untuk memecahkan masalah dengan arsitektur berorientasi layanan. Layanan mikro bahkan lebih merupakan komponen modular yang cocok untuk membangun aplikasi web. Namun, layanan mikro fokus untuk menjaga setiap komponen tetap kecil dan dengan konteks terbatas. Konteks terikat pada dasarnya berarti bahwa setiap layanan mikro memiliki kode dan datanya digabungkan bersama dengan ketergantungan minimal pada layanan mikro lainnya.

Arsitektur layanan mikro mungkin merupakan arsitektur terbaik untuk membangun aplikasi yang bertujuan untuk meningkatkan skala ke ribuan dan jutaan pengguna suatu hari nanti. Setiap komponen tangguh, terukur, dan mudah dirawat. Namun, mempertahankan siklus hidup DevOps untuk aplikasi berbasis layanan mikro memerlukan upaya tambahan; karenanya mungkin tidak cocok untuk kasus penggunaan yang lebih kecil.

Kelebihan Arsitektur Layanan Mikro

Beberapa kelebihan arsitektur layanan mikro meliputi:

• Komponen aplikasi sangat modular, independen, dan dapat digunakan kembali lebih luas daripada arsitektur berorientasi layanan.
• Setiap komponen dapat diskalakan secara independen untuk memenuhi lalu lintas pengguna yang berbeda-beda.
• Aplikasi berbasis layanan mikro sangat toleran terhadap kesalahan.

Kontra Arsitektur Layanan Mikro

Kelemahan arsitektur layanan mikro dapat berupa:

• Untuk proyek yang lebih kecil, arsitektur layanan mikro mungkin memerlukan terlalu banyak upaya untuk mempertahankannya.

Arsitektur Tanpa Server

Arsitektur tanpa server adalah pendatang baru lainnya di dunia arsitektur aplikasi web. Arsitektur ini berfokus pada penguraian aplikasi Anda dalam hal fungsi yang seharusnya dijalankan. Kemudian fungsi-fungsi ini di-host di platform FaaS (Function-as-a-Service) sebagai fungsi yang dipanggil saat dan saat permintaan masuk.

Tidak seperti kebanyakan arsitektur lain dalam daftar ini, aplikasi yang dibangun menggunakan arsitektur tanpa server tidak terus berjalan sepanjang waktu. Mereka berperilaku seperti fungsi yang akan dilakukan — tunggu dipanggil, dan setelah dipanggil, jalankan proses yang ditentukan dan kembalikan hasilnya. Karena sifat ini, mereka mengurangi biaya pemeliharaan dan sangat terukur tanpa banyak usaha. Namun, sulit untuk melakukan tugas jangka panjang menggunakan komponen tersebut.

Kelebihan Arsitektur Tanpa Server

Berikut adalah manfaat utama arsitektur tanpa server:

• Aplikasi tanpa server sangat dan mudah diskalakan. Mereka bahkan dapat beradaptasi dengan lalu lintas masuk secara real-time untuk mengurangi beban pada infrastruktur Anda.
• Aplikasi tersebut dapat menggunakan model penetapan harga bayar per penggunaan dari platform tanpa server untuk mengurangi biaya infrastruktur.
• Aplikasi tanpa server cukup mudah dibuat dan diterapkan karena yang harus Anda lakukan hanyalah menulis fungsi dan menghostingnya di platform seperti fungsi Firebase, AWS Lambda, dll.

Kontra Arsitektur Tanpa Server

Berikut adalah beberapa kelemahan arsitektur tanpa server:

• Tugas yang berjalan lama bisa mahal untuk dilakukan pada arsitektur seperti itu.
• Ketika suatu fungsi menerima permintaan setelah waktu yang lama, itu dikenal sebagai awal yang dingin. Mulai dingin lambat dan dapat memberikan pengalaman buruk bagi pengguna akhir Anda.

Lapisan Arsitektur Aplikasi Web

Meskipun arsitektur aplikasi web yang Anda lihat di atas mungkin terlihat sangat berbeda satu sama lain, komponennya dapat dikelompokkan secara logis menjadi lapisan tertentu yang membantu mencapai tujuan bisnis.

Lapisan Presentasi

Lapisan presentasi memperhitungkan semua yang ada di aplikasi web yang diekspos ke pengguna akhir. Terutama, lapisan presentasi terdiri dari klien frontend. Namun, ini juga menggabungkan logika apa pun yang telah Anda tulis di backend Anda untuk membuat frontend Anda dinamis. Ini memberi Anda ruang untuk melayani pengguna Anda dengan UI yang disesuaikan dengan profil dan persyaratan mereka.

Tiga teknologi dasar digunakan untuk membangun lapisan ini: HTML, CSS, dan JavaScript. HTML menata frontend Anda, CSS menatanya, dan JS menghidupkannya (yaitu, mengontrol perilakunya saat pengguna berinteraksi dengannya). Di atas ketiga teknologi ini, Anda dapat menggunakan kerangka kerja apa pun untuk membantu mempermudah pengembangan Anda. Beberapa kerangka kerja frontend umum termasuk Laravel, React, NextJS, Vue, GatsbyJS, dll.

Lapisan Bisnis

Lapisan bisnis bertanggung jawab untuk menahan dan mengelola logika kerja aplikasi Anda. Biasanya layanan backend yang menerima permintaan dari klien dan memprosesnya. Ini mengontrol apa yang dapat diakses pengguna dan menentukan bagaimana infrastruktur digunakan untuk melayani permintaan pengguna.

Dalam kasus aplikasi pemesanan hotel, aplikasi klien Anda berfungsi sebagai portal bagi pengguna untuk mengetikkan nama hotel dan data relevan lainnya. Namun, segera setelah pengguna mengklik tombol pencarian, lapisan bisnis menerima permintaan dan memulai logika untuk mencari kamar hotel yang tersedia yang sesuai dengan kebutuhan Anda. Klien kemudian hanya menerima daftar kamar hotel tanpa pengetahuan tentang bagaimana daftar ini dibuat atau bahkan mengapa item daftar diatur sedemikian rupa sehingga mereka dikirim.

Kehadiran lapisan seperti itu memastikan bahwa logika bisnis Anda tidak terekspos ke klien Anda dan, pada akhirnya, pengguna. Mengisolasi logika bisnis sangat membantu dalam operasi sensitif seperti menangani pembayaran atau mengelola catatan kesehatan.

Lapisan Persistensi

Lapisan persistensi bertanggung jawab untuk mengontrol akses ke penyimpanan data Anda. Ini bertindak sebagai lapisan abstraksi tambahan antara penyimpanan data Anda dan lapisan bisnis Anda. Ini menerima semua panggilan terkait data dari lapisan bisnis dan memprosesnya dengan membuat koneksi aman ke database.

Lapisan ini biasanya terdiri dari server database. Anda dapat mengatur sendiri lapisan ini dengan menyediakan database dan server database di infrastruktur lokal Anda atau memilih solusi jarak jauh/terkelola oleh salah satu penyedia infrastruktur cloud terkemuka seperti AWS, GCP, Microsoft Azure, dll.

Komponen Aplikasi Web

Sekarang setelah Anda memahami apa yang masuk ke dalam arsitektur aplikasi web, mari kita lihat detail setiap komponen yang menyusun aplikasi web. Kami akan mengelompokkan diskusi ini menjadi dua judul utama — komponen sisi server dan komponen sisi klien, atau komponen backend dan frontend.

Komponen sisi server

Komponen sisi server adalah komponen yang berada di backend aplikasi web Anda. Ini tidak diekspos langsung ke pengguna dan memegang logika bisnis paling penting dan sumber daya untuk aplikasi web Anda.

DNS & Perutean

DNS bertanggung jawab untuk mengontrol bagaimana aplikasi Anda diekspos ke web. Data DNS digunakan oleh klien HTTP, yang juga bisa menjadi browser, untuk menemukan dan mengirim permintaan ke komponen aplikasi Anda. DNS juga digunakan oleh klien frontend Anda secara internal untuk menyelesaikan lokasi server web Anda dan titik akhir API untuk mengirim permintaan dan memproses operasi pengguna.

Load balancing adalah komponen populer lain dari arsitektur aplikasi web. Penyeimbang beban digunakan untuk mendistribusikan permintaan HTTP antara beberapa server web yang identik. Maksud di balik memiliki beberapa server web adalah untuk mempertahankan redundansi yang membantu meningkatkan toleransi kesalahan serta mendistribusikan lalu lintas untuk mempertahankan kinerja tinggi.

Titik akhir API digunakan untuk mengekspos layanan backend ke aplikasi frontend. Ini membantu memfasilitasi komunikasi antara klien dan server, dan kadang-kadang bahkan antara beberapa server juga.

Penyimpanan data

Penyimpanan data adalah bagian penting dari sebagian besar aplikasi modern karena selalu ada beberapa data aplikasi yang perlu dipertahankan di seluruh sesi pengguna. Penyimpanan data terdiri dari dua jenis:

• Database: Database digunakan untuk menyimpan data untuk akses cepat. Biasanya, mereka mendukung penyimpanan sejumlah kecil data yang diakses secara teratur oleh aplikasi Anda.
• Gudang Data: Gudang data dimaksudkan untuk pelestarian data historis. Ini biasanya tidak terlalu sering dibutuhkan dalam aplikasi tetapi diproses secara teratur untuk menghasilkan wawasan bisnis.

Caching

Caching adalah fitur opsional yang sering diterapkan dalam arsitektur aplikasi web untuk menyajikan konten lebih cepat kepada pengguna. Sebagian besar konten aplikasi sering berulang untuk beberapa waktu, jika tidak selalu. Alih-alih mengaksesnya dari penyimpanan data dan memprosesnya sebelum mengirimnya kembali ke pengguna, sering kali di-cache. Berikut adalah dua jenis caching paling populer yang digunakan di seluruh aplikasi web:

• Caching data: Caching data memperkenalkan cara bagi aplikasi Anda untuk dengan mudah dan cepat mengakses data yang digunakan secara teratur yang tidak sering berubah. Teknologi seperti Redis dan Memcache memungkinkan data caching untuk menghemat kueri basis data yang mahal hanya untuk mengambil data yang sama berulang kali.
• Caching halaman web: CDN (Content Delivery Network) menyimpan halaman web dengan cara yang sama seperti Redis menyimpan data. Mirip dengan bagaimana hanya data yang tidak sering berubah yang di-cache, biasanya hanya halaman web statis yang disarankan untuk di-cache. Untuk aplikasi web yang dirender di sisi server, caching tidak banyak berguna karena kontennya seharusnya sangat dinamis.

Pekerjaan dan Layanan

Selain memperlihatkan antarmuka kepada pengguna (frontend) dan menangani permintaan mereka (backend), ada kategori komponen aplikasi web lain yang sedikit kurang populer. Pekerjaan sering kali merupakan layanan latar belakang yang dimaksudkan untuk menyelesaikan tugas yang tidak sensitif terhadap waktu atau tidak sinkron.

Pekerjaan CRON adalah pekerjaan yang dijalankan pada periode waktu tertentu berulang kali. Pekerjaan ini dijadwalkan di backend untuk menjalankan rutinitas pemeliharaan secara otomatis pada waktu yang ditentukan. Beberapa contoh kasus penggunaan yang umum untuk ini termasuk menghapus duplikat/catatan lama dari database, mengirimkan email pengingat kepada pelanggan, dll.

Komponen Sisi Klien

Komponen sisi klien adalah komponen yang diekspos ke pengguna Anda baik secara langsung maupun tidak langsung.

Ada dua jenis komponen dalam kategori ini.

Antarmuka Pengguna Frontend

Antarmuka pengguna adalah aspek visual dari aplikasi Anda. Ini adalah apa yang dilihat dan berinteraksi dengan pengguna Anda untuk mengakses layanan Anda.

Antarmuka frontend sebagian besar dibangun di atas tiga teknologi populer: HTML, CSS, dan JavaScript. Antarmuka pengguna frontend dapat menjadi aplikasi itu sendiri dengan siklus hidup pengembangan perangkat lunaknya sendiri.

Antarmuka pengguna ini tidak menampung banyak logika bisnis Anda karena mereka terpapar langsung ke pengguna Anda. Jika pengguna jahat mencoba merekayasa balik aplikasi frontend Anda, mereka bisa mendapatkan informasi tentang cara kerja bisnis Anda dan melakukan aktivitas ilegal seperti peniruan identitas merek dan pencurian data.

Selain itu, karena antarmuka pengguna frontend diekspos langsung ke pengguna, Anda sebaiknya mengoptimalkannya untuk waktu pemuatan dan responsivitas yang minimal. Terkadang ini dapat membantu Anda memberikan pengalaman yang lebih baik kepada pengguna Anda, sehingga meningkatkan pertumbuhan bisnis Anda.

Logika Bisnis Sisi Klien

Terkadang Anda mungkin perlu menyimpan beberapa logika bisnis pada klien Anda untuk melakukan operasi yang lebih sederhana dengan cepat. Logika sisi klien yang biasanya berada di dalam aplikasi frontend Anda dapat membantu Anda melewati perjalanan ke server dan memberikan pengalaman yang lebih cepat kepada pengguna Anda.

Ini adalah fitur opsional dari komponen sisi klien. Dalam beberapa kasus, logika bisnis aplikasi disimpan seluruhnya di sisi klien (terutama saat membangun tanpa server backend tradisional). Solusi modern seperti BaaS membantu Anda mengakses operasi umum seperti otentikasi, penyimpanan data, penyimpanan file, dll., saat bepergian di aplikasi frontend Anda.

Ada beberapa cara untuk menyamarkan atau memperkecil kode ini sebelum meluncurkannya ke pengguna Anda untuk meminimalkan kemungkinan rekayasa balik.

Model Komponen Aplikasi Web

Ada beberapa model arsitektur aplikasi web, masing-masing berdasarkan bagaimana server web terhubung ke penyimpanan data mereka.

Satu Server, Satu Basis Data

Model paling sederhana dari semuanya adalah satu server web yang terhubung ke satu instance database. Model seperti itu mudah diterapkan dan dipelihara, dan produksi dengannya juga cukup mudah.

Karena kesederhanaannya, model ini cocok untuk pembelajaran dan untuk aplikasi eksperimental kecil yang tidak akan terkena lalu lintas tinggi. Pengembang pemula dapat dengan mudah mengatur dan mengotak-atik aplikasi ini untuk mempelajari dasar-dasar pengembangan aplikasi web.

Namun, model ini tidak boleh digunakan dalam produksi karena sangat tidak dapat diandalkan. Masalah baik di server atau database dapat mengakibatkan downtime dan kehilangan bisnis.

Beberapa Server, Satu Basis Data

Model ini meningkatkan aplikasi dengan menyiapkan beberapa server untuk redundansi dengan satu contoh database umum.

Karena beberapa server web mengakses database secara bersamaan, masalah inkonsistensi dapat terjadi. Untuk menghindari itu, server web dirancang untuk tidak memiliki kewarganegaraan. Ini berarti server tidak menyimpan data di seluruh sesi; mereka hanya memprosesnya dan menyimpannya di database.

Aplikasi yang dibuat menggunakan model ini tentu lebih andal dibandingkan dengan model sebelumnya, karena kehadiran beberapa server web menambah toleransi kesalahan aplikasi web. Namun, karena database masih merupakan salah satu contoh umum, itu adalah tautan terlemah dalam arsitektur dan dapat menjadi sumber kegagalan.

Banyak Server, Banyak Basis Data

Model ini adalah salah satu model desain aplikasi web tradisional yang paling umum.

Dalam hal ini, terapkan logika aplikasi Anda sebagai beberapa instance server web identik yang disatukan di belakang penyeimbang beban. Penyimpanan data Anda juga dipertahankan di beberapa instans database untuk menambah toleransi kesalahan.

Anda juga dapat memilih untuk membagi database Anda di antara instans yang tersedia untuk meningkatkan kinerja atau mempertahankan duplikat seluruh penyimpanan data untuk redundansi. Dalam kedua kasus tersebut, kegagalan dalam salah satu contoh database Anda tidak akan menyebabkan penghentian aplikasi sepenuhnya.

Model ini sangat dihargai karena keandalan dan skalabilitasnya. Namun, mengembangkan dan memelihara aplikasi menggunakan model ini relatif rumit dan membutuhkan pengembang berpengalaman yang mahal. Dengan demikian, model ini hanya disarankan saat Anda membangun dalam skala besar.

Layanan Aplikasi

Sementara tiga model yang disebutkan di atas sangat cocok untuk aplikasi monolitik, ada model lain untuk aplikasi modular.

Model layanan aplikasi memecah aplikasi menjadi modul yang lebih kecil berdasarkan fungsionalitas bisnis. Modul ini bisa sekecil fungsi atau sebesar layanan.

Idenya di sini adalah untuk membuat setiap fitur bisnis independen dan terukur. Masing-masing modul ini dapat terhubung ke database sendiri. Anda bahkan dapat memiliki instans database khusus agar sesuai dengan kebutuhan skalabilitas modul Anda.

Di antara aplikasi non-monolitik, model ini cukup populer. Monolit lama sering dimigrasikan ke model ini untuk memanfaatkan manfaat skalabilitas dan modularitasnya. Namun, mengelola aplikasi yang dibuat dengan model seperti itu sering kali membutuhkan pengembang berpengalaman, terutama pengalaman dalam DevOps dan CI/CD.

Praktik Terbaik untuk Arsitektur Aplikasi Web

Berikut adalah beberapa praktik terbaik yang dapat Anda terapkan dalam proyek aplikasi web Anda untuk mendapatkan hasil maksimal dari arsitektur aplikasi web pilihan Anda.

1. Jadikan Frontend Anda Responsif

Ini tidak bisa cukup ditekankan: Selalu bertujuan untuk frontend yang responsif. Tidak peduli seberapa besar dan kompleksnya aplikasi web Anda secara internal, semuanya terekspos kepada pengguna Anda melalui halaman web frontend, aplikasi, dan layar.

Jika pengguna Anda merasa layar ini tidak intuitif atau lambat, mereka tidak akan bertahan cukup lama untuk melihat dan mengagumi keajaiban teknik yang merupakan aplikasi web Anda.

Oleh karena itu, merancang frontend yang mudah diakses, mudah digunakan, dan ringan sangat penting.

Ada banyak praktik terbaik UI/UX yang tersedia di seluruh web untuk membantu Anda memahami apa yang terbaik untuk pengguna Anda. Anda dapat menemukan profesional yang ahli dalam membuat desain dan arsitektur yang ramah pengguna yang dapat memungkinkan pengguna Anda untuk mendapatkan hasil maksimal dari aplikasi Anda.

Kami menyarankan untuk mempertimbangkan dengan serius respons frontend Anda sebelum meluncurkan produk Anda kepada pengguna Anda.

2. Pantau Waktu Muat

Selain mudah dipahami, frontend Anda juga harus cepat dimuat.

Menurut Portent, tingkat konversi e-niaga tertinggi terjadi pada halaman dengan waktu buka antara 0–2 detik, dan menurut Unbounce, sekitar 70% konsumen mengakui bahwa waktu pemuatan halaman merupakan faktor penting dalam pilihan mereka untuk membeli dari penjual online.

Saat merancang aplikasi asli seluler, Anda biasanya tidak dapat memastikan spesifikasi perangkat pengguna Anda. Perangkat apa pun yang tidak memenuhi persyaratan aplikasi Anda biasanya dinyatakan tidak mendukung aplikasi.

Namun, ini sangat berbeda dengan web.

Ketika datang ke aplikasi web, pengguna Anda dapat menggunakan apa saja dari Apple Macbook M1 Pro terbaru hingga Blackberry antik dan ponsel Nokia untuk melihat aplikasi Anda. Mengoptimalkan pengalaman frontend Anda untuk berbagai macam pengguna terkadang bisa jadi sulit.

Layanan seperti LightHouse dan Google PageSpeed ​​muncul di benak ketika berbicara tentang kinerja frontend. Anda harus menggunakan alat tersebut untuk membandingkan aplikasi frontend Anda sebelum menerapkannya dalam produksi. Sebagian besar alat tersebut memberi Anda daftar kiat yang dapat ditindaklanjuti untuk membantu meningkatkan kinerja aplikasi Anda sebanyak mungkin.

5-10% akhir dari kinerja aplikasi biasanya khusus untuk kasus penggunaan Anda dan hanya dapat diperbaiki oleh seseorang yang mengetahui aplikasi Anda dan teknologinya dengan baik. Tidak ada salahnya untuk berinvestasi dalam kinerja web!

3. Pilih PWA Sedapat Mungkin

Seperti dibahas sebelumnya, PWA adalah desain masa depan. Mereka dapat menyesuaikan sebagian besar kasus penggunaan dengan baik, dan memberikan pengalaman paling seragam di seluruh platform utama.

Anda harus mempertimbangkan untuk menggunakan PWA untuk aplikasi Anda sesering mungkin. Pengalaman asli di web dan seluler sangat berdampak bagi pengguna Anda dan juga dapat mengurangi banyak beban kerja Anda sendiri.

PWA juga cepat dimuat, mudah dioptimalkan, dan cepat dibuat. Memilih PWA dapat membantu Anda mengalihkan banyak fokus dari pengembangan ke bisnis sejak dini.

Jaga Basis Kode Anda Bersih dan Ringkas

Basis kode yang bersih dapat membantu Anda menemukan dan menyelesaikan sebagian besar masalah sebelum menyebabkan kerusakan. Berikut adalah beberapa tip yang dapat Anda ikuti untuk memastikan bahwa basis kode Anda tidak menyebabkan masalah lebih dari yang seharusnya.

• Fokus pada penggunaan kembali kode: Mempertahankan salinan kode yang sama di seluruh basis kode Anda tidak hanya berlebihan, tetapi juga dapat menyebabkan perbedaan merayap masuk, membuat basis kode Anda sulit dipelihara. Selalu fokus pada penggunaan kembali kode sedapat mungkin.
• Rencanakan struktur proyek Anda: Proyek perangkat lunak dapat berkembang sangat besar seiring waktu. Jika Anda tidak memulai dengan struktur organisasi dan sumber daya yang direncanakan, Anda mungkin akan menghabiskan lebih banyak waktu untuk menemukan file daripada menulis kode yang berguna.
• Tulis tes unit: Setiap bagian kode memiliki peluang untuk rusak. Menguji semuanya secara manual tidak layak, jadi Anda memerlukan strategi tetap untuk mengotomatiskan pengujian untuk basis kode Anda. Test runner dan alat cakupan kode dapat membantu Anda mengidentifikasi apakah upaya pengujian unit Anda memberikan hasil yang diinginkan.
• Modularitas tinggi: Saat menulis kode, selalu fokus pada modularitas. Menulis kode yang digabungkan erat dengan potongan kode lain membuat sulit untuk diuji, digunakan kembali, dan diubah bila diperlukan.

5. Otomatiskan Proses CI/CD Anda

CI/CD adalah singkatan dari Continuous Integration/Continuous Deployment. Proses CI/CD sangat penting untuk pengembangan aplikasi Anda karena membantu Anda membangun, menguji, dan menyebarkan proyek Anda dengan mudah.

Namun, Anda tidak ingin harus menjalankannya secara manual setiap kali. Sebaiknya Anda menyiapkan pipeline yang memicu secara otomatis berdasarkan aktivitas proyek Anda. Misalnya, Anda dapat menyiapkan saluran yang menjalankan pengujian secara otomatis setiap kali Anda memasukkan kode ke sistem kontrol versi. Ada banyak kasus penggunaan yang lebih kompleks juga, seperti menghasilkan artefak lintas platform dari repositori kode Anda setiap kali rilis dibuat.

Kemungkinannya tidak terbatas, jadi terserah Anda untuk mencari tahu bagaimana Anda dapat memaksimalkan saluran CI/CD Anda.

6. Menggabungkan Fitur Keamanan

Sebagian besar aplikasi modern terbuat dari banyak komponen. Ambil aplikasi berikut sebagai contoh:

Permintaan klien dirutekan ke aplikasi melalui gateway API. Sementara yang ini saat ini hanya mengizinkan permintaan langsung ke modul beranda aplikasi, di masa mendatang, ini dapat memungkinkan akses ke lebih banyak komponen tanpa melalui modul beranda.

Selanjutnya, modul rumah memeriksa BaaS otentikasi eksternal sebelum mengizinkan akses. Setelah diautentikasi, klien dapat mengakses halaman “Perbarui Profil” atau “Lihat Profil”. Kedua halaman ini berinteraksi dengan solusi database terkelola umum yang menangani data profil.

Seperti yang Anda lihat, aplikasi ini tampak seperti versi yang sangat mendasar dan minimal dari direktori orang online. Anda dapat menambah/memperbarui profil Anda sendiri atau melihat profil lain yang tersedia.

Berikut adalah legenda singkat dari berbagai komponen dalam arsitektur:

• Kotak biru: Modul aplikasi, yang mungkin dihosting sebagai layanan mikro atau fungsi tanpa server.
• Kotak merah: Komponen BaaS eksternal yang menyediakan otentikasi dan database.
• Kotak hijau: Komponen perutean yang mengatur permintaan masuk dari klien.
• Kotak hitam: Aplikasi klien Anda diekspos ke pengguna.

Komponen dari masing-masing warna di atas rentan terhadap berbagai macam ancaman keamanan. Berikut adalah beberapa konstruksi keamanan yang dapat Anda terapkan untuk meminimalkan eksposur Anda:

• Modul aplikasi (biru): Karena ini adalah fungsi tanpa server, berikut adalah beberapa kiat untuk memperkuat keamanannya:
  • Pisahkan rahasia aplikasi dan kelola secara independen dari kode sumber Anda
  • Pertahankan kontrol akses melalui layanan IAM
  • Tingkatkan upaya pengujian Anda untuk juga mencari ancaman keamanan melalui teknik seperti SAST
• Layanan eksternal (merah):
  • Siapkan kontrol akses melalui modul IAM mereka untuk mengatur akses
  • Memilih pembatasan tingkat API
  • For services such as databases, set up finer control permissions, such as who can access the profiles' data, who can view the users' data, and more. Many services, like Firebase, provide a detailed set of such rules.
• Routing component (green):
  • Like all other components, implement access controls
  • Siapkan otorisasi
  • Periksa kembali praktik terbaik standar seperti CORS
• Client:
  • Ensure that no app secrets are available to your client
  • Obfuscate your client code to minimize the chances of reverse engineering

While these are just a handful of suggestions, they stand to make the point that app security is complicated, and it's your responsibility to ensure that you're not leaving any loose ends for attackers to pull on. You cannot rely on a central security component to protect your business; app security is distributed across your app architecture.

7. Collect User Feedback

User feedback is a crucial tool to understand how well your app is doing in terms of business and technical performance. You can build the lightest and the smoothest app in the world, but if it doesn't let your users do what they expect, then all your efforts go down the drain.

There are multiple ways to collect user feedback. While a quick and anonymized survey is the conventional approach, you could also go for a more sophisticated solution, such as a heat map of your users' activity.

The choice of feedback collection method is less important than taking action on the collected feedback. Customers love businesses that listen to their problems. Giants like McDonald's and Tesla do it, and that's one of the reasons why they continue to succeed in their markets.

Ringkasan

The web is a huge playground of a variety of applications, each designed in its own unique way. Multiple types of architectures make way for web apps to diversify, thrive, and offer services to users all across the globe.
Learn how web application architecture affects the end-user experience and see best practices you can implement, all in this guide Click to Tweet
In this guide, we broke down the different models of web app architecture and showed you how crucial they are to an application's growth.

Is there a web app architecture that you really loved? Or is there another that you'd like to share with the world? Let us know in the comments below!