Aplikasi Halaman Tunggal: kelebihan dan kekurangan [ditutup]


203

Saya sudah membaca tentang SPA dan itu keuntungan. Saya menemukan sebagian besar dari mereka tidak meyakinkan. Ada 3 keuntungan yang membangkitkan keraguan saya.

Pertanyaan: Bisakah Anda bertindak sebagai pembela SPA dan membuktikan bahwa saya salah tentang tiga pernyataan pertama?

                              === ADVANTAGES ===

1. SPA sangat baik untuk situs yang sangat responsif:

Render sisi server sulit diterapkan untuk semua status perantara - status tampilan kecil tidak memetakan dengan baik ke URL.

Aplikasi satu halaman dibedakan oleh kemampuannya untuk menggambar ulang bagian mana pun dari UI tanpa memerlukan bolak-balik server untuk mengambil HTML. Ini dicapai dengan memisahkan data dari penyajian data dengan memiliki lapisan model yang menangani data dan lapisan tampilan yang dibaca dari model.

Apa yang salah dengan memegang lapisan model untuk non-SPA? Apakah SPA satu-satunya arsitektur yang kompatibel dengan MVC di sisi klien?

2. Dengan SPA kita tidak perlu menggunakan permintaan tambahan ke server untuk mengunduh halaman.

Hah, dan berapa banyak halaman yang dapat diunduh pengguna selama mengunjungi situs Anda? Dua tiga? Sebaliknya muncul masalah keamanan lain dan Anda perlu memisahkan halaman login Anda, halaman admin dll menjadi halaman terpisah. Pada gilirannya itu bertentangan dengan arsitektur SPA.

3.Mungkin ada keuntungan lain? Jangan dengar hal lain ..

                            === DISADVANTAGES ===
  1. Klien harus mengaktifkan javascript.
  2. Hanya satu titik masuk ke situs.
  3. Keamanan.

PS Saya sudah bekerja di proyek SPA dan non-SPA. Dan saya mengajukan pertanyaan-pertanyaan itu karena saya perlu memperdalam pemahaman saya. Tidak bermaksud membahayakan pendukung SPA. Jangan tanya saya untuk membaca sedikit tentang SPA. Saya hanya ingin mendengar pertimbangan Anda tentang itu.


1
2. dan 3. bukan masalah.
Wiktor Zychla

1
Saya menyarankan bahwa alih-alih hanya membaca tentang SPA, Anda bisa menghabiskan waktu bermain dengan kerangka kerja yang sebenarnya seperti extjs. Waktu yang ada di sana akan terbayar dan Anda akan dapat menjawab pertanyaan Anda sendiri.
Wiktor Zychla

3
@WiktorZychla Saya bekerja pada proyek SPA. Saya menggunakan JQuery + Backbone. Saya juga telah menulis situs JSP. Saya tidak bisa menjawab pertanyaan-pertanyaan itu. Bisakah kamu?
VB_

3
@VolodymyrBakhmatiuk: itu tidak masalah, yang dapat dikompromikan oleh pengguna adalah gui bukan data karena data dijaga di sisi server.
Wiktor Zychla

4
Bagaimana jika pertanyaan ini didasarkan pada opini? Saya sering bertanya-tanya mengapa dan kapan saya harus menulis SPA? Akan sangat membantu jika SO memperbolehkan pertanyaan Pro dan Kontra
Anurag Awasthi

Jawaban:


144

Mari kita lihat salah satu situs SPA paling populer, GMail.

1. SPA sangat baik untuk situs yang sangat responsif:

Render sisi server tidak sesulit dulu dengan teknik sederhana seperti menyimpan # hash di URL, atau yang terbaru HTML5pushState . Dengan pendekatan ini, keadaan sebenarnya dari aplikasi web tertanam dalam URL halaman. Seperti di GMail setiap kali Anda membuka email, tag hash khusus ditambahkan ke URL. Jika disalin dan ditempelkan ke jendela browser lain dapat membuka email yang sama persis (asalkan mereka dapat mengotentikasi). Pendekatan ini memetakan langsung ke string kueri yang lebih tradisional, perbedaannya hanya pada eksekusi. Dengan HTML5 pushState () Anda dapat menghilangkan #hashdan menggunakan URL yang benar-benar klasik yang dapat diselesaikan pada server pada permintaan pertama dan kemudian memuat melalui ajax pada permintaan berikutnya.

2. Dengan SPA kita tidak perlu menggunakan permintaan tambahan ke server untuk mengunduh halaman.

Jumlah halaman yang diunduh pengguna selama kunjungan ke situs web saya ?? benar-benar berapa banyak surat yang dibaca ketika dia membuka akun suratnya. Saya membaca> 50 sekaligus. sekarang struktur surat hampir sama. jika Anda akan menggunakan skema rendering sisi server maka server akan merendernya pada setiap permintaan (kasus umum). - masalah keamanan - Anda harus / tidak boleh menyimpan halaman terpisah untuk admin / login yang sepenuhnya tergantung pada struktur situs Anda, ambil paytm.com misalnya juga membuat situs web SPA tidak berarti Anda membuka semua titik akhir untuk semua pengguna yang saya maksud, saya menggunakan formulir auth dengan situs web spa saya. - dalam kerangka SPA yang mungkin paling sering digunakan Angular JS, dev dapat memuat seluruh kuil html dari situs web sehingga dapat dilakukan tergantung pada tingkat otentikasi pengguna. pre loading html untuk semua jenis auth isn '

3. Mungkin ada keuntungan lain? Jangan dengar hal lain ..

  • hari ini Anda dapat dengan aman menganggap klien akan memiliki browser yang mengaktifkan javascript.
  • hanya satu titik masuk situs. Seperti yang saya sebutkan sebelumnya, pemeliharaan status dimungkinkan, Anda dapat memiliki sejumlah titik masuk seperti yang Anda inginkan, tetapi Anda harus memilikinya.
  • bahkan dalam pengguna SPA hanya melihat apa yang ia miliki hak yang tepat. Anda tidak harus menyuntikkan semuanya sekaligus. memuat template html berbeda dan javascript async juga merupakan bagian yang valid dari SPA.

Keuntungan yang bisa saya pikirkan adalah:

  1. rendering html jelas membutuhkan beberapa sumber daya sekarang setiap pengguna yang mengunjungi situs Anda melakukan ini. juga tidak hanya merender logika utama sekarang dilakukan sisi klien, bukan sisi server.
  2. masalah waktu tanggal - Saya hanya memberi waktu UTC klien adalah format yang ditetapkan sebelumnya dan bahkan tidak peduli dengan zona waktu yang saya biarkan javascript menanganinya. ini adalah keuntungan besar di mana saya harus menebak zona waktu berdasarkan lokasi yang berasal dari pengguna IP.
  3. bagi saya menyatakan lebih baik dikelola di SPA karena setelah Anda menetapkan variabel Anda tahu itu akan ada di sana. ini memberi kesan mengembangkan aplikasi daripada halaman web. ini sangat membantu dalam membuat situs seperti foodpanda, flipkart, amazon. karena jika Anda tidak menggunakan keadaan sisi klien Anda menggunakan sesi mahal.
  4. situs web pasti sangat responsif - Saya akan mengambil contoh ekstrim untuk ini mencoba membuat kalkulator di situs web non SPA (Saya tahu ini aneh).

Pembaruan dari Komentar

Sepertinya tidak ada yang menyebutkan tentang soket dan polling panjang. Jika Anda keluar dari klien lain mengatakan aplikasi seluler, maka browser Anda juga harus keluar. Jika Anda tidak menggunakan SPA, Anda harus membuat kembali koneksi soket setiap kali ada pengalihan. Ini juga harus bekerja dengan setiap pembaruan dalam data seperti pemberitahuan, pembaruan profil dll

Perspektif alternatif: Selain dari situs web Anda, apakah proyek Anda akan melibatkan aplikasi seluler asli? Jika ya, Anda kemungkinan besar akan memberi makan data mentah ke aplikasi asli dari server (yaitu JSON) dan melakukan pemrosesan sisi klien untuk merendernya, benar? Jadi dengan pernyataan ini, Anda SUDAH melakukan model rendering sisi klien. Sekarang pertanyaannya menjadi, mengapa Anda tidak harus menggunakan model yang sama untuk versi situs web proyek Anda? Agak no-brainer. Kemudian pertanyaannya adalah apakah Anda ingin membuat halaman sisi server hanya untuk manfaat SEO dan kenyamanan URL yang dapat dibagikan / bookmark


4
Baik untuk Anda karena membuat ini sebagai jawaban Wiki komunitas :) Ini juga poin bagus
Jason Sperske

@ Parv Sharma menjelaskan tolong secara lebih luas mengapa mempertahankan status lebih cocok dengan SPA?
VB_

4
Anda tidak dapat dengan mudah mengindeks halaman untuk optimasi SEO dengan SPA.
Ankit_Shah55

2
@ Ankit_Shah55 Ini mungkin tidak lagi benar (setidaknya untuk google, yang memiliki sebagian besar pangsa pasar mesin pencari). Lihat "Menghilangkan skema perayapan AJAX kami" dari Google. Pemahaman saya adalah bahwa Anda tidak perlu melakukan sesuatu yang istimewa bagi Google untuk mengindeks SPA Anda lagi. Saya pikir Anda perlu memastikan untuk mendukung pushstate, karena saya tidak berpikir fragmen hash indeks Google.
Kevin Wheeler

3
Sepertinya tidak ada yang menyebutkan tentang soket dan polling panjang. Jika Anda keluar dari klien lain mengatakan aplikasi seluler, maka browser Anda juga harus keluar. Jika Anda tidak menggunakan SPA, Anda harus membuat kembali koneksi soket setiap kali ada pengalihan. Ini juga harus bekerja dengan setiap pembaruan dalam data seperti pemberitahuan, pembaruan profil dll.
tsuz

66

Saya seorang pragmatis, jadi saya akan mencoba melihat ini dari segi biaya dan manfaat.

Perhatikan bahwa untuk setiap kerugian yang saya berikan, saya menyadari bahwa mereka dapat dipecahkan. Itu sebabnya saya tidak melihat apa pun sebagai hitam dan putih, melainkan biaya dan manfaat.

Keuntungan

  • Pelacakan status yang lebih mudah - tidak perlu menggunakan cookie, pengiriman formulir, penyimpanan lokal, penyimpanan sesi, dll. Untuk mengingat status di antara 2 pemuatan halaman.
  • Konten pelat ketel yang ada di setiap halaman (header, footer, logo, spanduk hak cipta, dll.) Hanya dimuat sekali per sesi browser tipikal.
  • Tidak ada latensi overhead saat pengalihan "halaman".

Kekurangan

  • Pemantauan kinerja - terikat tangan: Sebagian besar solusi pemantauan kinerja tingkat browser Saya telah melihat fokus secara eksklusif pada waktu pemuatan halaman saja, seperti waktu untuk byte pertama, waktu untuk membangun DOM, round-trip jaringan untuk HTML, acara yang memuat, dll. Memperbarui halaman post-load via AJAX tidak akan diukur. Ada solusi yang memungkinkan Anda instrumen kode Anda untuk merekam tindakan eksplisit, seperti ketika mengklik tautan, memulai penghitung waktu, lalu mengakhiri penghitung waktu setelah memberikan hasil AJAX, dan mengirimkan umpan balik itu. Relik Baru, misalnya, mendukung fungsi ini. Dengan menggunakan SPA, Anda telah mengikat diri Anda hanya dengan beberapa alat yang mungkin.
  • Pengujian keamanan / penetrasi - terikat tangan: Pemindaian keamanan otomatis dapat mengalami kesulitan menemukan tautan ketika seluruh halaman Anda dibangun secara dinamis oleh kerangka SPA. Mungkin ada solusi untuk ini, tetapi sekali lagi, Anda membatasi diri.
  • Bundling: Sangat mudah untuk masuk ke situasi ketika Anda mengunduh semua kode yang diperlukan untuk seluruh situs web pada pemuatan halaman awal, yang dapat melakukan sangat untuk koneksi bandwidth rendah. Anda dapat menggabungkan file JavaScript dan CSS Anda untuk mencoba memuat dalam potongan yang lebih alami saat Anda pergi, tetapi sekarang Anda perlu mempertahankan pemetaan itu dan menonton file yang tidak diinginkan untuk ditarik melalui dependensi yang tidak direalisasi (kebetulan saja pada saya). Sekali lagi, dipecahkan, tetapi dengan biaya.
  • Refactoring Big Bang: Jika Anda ingin membuat perubahan arsitektur besar, seperti katakanlah, beralih dari satu kerangka kerja ke kerangka kerja lainnya, untuk meminimalkan risiko, diinginkan untuk membuat perubahan tambahan. Yaitu, mulailah menggunakan yang baru, bermigrasi atas dasar tertentu, seperti per-halaman, per-fitur, dll., Lalu lepaskan yang lama setelahnya. Dengan aplikasi multi-halaman tradisional, Anda dapat beralih satu halaman dari Angular ke React, lalu beralih halaman lain di sprint berikutnya. Dengan SPA, semuanya atau tidak sama sekali. Jika Anda ingin mengubah, Anda harus mengubah seluruh aplikasi sekaligus.
  • Kompleksitas navigasi: Tooling ada untuk membantu mempertahankan konteks navigasi di SPA, seperti history.js, Angular 2, yang sebagian besar bergantung pada kerangka URL (#) atau API riwayat yang lebih baru. Jika setiap halaman adalah halaman terpisah, Anda tidak memerlukan semua itu.
  • Kompleksitas mencari tahu kode: Secara alami kami menganggap situs web sebagai halaman. Aplikasi multi-halaman biasanya mem-partisi kode per halaman, yang membantu pemeliharaan.

Sekali lagi, saya menyadari bahwa setiap masalah ini dapat dipecahkan, dengan biaya tertentu. Tapi ada titik di mana Anda menghabiskan semua waktu Anda memecahkan masalah yang Anda bisa hindari di tempat pertama. Itu kembali ke manfaat dan betapa pentingnya bagi Anda.


2
Saya pikir respons ini memberikan umpan balik yang sangat valid dari seseorang yang telah benar-benar membangun sistem kompleks besar dan mengalami korban jangka panjang yang dibawa oleh SPA (atau yang kelihatannya seperti itu)
DanielCuadra

4
Apa yang saya dapatkan dari jawaban ini adalah, hindari SPA jika Anda melakukan sesuatu yang bahkan jauh dari serius.
IvanP

Saya pikir Anda memberi kami ikhtisar yang sangat membantu, bukan hanya menjawab. Benar-benar pragmatis.
Hos Mercury

3
Saya setuju. SPA tampak hebat ketika kami melakukan pembuktian konsep. 3 tahun ke depan, kami telah melihat setiap masalah yang disebutkan dalam jawaban ini dan kami terus menghabiskan banyak waktu untuk mencoba menyelesaikannya. Perubahan kerangka kerja tidak lagi menjadi pilihan dan kami terjebak dengan kerangka kerja yang pada dasarnya menghentikan pengembangan.
Qi Fan

1
Saya telah mengalami 4 poin kerugian terakhir secara langsung. Saya telah membangun aplikasi web 10K LOC dengan Angular, Bootstrap & PHP sebagai pemain utama dengan sekitar 5K kode JS Angular. Ada beberapa fitur yang sangat rapi dari Angular tetapi pada titik ini saya benar-benar berharap saya baru saja menggunakan pendekatan berbasis halaman tradisional dan saya pikir itu akan secara signifikan mempercepat pengembangan situs.
Zack Macomber

41

Kekurangan

1. Klien harus mengaktifkan javascript. Ya, ini jelas kerugian SPA. Dalam kasus saya, saya tahu bahwa saya dapat mengharapkan pengguna saya mengaktifkan JavaScript. Jika Anda tidak bisa maka Anda tidak bisa melakukan SPA, titik. Itu seperti mencoba untuk menyebarkan aplikasi .NET ke mesin tanpa .NET Framework diinstal.

2. Hanya satu titik masuk ke situs. Saya mengatasi masalah ini menggunakan SammyJS . 2-3 hari kerja untuk mendapatkan pengaturan rute Anda dengan benar, dan orang-orang akan dapat membuat bookmark tautan-dalam ke aplikasi Anda yang bekerja dengan benar. Server Anda hanya perlu mengekspos satu titik akhir - titik akhir "beri saya HTML + CSS + JS untuk aplikasi ini" (anggap sebagai lokasi unduhan / perbarui untuk aplikasi yang dikompilasi) - dan JavaScript sisi klien yang Anda tulis akan menangani entri aktual ke dalam aplikasi.

3. Keamanan.Masalah ini tidak unik untuk SPA, Anda harus berurusan dengan keamanan dengan cara yang persis sama ketika Anda memiliki aplikasi server klien "sekolah lama" (model HATEOAS menggunakan Hypertext untuk menghubungkan antar halaman). Hanya saja pengguna membuat permintaan alih-alih JavaScript Anda, dan bahwa hasilnya dalam HTML daripada JSON atau beberapa format data. Di aplikasi non-SPA Anda harus mengamankan halaman individual di server, sedangkan di aplikasi SPA Anda harus mengamankan titik akhir data. (Dan, jika Anda tidak ingin klien Anda memiliki akses ke semua kode, maka Anda harus memecah JavaScript yang dapat diunduh menjadi area terpisah juga. Saya hanya mengikatnya ke dalam sistem perutean berbasis SammyJS saya sehingga browser hanya meminta hal-hal yang klien tahu harus memiliki akses, berdasarkan beban awal peran pengguna,

Keuntungan

  1. Keuntungan arsitektur utama dari SPA (yang jarang disebutkan) dalam banyak kasus adalah pengurangan besar dalam "chattiness" aplikasi Anda. Jika Anda mendesainnya dengan benar untuk menangani sebagian besar pemrosesan pada klien (intinya, bagaimanapun juga), maka jumlah permintaan ke server (baca "kemungkinan untuk 503 kesalahan yang merusak pengalaman pengguna Anda") berkurang secara dramatis. Bahkan, SPA memungkinkan untuk melakukan pemrosesan offline sepenuhnya, yang sangat besar dalam beberapa situasi.

  2. Kinerja tentu saja lebih baik dengan rendering sisi klien jika Anda melakukannya dengan benar, tetapi ini bukan alasan yang paling meyakinkan untuk membangun SPA. (Bagaimanapun juga, kecepatan jaringan meningkat.) Jangan membuat SPA hanya untuk kasus ini.

  3. Fleksibilitas dalam desain UI Anda mungkin merupakan keunggulan utama lain yang saya temukan. Setelah saya mendefinisikan API saya (dengan SDK dalam JavaScript), saya dapat sepenuhnya menulis ulang front-end saya dengan nol dampak pada server selain dari beberapa file sumber daya statis. Coba lakukan itu dengan aplikasi MVC tradisional! :) (Ini menjadi berharga ketika Anda memiliki penyebaran langsung dan konsistensi versi API Anda untuk dikhawatirkan.)

Jadi, intinya: Jika Anda memerlukan pemrosesan offline (atau setidaknya ingin klien Anda dapat bertahan hidup dari pemadaman server sesekali) - secara dramatis mengurangi biaya perangkat keras Anda sendiri - dan Anda dapat mengasumsikan JavaScript & browser modern, maka Anda memerlukan SPA. Dalam kasus lain, ini lebih merupakan tradeoff.


6
Keuntungan lain adalah SPA dapat disimpan sebagai bookmark ("Tambahkan ke layar awal") di iOS dan buka dalam mode layar penuh (dengan asumsi Anda telah menetapkan meta tag yang benar ), membuatnya terasa seperti aplikasi asli dan bukan aplikasi asli. halaman web.
Strille

7
3. Sama mudahnya dengan aplikasi MVC tradisional. Jika Anda beroperasi dengan data yang sama, Anda hanya perlu melakukan perubahan di bagian V (tampilan) aplikasi Anda. Ini biasanya templat, css dan js.
karantan

Dapatkah versi SPA dari SO memiliki tautan ke pertanyaan individu untuk dibagikan, atau kelebihan dan kekurangan apa yang akan dibawanya, misalnya dalam hal SEO (penelusuran pertanyaan sebelumnya dari mesin pencari).
Selçuk

5
Sebagian besar aplikasi SPA yang saya lihat lebih cerewet daripada aplikasi sisi server. Alih-alih satu permintaan untuk mendapatkan data Anda berakhir dengan lebih banyak permintaan ke server per halaman.
Matthew Whited

29

Salah satu kelemahan utama dari SPA - SEO. Hanya baru-baru ini Google dan Bing mulai mengindeks halaman berbasis Ajax dengan mengeksekusi JavaScript selama perayapan, dan masih dalam banyak kasus halaman diindeks dengan tidak benar.

Saat mengembangkan SPA, Anda akan dipaksa untuk menangani masalah SEO, mungkin dengan post-rendering semua situs Anda dan membuat snapshot html statis untuk penggunaan crawler. Ini akan membutuhkan investasi yang kuat dalam infrastruktur yang tepat.

Pembaruan 19.06.16:

Sejak menulis jawaban ini beberapa waktu yang lalu, saya mendapatkan lebih banyak pengalaman dengan Aplikasi Halaman Tunggal (yaitu, AngularJS 1.x) - jadi saya memiliki lebih banyak info untuk dibagikan.

Menurut pendapat saya, kelemahan utama dari aplikasi SPA adalah SEO, membuat mereka terbatas pada jenis aplikasi "dashboard" saja. Selain itu, Anda akan mengalami masa yang lebih sulit dengan caching, dibandingkan dengan solusi klasik. Sebagai contoh, dalam caching ASP.NET sangat mudah - cukup aktifkan OutputCaching dan Anda baik: seluruh halaman HTML akan di-cache sesuai dengan URL (atau parameter lainnya). Namun, di SPA Anda perlu menangani caching sendiri (dengan menggunakan beberapa solusi seperti cache level kedua, caching template, dll.).


Apakah SEO yang lebih baik untuk memiliki lalu lintas diteruskan ke satu halaman vs tersebar di beberapa halaman?
SILENT

@SILENT - tidak yakin, tetapi karena semua halaman di domain yang sama, saya tidak berpikir harus ada perbedaan
Illidan

Saya tidak mengerti argumen SEO. Tidak bisakah Anda hanya menentukan rute yang sama di SPA Anda juga mendefinisikan sisi server, jadi bot pencarian dapat dengan mudah merayapi situs Anda, dan pada saat yang sama orang mendapatkan URL langsung ke konten Anda. Jadi, Anda mungkin memiliki dua set templat untuk dikelola, masalah besar. Anda dapat mencoba menggunakan templating universal jika itu menjadi masalah.
MarsAndBack

@MarsAndBack: Tidak yakin tautan server mana yang Anda bicarakan. Jika yang Anda maksud sitemap - maka itu tidak berguna dalam kasus SPA: mesin pencari tidak menjalankan JavaScript (setidaknya, ini adalah keadaan beberapa tahun yang lalu), mereka hanya mengunduh dan mem-parsing HTML. Jadi, bahkan jika Anda menyiapkan peta situs - halaman tidak akan dikonstruksi dengan benar.
Illidan

12

Saya ingin menjadikan SPA yang terbaik untuk Aplikasi Berbasis Data. gmail, tentu saja semua tentang data dan dengan demikian kandidat yang baik untuk SPA.

Tetapi jika halaman Anda sebagian besar untuk tampilan, misalnya, halaman persyaratan layanan, maka SPA benar-benar berlebihan.

Saya pikir sweet spot memiliki situs dengan campuran halaman gaya SPA dan statis / MVC, tergantung pada halaman tertentu.

Misalnya, di satu situs yang saya bangun, pengguna mendarat di halaman indeks MVC standar. Tetapi kemudian ketika mereka pergi ke aplikasi yang sebenarnya, maka itu memanggil SPA. Keuntungan lain dari hal ini adalah bahwa waktu buka SPA tidak pada halaman beranda, tetapi pada halaman aplikasi. Waktu buka berada di beranda dapat menjadi gangguan bagi pengguna situs pertama kali.

Skenario ini sedikit seperti menggunakan Flash. Setelah beberapa tahun pengalaman, jumlah situs Flash saja turun mendekati nol karena faktor beban. Tetapi sebagai komponen halaman, masih digunakan.


1
setelah bertahun-tahun pengembangan web itulah yang bisa saya konfirmasi. Anda harus mencampur keduanya, aplikasi spa dan MVC bersama. Anda tidak dapat memiliki jawaban, juga tidak. Saya memiliki seluruh aplikasi saya sebagai spa terlebih dahulu, menemukan bahwa aplikasi saya tidak terdaftar oleh google dengan benar. jadi saya pindah ke mpa dan menggunakan spa hanya dalam situasi yang diperlukan. wordpress juga bukan spa dan kerangka kerja populer untuk alasan yang baik.
Rudolf Schmidt

1
Ini juga pendekatan saya. Saya memiliki SPA sebagai area utama bagi pengguna saya untuk dengan cepat menelusuri hasil pencarian baik itu di peta atau daftar dinamis. Kemudian ketika melihat detail, itu terbuka sebagai halaman standar yang diberikan server. Rute saya berfungsi baik di dalam SPA, dan sebagai rute server yang memuat pertama. Saya telah menduplikasi kode templat dan kode rute, tetapi saya tidak peduli, itu adalah kejahatan yang perlu.
MarsAndBack

8

Untuk perusahaan seperti google, amazon dll, yang servernya berjalan pada kapasitas maksimal dalam mode 24/7, mengurangi lalu lintas berarti uang nyata - lebih sedikit perangkat keras, lebih sedikit energi, lebih sedikit pemeliharaan. Menggeser penggunaan CPU dari server ke klien terbayar, dan SPA bersinar. Keuntungannya kelebihan berat badan sejauh ini. Jadi, SPA atau tidak SPA sangat tergantung pada use case.

Hanya untuk menyebutkan kasus penggunaan lain, mungkin tidak begitu jelas (untuk pengembang web) untuk SPA: Saat ini saya sedang mencari cara untuk mengimplementasikan GUI dalam sistem tertanam dan arsitektur berbasis browser tampaknya menarik bagi saya. Secara tradisional tidak ada banyak kemungkinan untuk UI dalam sistem embedded - Java, Qt, wx, dll atau kerangka kerja komersial yang wajar. Beberapa tahun yang lalu Adobe mencoba memasuki pasar dengan flash tetapi tampaknya tidak begitu berhasil.

Saat ini, karena "embedded system" sekuat mainframe beberapa tahun yang lalu, UI berbasis browser yang terhubung ke unit kontrol melalui REST adalah solusi yang memungkinkan. Keuntungannya adalah, palet besar alat untuk UI tanpa biaya. (mis. Qt membutuhkan $ 20-30 per unit terjual dengan biaya royalti ditambah $ 3000-4000 per pengembang)

Untuk arsitektur seperti itu SPA menawarkan banyak keuntungan - mis. Pendekatan pengembangan yang lebih akrab bagi pengembang aplikasi desktop, berkurangnya akses server (seringkali dalam industri mobil UI dan sistem muddle adalah perangkat keras yang terpisah, di mana bagian sistem memiliki RT OS).

Karena satu-satunya klien adalah browser bawaan, kerugian yang disebutkan seperti ketersediaan JS, logging sisi server, keamanan tidak dihitung lagi.


1
Amazon tidak terlalu khawatir tentang jumlah bandwidth atau permintaan. Setiap halaman sekitar 10MB dan lebih dari 200 permintaan.
Matthew Whited

3

2. Dengan SPA kita tidak perlu menggunakan permintaan tambahan ke server untuk mengunduh halaman.

Saya masih harus belajar banyak tetapi sejak saya mulai belajar tentang SPA, saya mencintai mereka.

Poin khusus ini dapat membuat perbedaan besar.

Di banyak aplikasi web yang bukan SPA, Anda akan melihat bahwa mereka masih akan mengambil dan menambahkan konten ke halaman yang membuat permintaan ajax. Jadi saya pikir SPA melampaui dengan mempertimbangkan: bagaimana jika konten yang akan diambil dan ditampilkan menggunakan ajax adalah seluruh halaman? dan bukan hanya sebagian kecil halaman?

Biarkan saya menyajikan skenario. Pertimbangkan bahwa Anda memiliki 2 halaman:

  1. halaman dengan daftar produk
  2. halaman untuk melihat detail produk tertentu

Pertimbangkan bahwa Anda berada di halaman daftar. Kemudian Anda mengklik suatu produk untuk melihat detailnya. Aplikasi sisi klien akan memicu 2 permintaan ajax:

  1. permintaan untuk mendapatkan objek json dengan detail produk
  2. permintaan untuk mendapatkan templat html tempat detail produk akan dimasukkan

Kemudian, aplikasi sisi klien akan memasukkan data ke templat html dan menampilkannya.

Kemudian Anda kembali ke daftar (tidak ada permintaan untuk ini!) Dan Anda membuka produk lain. Kali ini, hanya akan ada permintaan ajax untuk mendapatkan detail produk. Template html akan sama sehingga Anda tidak perlu mengunduh lagi.

Anda dapat mengatakan bahwa di SPA non, ketika Anda membuka detail produk, Anda hanya membuat 1 permintaan dan dalam skenario ini kami lakukan 2. Ya. Tetapi Anda mendapatkan keuntungan dari perspektif keseluruhan, ketika Anda menavigasi banyak halaman, jumlah permintaan akan lebih rendah. Dan data yang ditransfer antara sisi klien dan server akan lebih rendah juga karena template html akan digunakan kembali. Selain itu, Anda tidak perlu mengunduh semua permintaan css, gambar, file javascript di semua halaman dalam semua permintaan.

Juga, mari kita pertimbangkan bahwa bahasa sisi server Anda adalah Java. Jika Anda menganalisis 2 permintaan yang saya sebutkan, 1 unduhan data (Anda tidak perlu memuat file tampilan dan memanggil mesin rendering tampilan) dan unduhan lain serta templat html statis sehingga Anda dapat memiliki server web HTTP yang dapat mengambil secara langsung tanpa harus memanggil server aplikasi Java, tidak ada perhitungan yang dilakukan!

Akhirnya, perusahaan besar menggunakan SPA: Facebook, GMail, Amazon. Mereka tidak bermain, mereka memiliki insinyur terbaik yang mempelajari semua ini. Jadi, jika Anda tidak melihat kelebihannya, Anda bisa memercayai mereka pada awalnya dan berharap menemukan mereka di ujung jalan.

Tetapi penting untuk menggunakan pola desain SPA yang baik. Anda dapat menggunakan kerangka kerja seperti AngularJS. Jangan mencoba menerapkan SPA tanpa menggunakan pola desain yang bagus karena Anda mungkin akan mengalami kekacauan.


1
Facebook bukan SPA, sebenarnya ini adalah aplikasi gaya MPA, mereka menggunakan ReactJS di sana-sini untuk komentar, obrolan dll. Instagram adalah contoh yang baik untuk halaman SPA lengkap dengan PWA diaktifkan. Sama berlaku untuk Amazon, Youtube keduanya adalah aplikasi MPA.
Peter Húbek

3

Kekurangan : Secara teknis, desain dan pengembangan awal SPA adalah kompleks dan dapat dihindari. Alasan lain untuk tidak menggunakan SPA ini adalah:

  • a) Keamanan: Aplikasi Halaman Tunggal kurang aman dibandingkan dengan halaman tradisional karena skrip lintas situs (XSS).
  • b) Memory Leak: Kebocoran memori dalam JavaScript bahkan dapat menyebabkan Komputer yang kuat melambat. Sebagai situs web tradisional mendorong untuk bernavigasi di antara halaman, sehingga setiap kebocoran memori yang disebabkan oleh halaman sebelumnya hampir dibersihkan meninggalkan residu lebih sedikit.
  • c) Klien harus mengaktifkan JavaScript untuk menjalankan SPA, tetapi dalam aplikasi multi-halaman JavaScript dapat sepenuhnya dihindari.
  • d) SPA tumbuh ke ukuran optimal, menyebabkan waktu tunggu yang lama. Misalnya: Bekerja di Gmail dengan koneksi yang lebih lambat.

Selain di atas, batasan arsitektur lainnya adalah hilangnya Data Navigasi, Tidak ada log Riwayat Navigasi di browser dan kesulitan dalam Pengujian Fungsional Otomatis dengan selenium.

Tautan ini menjelaskan Kelebihan dan Kekurangan Aplikasi Satu Halaman.


12
Ini salah. a) XSS memengaruhi halaman yang dihasilkan server sama mudahnya dengan dokumen yang dihasilkan pada klien. Saya berpendapat lebih, mengingat bahwa ada solusi mitigasi XSS yang sangat sederhana dan efektif pada klien. Jika Anda tidak ingin mengizinkan XSS, jangan menafsirkan konten yang dikirimkan pengguna sebagai HTML. Setiap programmer yang baik dapat menangani ini. Navigasi mudah menggunakan salah satu teknik yang tersedia (pushState, hash routing, dll). AFT untuk SPA yang dibangun dengan benar persis sama dengan aplikasi web lainnya. Ringkasan jawaban Anda adalah bahwa Anda tidak tahu bagaimana membangun untuk klien.
Jason Miller

@JasonMiller: Setuju. Saya hanya menyadari bahwa ringkasan tidak semua konteks dari keseluruhan blog. Saya akan membuat perubahan di dalamnya. Terima kasih.
Vish

6
Poin a dan b sama sekali tidak valid. Keduanya lebih berkaitan dengan pemrograman yang buruk daripada karakteristik SPA, dan keduanya sangat mungkin dengan situs web tradisional; Kerentanan XSS dapat memengaruhi situs Anda, bahkan jika Anda tidak menulis sebaris JS. Kebocoran memori sama mungkin dengan sisi server dengan sisi klien. Adapun poin c, siapa pun yang menonaktifkan Javascript di hari ini dan usia cenderung menemukan menggunakan web pada umumnya masalah utama, ini adalah IMHO non-masalah.
garryp

2

Dalam perkembangan saya, saya menemukan dua keuntungan berbeda untuk menggunakan SPA. Itu bukan untuk mengatakan bahwa hal berikut ini tidak dapat dicapai dalam aplikasi web tradisional hanya karena saya melihat manfaat tambahan tanpa memperkenalkan kerugian tambahan.

  • Potensi untuk lebih sedikit permintaan server karena rendering konten baru tidak selalu atau bahkan permintaan server http untuk halaman html baru. Tapi saya katakan potensial karena konten baru bisa dengan mudah membutuhkan panggilan Ajax untuk menarik data tetapi data itu bisa lebih ringan daripada itu sendiri ditambah markup memberikan keuntungan bersih.

  • Kemampuan untuk mempertahankan "Negara". Dalam istilah yang paling sederhana, atur variabel saat masuk ke aplikasi dan itu akan tersedia untuk komponen lain di seluruh pengalaman pengguna tanpa meneruskannya atau mengaturnya ke pola penyimpanan lokal. Namun mengelola kemampuan ini secara cerdas adalah kunci untuk menjaga ruang lingkup tingkat atas tidak berantakan.

Selain meminta JS (yang bukan hal gila untuk memerlukan aplikasi web) Kerugian lain yang tercatat menurut saya adalah tidak spesifik untuk SPA atau dapat dikurangi melalui kebiasaan dan pola pengembangan yang baik.


1

Cobalah untuk tidak mempertimbangkan menggunakan SPA tanpa terlebih dahulu menentukan bagaimana Anda akan mengatasi keamanan dan stabilitas API di sisi server. Maka Anda akan melihat beberapa manfaat sebenarnya dari menggunakan SPA. Khususnya, jika Anda menggunakan server RESTful yang mengimplementasikan OAUTH 2.0 untuk keamanan, Anda akan mencapai dua pemisahan mendasar yang dapat menurunkan biaya pengembangan dan pemeliharaan Anda.

  1. Ini akan memindahkan sesi (dan ini keamanan) ke SPA dan membebaskan server Anda dari semua overhead itu.
  2. API Anda menjadi stabil dan mudah diperluas.

Diberitahu sebelumnya, tetapi tidak dibuat eksplisit; Jika tujuan Anda adalah menggunakan aplikasi Android & Apple, menulis JavaScript SPA yang dibungkus dengan panggilan asli untuk meng-host layar di browser (Android atau Apple) menghilangkan kebutuhan untuk mempertahankan basis kode Apple dan basis kode Android.


0

Saya mengerti ini adalah pertanyaan yang lebih lama, tetapi saya ingin menambahkan kelemahan lain dari Aplikasi Halaman Tunggal:

Jika Anda membuat API yang mengembalikan hasil dalam bahasa data (seperti XML atau JSON) alih-alih bahasa pemformatan (seperti HTML), Anda mengaktifkan interoperabilitas aplikasi yang lebih besar, misalnya, dalam aplikasi bisnis-ke-bisnis (B2B). Interoperabilitas semacam itu memiliki manfaat besar tetapi memungkinkan orang untuk menulis perangkat lunak untuk "menambang" (atau mencuri) data Anda. Kerugian khusus ini umum untuk semua API yang menggunakan bahasa data, dan tidak untuk SPA secara umum (memang, SPA yang meminta server untuk HTML yang telah diterjemahkan sebelumnya menghindari hal ini, tetapi dengan mengorbankan pemisahan model / tampilan yang buruk). Risiko ini terkena kerugian ini dapat dikurangi dengan berbagai cara, seperti pembatasan permintaan dan pemblokiran koneksi, dll.


2
1.) Tidak memiliki API tidak berarti bahwa halaman HTML tidak dapat ditambang. 2.) Anda dapat mencegah penyalahgunaan API Anda sampai batas tertentu. 3.) Dengan memiliki API, Anda dapat dengan mudah membangun tidak hanya halaman web, tetapi juga aplikasi seluler di atasnya, yang menurut saya jauh melebihi kerugiannya.
Honza Kalfus

1. Saya tidak mengatakan bahwa non-API mencegah penggalian data. Saya baru saja mengatakan bahwa API dapat membuat data mining lebih mudah. 2. Itulah yang dijawab oleh kalimat terakhir saya. 3. Ada banyak keuntungan memiliki API, dan saya pribadi lebih suka kombinasi API / SPA untuk sebagian besar kasus penggunaan yang biasanya saya temui. Namun, saya hanya ingin menambahkan satu kerugian pada daftar (yang jika saya renungkan seharusnya saya tambahkan sebagai komentar daripada jawaban yang lengkap).
Magnus

Maaf, tetapi jika saya belum salah paham, Anda tidak, Anda mengatakan bahwa "interoperabilitas semacam itu memiliki manfaat besar tetapi memungkinkan orang untuk menulis perangkat lunak untuk" menambang "(atau mencuri) data Anda.". Jika saya mengubah kalimat Anda sedikit, saya juga bisa mengatakan bahwa "Situs web memungkinkan orang menulis perangkat lunak untuk" menambang "(atau mencuri) data Anda." dan menjadi benar. Sekarang saya tidak mengatakan bahwa ide Anda salah, saya setuju dengan penambangan menjadi lebih mudah, saya hanya mengatakan bahwa itu bukan apa yang Anda tulis;)
Honza Kalfus

Sepakat. Itu tidak cukup jelas. Data yang tertanam dalam HTML dapat ditambang. Data yang disematkan dalam JSON / XML / etc juga dapat ditambang, hanya lebih mudah
magnus
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.