Panduan praktis pengambilan keputusan Blazor
Blazor: Server, WebAssembly, atau Hibrida?
Blazor berguna ketika Anda mengetahui karya mana yang tetap berada di server, karya mana yang dipindahkan ke browser, dan URL mana yang harus ada sebagai tautan HTML asli.
Panduan ini melewatkan versi brosur. Ini berfokus pada trade-off yang biasanya mengejutkan tim di kemudian hari: memori server, koneksi langsung, latensi, ukuran muatan, SEO, dan perutean multibahasa.
Sebelum pilihan mode render
Apa sebenarnya Blazor itu
Blazor adalah kerangka komponen Microsoft untuk aplikasi web .NET. Anda membangun UI dari komponen Razor, menulis sebagian besar logika interaksi dalam C#, dan membiarkan ASP.NET Core merender komponen tersebut di server, di WebAssembly, atau di dalam shell aplikasi asli.
Ini tumbuh dari ide-ide ASP.NET yang lebih tua. Formulir Web mencoba menyembunyikan web di belakang kontrol server. MVC dan Razor Pages menjadikan HTML respons permintaan lebih bersih. Blazor menambahkan komponen interaktif yang dapat digunakan kembali, namun tidak membuat MVC atau Razor Pages menjadi usang untuk halaman dan formulir konten sederhana.
Formulir Web, MVC, dan Halaman Razor memecahkan berbagai masalah Razor Pages
Formulir Web produktif namun berat dan berstatus tinggi. MVC dan Razor Pages memberikan HTML yang lebih bersih dan penanganan permintaan yang lebih sederhana. Mereka masih bagus ketika sebagian besar halaman membaca data, memposting formulir, dan mengembalikan HTML.
Komponen menjaga logika UI tetap dekat dengan markup
Komponen Razor dapat berisi markup, parameter, peristiwa, validasi, layanan yang disuntikkan, dan status lokal. Itu berguna untuk dasbor, editor, wizard, kisi, dan alat di mana halaman berubah tanpa memuat ulang sepenuhnya.
.NET modern memungkinkan Anda mencampur mode render
Aplikasi Blazor yang lebih baru dapat menggabungkan HTML statis yang dirender oleh server dengan komponen interaktif. Hal ini penting karena satu halaman mungkin memerlukan konten yang dapat dirayapi, sementara bagian lainnya memerlukan komponen aktif.
Daftar Isi
Mulai di sini
Versi singkat yang bermanfaat
Blazor bukanlah satu arsitektur. Ini adalah satu model komponen dengan beberapa mode render. Pilihan yang tepat tidak terlalu bergantung pada sintaksis dan lebih bergantung pada status, latensi, memori, dan tautan yang dapat dirayapi.
Blazor Server bersifat stateful
Ini bisa terasa cepat pada pemuatan pertama, tetapi server tetap menjaga sirkuit tetap hidup. Rencanakan memori, sambungkan kembali perilaku, dan perluas skala sebelum lalu lintas bertambah.
WebAssembly membayar di muka
Ini menghapus sirkuit server langsung, tetapi kunjungan pertama mengunduh runtime dan aplikasi. Masalah cache, pemangkasan, dan pra-perenderan.
Hibrida adalah keputusan produk
Gunakan Hybrid ketika aplikasi benar-benar membutuhkan desktop atau shell seluler. Untuk konten publik, gunakan rendering web dan URL asli.
Blazor Server
Blazor Server membuat pekerjaan tetap berjalan di antara klik
Blazor Server bukan halaman respons permintaan tanpa kewarganegaraan biasa. Tab browser yang terhubung mendapat sirkuit. Server menyimpan status komponen dan layanan tercakup untuk sirkuit tersebut saat pengguna terhubung, dan sering kali untuk jendela sambungan ulang singkat setelah pemutusan sambungan.
Memori tumbuh dengan sirkuit aktif
Setiap tab yang terhubung memiliki sirkuit. Status komponen, layanan tercakup, status validasi, dan pekerjaan UI yang tertunda dapat tetap tersimpan di memori hingga sirkuit berakhir. Uji beban harus menghitung pengguna aktif, bukan hanya permintaan per detik.
Latensi menjadi bagian dari UI
Klik tombol, peristiwa input, atau interaksi grid dapat berpindah ke server dan kembali. Selenggarakan acara yang dekat dengan pengguna dan hindari komponen yang cerewet ketika audiens tersebar di berbagai wilayah.
Perluasan skala memerlukan rencana
Beberapa instans aplikasi sering kali memerlukan sesi melekat, backplane SignalR, Layanan Azure SignalR, atau desain status yang cermat. Jika tidak, penyambungan kembali dan sirkuit hidup dapat mendarat di tempat yang salah.
Cocok: pengguna yang terkontrol
Blazor Server paling kuat untuk alat terotentikasi, layar admin, dasbor, dan aplikasi internal tempat pengguna, latensi, dan kapasitas hosting diketahui.
Blazor WebAssembly
WebAssembly memindahkan biaya ke pemuatan pertama
Blazor WebAssembly menghilangkan sirkuit server, namun tidak menghilangkan biaya. Browser harus mengunduh runtime .NET, rakitan, sumber daya lokalisasi, dan aset aplikasi sebelum pengalaman terasa cepat. Kunjungan berulang bisa menjadi hal yang baik karena cache membantu. Kunjungan pertama memerlukan perhatian.
Beban pertama adalah pajak
Browser mengunduh runtime .NET, rakitan aplikasi, sumber daya, dan aset statis. Pemangkasan membantu. Kompilasi sebelumnya dapat meningkatkan pekerjaan yang membebani CPU tetapi sering kali meningkatkan ukuran unduhan.
Rahasia tidak bisa hidup di dalam klien
Aplikasi WebAssembly berjalan di browser pengguna. Perlakukan seperti frontend publik lainnya: simpan rahasia di server, lindungi API, dan asumsikan kode klien dapat diperiksa.
SEO membutuhkan konten yang dirender
Untuk artikel publik, halaman produk, dan halaman arahan, jangan mengandalkan shell kosong yang hanya berguna setelah WebAssembly dimulai. Gunakan rendering sisi server, pra-render, rendering statis, atau jalur konten terpisah.
Cocok: aplikasi offline atau aplikasi yang banyak klien
WebAssembly berfungsi dengan baik ketika pengguna sering kembali, membutuhkan perilaku offline, atau melakukan pekerjaan berat di sisi klien di mana perjalanan pulang pergi server akan lebih buruk.
Hibrid dan Tampilan Web
Hibrid ditujukan untuk aplikasi, bukan untuk laman landas publik
Blazor Hybrid berguna ketika tim .NET ingin menggunakan kembali komponen di dalam aplikasi desktop atau seluler. Ini berjalan di shell asli melalui WebView, sehingga bisa dekat dengan file lokal, API perangkat, dan penerapan perusahaan. Ini bukan jalan pintas untuk situs web yang berfokus pada SEO.
- Gunakan Hibrid saat Anda memerlukan akses ke file lokal, API perangkat, penerapan desktop, atau kemasan seluler.
- Jangan memilih Hybrid hanya untuk menggunakan kembali komponen web. Shell asli menambahkan pekerjaan pembaruan, penyimpanan, penandatanganan, dan dukungan.
- Untuk SEO dan URL publik yang dapat dibagikan, Hybrid biasanya merupakan permukaan yang salah.
Perutean multibahasa
Tautan yang sadar budaya harus menjadi tautan yang nyata
Situs Blazor multibahasa tidak boleh membangun navigasi bahasa hanya di penangan klik atau JavaScript setelah halaman menjadi interaktif. Mesin pencari dan pengguna memerlukan tag jangkar nyata di HTML awal, dengan nilai href yang stabil, URL kanonik, dan data hreflang.
- Gunakan tautan halaman pusat dan pembantu alih-alih string buatan tangan seperti jalur tebas budaya garis miring.
- Render tautan bahasa sebagai tag jangkar dengan nilai href selama rendering HTML awal.
- Jaga agar URL kanonik, URL hreflang, dan navigasi bahasa terlihat tetap sinkron.
- Hindari menyembunyikan tautan penting di balik penangan onclick, JavaScript yang tertunda, atau status Blazor yang hanya interaktif.
Panduan keputusan
Pilih berdasarkan hambatan yang Anda terima
Setiap mode render memindahkan tekanan ke tempat yang berbeda. Pilih tekanan yang dapat Anda ukur, selenggarakan, dan jelaskan kepada tim.
Saat pemuatan pertama dan integrasi backend .NET paling penting
Pilih Blazor Server untuk aplikasi terautentikasi terkontrol yang mana memori server, koneksi langsung, dan latensi regional merupakan biaya pengoperasian yang dapat diterima.
Saat pekerjaan klien dan perilaku offline adalah hal yang paling penting
Pilih WebAssembly ketika kunjungan berulang, caching, penggunaan offline, atau pekerjaan CPU lokal lebih penting daripada pemuatan pertama yang terkecil.
Ketika produk tersebut benar-benar merupakan aplikasi asli
Pilih Hibrida jika aplikasi berada di desktop atau seluler dan lebih membutuhkan integrasi lokal daripada jangkauan web publik.
Ketika situs ini sebagian besar berisi dokumen dan formulir
ASP.NET Core MVC atau Razor Pages klasik seringkali lebih sederhana untuk situs dengan banyak konten, dokumentasi publik, dan formulir dengan interaktivitas terbatas.
Bagian referensi
Bacalah ini selanjutnya ketika Anda membangunnya secara nyata
Referensi ini berguna setelah keputusan arsitektur, karena mencakup bagian-bagian yang membuat halaman Blazor dapat diandalkan dalam produksi: metadata, link bahasa, hosting, dan UI yang dapat digunakan kembali.
Gunakan ini ketika setiap halaman memerlukan judul, deskripsi, Grafik Terbuka, kanonis, dan keluaran JSON-LD yang konsisten.
Tautan locale ramah SEOGunakan ini ketika perutean multibahasa memerlukan tautan nyata yang dapat dirayapi, jalur budaya yang stabil, dan keluaran hreflang yang benar.
Hosting Blazor di UpCloudGunakan ini ketika aplikasi Blazor Server memerlukan VPS kecil, Nginx, TLS, systemd, log, cadangan, dan penerapan berulang.
TablerForNetGunakan ini ketika nilainya adalah antarmuka admin, tabel data, formulir, dan layar dasbor, bukan halaman pemasaran.
BlazorGunakan hub Blazor bila Anda ingin panduan terkait ada di satu tempat sebelum memilih detail implementasi berikutnya.
Pertanyaan umum
Mengapa Blazor Server membutuhkan lebih banyak memori daripada MVC?
MVC dapat menyelesaikan permintaan dan melepaskan sebagian besar status permintaan. Blazor Server menyimpan sirkuit untuk setiap tab browser yang terhubung, sehingga status komponen dan layanan tercakup dapat tetap aktif di antara klik.
Bisakah saya menjalankan Blazor Server di beberapa aplikasi?
Ya, tapi rencanakan dengan sengaja. Sirkuit aktif dan koneksi SignalR memerlukan perutean yang stabil, layanan SignalR terkelola atau backplane, dan status aplikasi yang dapat bertahan saat tersambung kembali dengan benar.
Bisakah Blazor WebAssembly ramah SEO?
Ya, tapi tidak dengan mengirimkan cangkang kosong dan berharap crawler menunggu. Halaman publik memerlukan HTML yang dirender, metadata, tautan kanonis, dan data terstruktur sebelum atau selama respons pertama.
Bagaimana seharusnya tautan Blazor multibahasa dibuat?
Gunakan definisi rute pusat dan render tag jangkar nyata untuk setiap budaya. Jaga agar tautan yang terlihat, URL kanonik, dan data hreflang tetap selaras sehingga pengguna dan perayap melihat struktur bahasa yang sama.