Pilih Antara Aplikasi Web Tradisional dan Aplikasi Halaman Tunggal (SPA)
Tip
Konten ini adalah kutipan dari e-book berjudul Architect Modern Web Applications with ASP.NET Core and Azure, yang tersedia di .NET Docs atau sebagai PDF yang dapat diunduh gratis dan dibaca secara offline.
"Hukum Atwood: Aplikasi apa pun yang dapat ditulis dalam JavaScript, pada akhirnya akan ditulis dalam JavaScript."
- Jeff Atwood
Ada dua pendekatan umum untuk membangun aplikasi web saat ini: aplikasi web tradisional yang melakukan sebagian besar logika aplikasi di server, dan aplikasi halaman tunggal (SPA) yang melakukan sebagian besar logika antarmuka pengguna di browser web, berkomunikasi dengan server web terutama menggunakan API web. Pendekatan hibrid juga memungkinkan, yang paling sederhana adalah menghosting satu atau beberapa subaplikasi seperti SPA yang kaya dalam aplikasi web tradisional yang lebih besar.
Gunakan aplikasi web tradisional saat:
Persyaratan sisi klien aplikasi Anda adalah sederhana atau baca-saja.
Aplikasi Anda harus berfungsi di browser tanpa dukungan JavaScript.
Aplikasi Anda menghadap publik dan mendapat manfaat dari penemuan dan rujukan mesin pencari.
Gunakan SPA saat:
Aplikasi Anda harus mengekspos antarmuka pengguna yang kaya dengan banyak fitur.
Tim Anda terbiasa dengan pengembangan JavaScript, TypeScript, atau BlazorWebAssembly.
Aplikasi Anda harus sudah mengekspos API untuk klien (internal atau publik) lainnya.
Selain itu, kerangka kerja SPA memerlukan keahlian arsitektur dan keamanan yang lebih besar. Mereka mengalami churn yang lebih besar karena seringnya pembaruan dan kerangka kerja klien baru daripada aplikasi web tradisional. Mengonfigurasi proses build dan penyebaran otomatis serta menggunakan opsi penyebaran seperti kontainer mungkin lebih sulit dengan aplikasi SPA daripada aplikasi web tradisional.
Peningkatan pengalaman pengguna yang dimungkinkan oleh pendekatan SPA harus dipertimbangkan dengan pertimbangan ini.
Blazor
ASP.NET Core menyertakan model untuk membangun antarmuka pengguna yang kaya, interaktif, dan dapat disusun yang disebut Blazor. Sisi server Blazor memungkinkan pengembang untuk membangun antarmuka pengguna dengan C# dan Razor di server dan agar antarmuka pengguna terhubung secara interaktif ke browser secara real time menggunakan koneksi SignalR yang persisten. BlazorWebAssembly memperkenalkan opsi lain untuk aplikasi Blazor, memungkinkannya berjalan di browser menggunakan WebAssembly. Karena ini adalah kode .NET nyata yang berjalan di WebAssembly, Anda dapat menggunakan kembali kode dan pustaka dari bagian sisi server aplikasi Anda.
Blazor menyediakan opsi ketiga baru untuk dipertimbangkan saat mengevaluasi apakah akan membangun aplikasi web murni yang dirender oleh server atau SPA. Anda dapat membangun perilaku sisi klien yang kaya SPA menggunakan Blazor, tanpa perlu pengembangan JavaScript yang signifikan. Aplikasi Blazor dapat memanggil API untuk meminta data atau melakukan operasi sisi server. Aplikasi dapat beroperasi dengan JavaScript jika perlu untuk memanfaatkan pustaka dan kerangka kerja JavaScript.
Pertimbangkan untuk membangun aplikasi web Anda dengan Blazor saat:
Aplikasi Anda harus mengekspos antarmuka pengguna yang kaya
Tim Anda lebih cocok dengan pengembangan .NET daripada pengembangan JavaScript atau TypeScript
Jika Anda sudah memiliki aplikasi formulir web, Anda sedang mempertimbangkan untuk bermigrasi ke .NET Core atau .NET terbaru, Anda mungkin ingin meninjau e-book gratis, Blazor untuk Pengembang Formulir Web untuk melihat apakah masuk akal mempertimbangkan untuk memigrasikannya ke Blazor.
Untuk informasi selengkapnya tentang Blazor, lihat Memulai dengan Blazor.
Waktu untuk memilih aplikasi web tradisional
Bagian berikut adalah penjelasan yang lebih rinci tentang alasan yang disebutkan sebelumnya untuk memilih aplikasi web tradisional.
Aplikasi Anda memiliki persyaratan sisi klien yang sederhana, mungkin baca-saja
Banyak aplikasi web terutama dikonsumsi dalam mode baca-saja oleh sebagian besar pengguna mereka. Aplikasi baca-saja (atau baca-sebagian besar) cenderung jauh lebih sederhana daripada aplikasi yang mempertahankan dan memanipulasi banyak status. Misalnya, mesin cari mungkin terdiri dari satu titik entri dengan kotak teks dan halaman kedua untuk menampilkan hasil pencarian. Pengguna anonim dapat dengan mudah membuat permintaan, dan logika sisi klien tidak terlalu diperlukan. Demikian juga, blog atau aplikasi sistem manajemen konten yang menghadap publik biasanya terdiri dari konten dengan sedikit perilaku sisi klien. Aplikasi tersebut dengan mudah dibangun sebagai aplikasi web berbasis server tradisional, yang melakukan logika di server web dan merender HTML untuk ditampilkan di browser. Fakta bahwa setiap halaman unik situs memiliki URL sendiri yang dapat di jangkar dan diindeks oleh mesin cari (secara default, tanpa harus menambahkan fungsionalitas ini sebagai fitur terpisah dari aplikasi) juga merupakan keuntungan yang jelas dalam skenario tersebut.
Aplikasi Anda harus berfungsi di browser tanpa dukungan JavaScript
Aplikasi web yang perlu berfungsi di browser dengan dukungan JavaScript terbatas atau tidak harus ditulis menggunakan alur kerja aplikasi web tradisional (atau setidaknya dapat kembali ke perilaku tersebut). SPA memerlukan JavaScript sisi klien agar berfungsi; jika tidak tersedia, SPA bukanlah pilihan yang baik.
Tim Anda tidak terbiasa dengan teknik pengembangan JavaScript atau TypeScript
Jika tim Anda tidak terbiasa dengan JavaScript atau TypeScript, tetapi terbiasa dengan pengembangan aplikasi web sisi server, maka mereka mungkin akan dapat mengirimkan aplikasi web tradisional lebih cepat daripada SPA. Kecuali belajar untuk memprogram SPA adalah tujuan, atau pengalaman pengguna yang diberikan oleh SPA diperlukan, aplikasi web tradisional adalah pilihan yang lebih produktif bagi tim yang sudah terbiasa membangunnya.
Kapan memilih SPA
Bagian berikut adalah penjelasan yang lebih rinci tentang kapan harus memilih gaya Aplikasi Satu Halaman dari pengembangan untuk aplikasi web Anda.
Aplikasi Anda harus mengekspos antarmuka pengguna yang kaya dengan banyak fitur
SPA dapat mendukung fungsionalitas sisi klien yang kaya yang tidak memerlukan pemuatan ulang halaman saat pengguna mengambil tindakan atau menavigasi di antara area aplikasi. SPA dapat dimuat lebih cepat, mengambil data di latar belakang, dan tindakan pengguna individual lebih responsif karena pemuatan ulang halaman penuh jarang terjadi. SPA dapat mendukung pembaruan bertambah bertahap, menyimpan sebagian formulir atau dokumen yang telah selesai tanpa pengguna harus mengklik tombol untuk mengirimkan formulir. SPA dapat mendukung perilaku sisi klien yang kaya, seperti seret dan lepaskan, jauh lebih mudah daripada aplikasi tradisional. SPA dapat dirancang agar berjalan dalam mode terputus, membuat pembaruan pada model sisi klien yang akhirnya disinkronkan kembali ke server setelah koneksi dibuat kembali. Pilih aplikasi bergaya SPA jika persyaratan aplikasi Anda mencakup fungsionalitas kaya yang melampaui formulir HTML biasa tawarkan.
Sering kali, SPA perlu mengimplementasikan fitur yang dibangun ke dalam aplikasi web tradisional, seperti menampilkan URL bermakna di bilah alamat yang mencerminkan operasi saat ini (dan memungkinkan pengguna untuk menjangkar atau tautan mendalam ke URL ini untuk dikembalikan ke dalamnya). SPA juga harus memungkinkan pengguna untuk menggunakan tombol kembali dan teruskan browser dengan hasil yang tidak akan mengejutkan mereka.
Tim Anda terbiasa dengan pengembangan JavaScript dan/atau TypeScript
Menulis SPA memerlukan keakraban dengan JavaScript dan/atau TypeScript serta teknik dan pustaka pemrograman sisi klien. Tim Anda harus kompeten dalam menulis JavaScript modern menggunakan kerangka kerja SPA seperti Angular.
Referensi – Kerangka Kerja SPA
- Angular: https://angular.io
- React: https://reactjs.org/
- Vue.js: https://vuejs.org/
Aplikasi Anda harus sudah mengekspos API untuk klien (internal atau publik) lainnya
Jika Anda sudah mendukung API web untuk digunakan oleh klien lain, mungkin perlu lebih sedikit upaya untuk membuat implementasi SPA yang memanfaatkan API ini daripada mereproduksi logika dalam bentuk sisi server. SPA menggunakan API web secara ekstensif untuk melakukan kueri dan memperbarui data saat pengguna berinteraksi dengan aplikasi.
Kapan memilih Blazor
Bagian berikut adalah penjelasan yang lebih rinci tentang kapan harus memilih Blazor untuk aplikasi web Anda.
Aplikasi Anda harus mengekspos antarmuka pengguna yang kaya
Seperti SPA berbasis JavaScript, aplikasi Blazor dapat mendukung perilaku klien yang kaya tanpa memuat ulang halaman. Aplikasi ini lebih responsif terhadap pengguna, hanya mengambil data (atau HTML) yang diperlukan untuk merespons interaksi pengguna tertentu. Dirancang dengan baik, aplikasi Blazor sisi server dapat dikonfigurasi untuk dijalankan sebagai aplikasi Blazor sisi klien dengan perubahan minimal setelah fitur ini didukung.
Tim Anda lebih nyaman dengan pengembangan .NET daripada pengembangan JavaScript atau TypeScript
Banyak pengembang lebih produktif dengan .NET dan Razor daripada dengan bahasa sisi klien seperti JavaScript atau TypeScript. Karena sisi server aplikasi sudah dikembangkan dengan .NET, menggunakan Blazor memastikan setiap pengembang .NET di tim dapat memahami dan berpotensi membangun perilaku ujung depan aplikasi.
Tabel keputusan
Tabel keputusan berikut merangkum beberapa faktor dasar yang perlu dipertimbangkan saat memilih antara aplikasi web tradisional, SPA, atau aplikasi Blazor.
| Kecil | Aplikasi Web Tradisional | Aplikasi Halaman Tunggal | Blazor App |
|---|---|---|---|
| Diperlukan Penguasaan Tim dengan JavaScript/TypeScript | Minimal | Diperlukan | Minimal |
| Mendukung Browser tanpa Scripting | Didukung | Tidak Didukung | Didukung |
| Perilaku Aplikasi Sisi Klien Minimal | Sangat Cocok | Berlebihan | Layak |
| Persyaratan Antarmuka Pengguna yang Kaya dan Kompleks | Terbatas | Sangat Cocok | Sangat Cocok |
Pertimbangan lain
Web Apps tradisional cenderung lebih sederhana dan memiliki kriteria Search Engine Optimization (SEO) yang lebih baik daripada aplikasi SPA. Bot mesin pencari dapat dengan mudah menggunakan konten dari aplikasi tradisional, sementara dukungan untuk pengindeksan SPAs mungkin kurang atau terbatas. Jika aplikasi Anda mendapat manfaat dari penemuan publik oleh mesin pencari, ini sering kali menjadi pertimbangan penting.
Selain itu, kecuali Anda telah membuat alat manajemen untuk konten SPA Anda, mungkin mengharuskan pengembang untuk membuat perubahan. Web Apps tradisional sering kali lebih mudah bagi non-pengembang untuk membuat perubahan, karena sebagian besar konten hanyaLAH HTML dan mungkin tidak memerlukan proses build untuk dipratinjau atau bahkan disebarkan. Jika non-pengembang di organisasi Anda cenderung perlu mempertahankan konten aplikasi, aplikasi web tradisional mungkin menjadi pilihan yang lebih baik.
SPAs bersinar ketika aplikasi memiliki bentuk interaktif yang kompleks atau fitur interaksi pengguna lainnya. Untuk aplikasi kompleks yang memerlukan autentikasi untuk digunakan, dan dengan demikian tidak dapat diakses oleh laba-laba mesin pencari publik, SPAs adalah opsi yang bagus dalam banyak kasus.
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk