Tek Sayfalı Uygulama: avantajları ve dezavantajları [kapalı]

SPA'yı ve avantajlarını okudum. Onların çoğunu ikna edici bulmuyorum. Şüphelerimi uyandıran 3 avantaj var.

Soru: SPA'nın savunucusu olarak hareket edebilir ve ilk üç ifade konusunda yanıldığımı kanıtlayabilir misiniz?

                              === ADVANTAGES ===

1. SPA çok duyarlı siteler için son derece iyidir:

Sunucu tarafı oluşturma işleminin tüm ara durumlar için uygulanması zordur - küçük görünüm durumları URL'lerle iyi eşleşmez.

Tek sayfalık uygulamalar, HTML'yi almak için bir sunucu gidiş dönüşüne gerek kalmadan kullanıcı arayüzünün herhangi bir bölümünü yeniden çizebilmeleriyle ayırt edilir. Bu, verileri işleyen bir model katmanına ve modellerden okunan bir görünüm katmanına sahip olarak verilerin verilerin sunumundan ayrılmasıyla elde edilir.

SPA dışı bir model katmanı tutmanın nesi yanlış? SPA, istemci tarafında MVC ile uyumlu tek mimari midir?

2. SPA ile sayfaları indirmek için sunucuya fazladan sorgu kullanmamız gerekmez.

Hah ve sitenizi ziyaret ederken kullanıcı kaç sayfa indirebilir? İki üç? Bunun yerine başka bir güvenlik sorunu ortaya çıkıyor ve giriş sayfanızı, yönetici sayfanızı vb. Ayrı sayfalara ayırmanız gerekiyor. Buna karşılık SPA mimarisi ile çatışıyor.

3. başka avantajlar olabilir? Başka bir şey duyamıyorum ..

                            === DISADVANTAGES ===

1. İstemcinin javascript'i etkinleştirmesi gerekir.
2. Siteye yalnızca bir giriş noktası.
3. Güvenlik.

PS SPA ve SPA dışı projeler üzerinde çalıştım. Ve ben bu soruları soruyorum çünkü anlayışımı derinleştirmem gerekiyor. SPA taraftarlarına zarar vermek anlamına gelmez. SPA hakkında biraz daha okumamı istemeyin. Sadece bu konudaki düşüncelerinizi duymak istiyorum.

En popüler SPA sitelerinden biri olan GMail'e bakalım.

1. SPA çok duyarlı siteler için son derece iyidir:

Sunucu tarafı oluşturma, URL'de #hash veya daha yakın zamanda HTML5pushState tutmak gibi basit tekniklerle eskisi kadar zor değildir . Bu yaklaşımla web uygulamasının kesin durumu sayfa URL'sine gömülür. GMail'de olduğu gibi, her posta açtığınızda URL'ye özel bir karma etiketi eklenir. Kopyalanır ve başka bir tarayıcı penceresine yapıştırılırsa, tam olarak aynı postayı açabilir (kimlik doğrulama yapabilmeleri koşuluyla). Bu yaklaşım doğrudan daha geleneksel bir sorgu dizesiyle eşleşir, fark sadece yürütmededir. HTML5 pushState () #hashile, sunucuda ilk istekte çözülebilen ve daha sonra gelen isteklere ajax aracılığıyla yükleyebilen tamamen klasik URL'leri kaldırabilir ve kullanabilirsiniz.

2. SPA ile sayfaları indirmek için sunucuya fazladan sorgu kullanmamız gerekmez.

Kullanıcının web sitemi ziyareti sırasında indirdiği sayfa sayısı ?? gerçekten posta hesabını açtığında kaç kişinin okuduğunu gösterir. Tek seferde> 50 okudum. şimdi postaların yapısı neredeyse aynı. bir sunucu tarafı oluşturma şeması kullanırsanız, sunucu bunu her istekte (tipik durum) oluşturur. - güvenlik endişesi - tamamen sitenizin yapısına bağlı yöneticiler / giriş için ayrı sayfalar tutmak gerekir / örneğin paytm.com almak bir web sitesi SPA yapmak tüm için tüm uç noktaları açacağınız anlamına gelmez Kullanıcılar demek istedim spa web sitemle form kimlik doğrulaması kullanıyorum. - Muhtemelen en çok kullanılan SPA çerçevesinde Angular JS, dev, kullanıcıların kimlik doğrulama seviyesine bağlı olarak yapılabilmesi için web sitesinden tüm html tapınağını yükleyebilir. tüm yetkilendirme türleri için ön yükleme html isn '

3. Başka avantajlar olabilir mi? Başka bir şey duyamıyorum ..

• bu gün güvenli bir şekilde istemcinin javascript özellikli tarayıcılara sahip olacağını varsayabilirsiniz.
• sitenin yalnızca bir giriş noktası. Daha önce de belirttiğim gibi, durumun sürdürülmesi mümkündür, istediğiniz sayıda giriş noktasına sahip olabilirsiniz, ancak mutlaka bir tane olmalıdır.
• bir SPA kullanıcısında bile sadece uygun haklara sahip olduğunu görür. her şeyi aynı anda enjekte etmek zorunda değilsiniz. diff html şablonları ve javascript async yükleme de SPA'nın geçerli bir parçasıdır.

Düşünebileceğim avantajlar:

1. html oluşturma, sitenizi ziyaret eden her kullanıcı bunu yapıyor. Ayrıca artık sadece büyük mantık oluşturma değil sunucu tarafı yerine istemci tarafında yapılır.
2. tarih saat sorunları - Sadece istemciye UTC zaman önceden ayarlanmış bir biçim vermek ve ben bile javascript işlemek izin saat dilimleri umurumda değil. Bu, kullanıcıların IP'sinden türetilen konuma göre saat dilimlerini tahmin etmem gerektiğinde büyük bir avantaj.
3. bir kez bir değişken ayarladıktan sonra orada olacağını biliyorum çünkü bana devlet daha güzel bir SPA'da korunur. bu, web sayfası yerine uygulama geliştirme hissi verir. Bu genellikle foodpanda, flipkart, amazon gibi siteler yapımında çok yardımcı olur. çünkü istemci tarafı durumunu kullanmıyorsanız pahalı oturumlar kullanıyorsunuzdur.
4. web siteleri kesinlikle son derece duyarlı - Ben olmayan bir SPA web sitesi (onun garip biliyorum) bir hesap makinesi yapmak deneyin bu için aşırı bir örnek alacağım.

Yorumlardan Güncellemeler

Soketler ve uzun oylamalardan bahsetmiş gibi görünmüyor. Mobil uygulama diyelim başka bir istemciden çıkış yaparsanız, tarayıcınızın da oturumu kapatması gerekir. SPA kullanmıyorsanız, her yönlendirme olduğunda soket bağlantısını yeniden oluşturmanız gerekir. Bu ayrıca bildirimler, profil güncellemesi vb. Verilerdeki güncellemelerle de çalışmalıdır.

Alternatif bir bakış açısı: Web siteniz dışında projenizde yerel bir mobil uygulama yer alacak mı? Evetse, büyük olasılıkla bir sunucudan (JSON) o yerel uygulamaya ham veri besleyecek ve bunu oluşturmak için istemci tarafı işleme yapacaksınız, değil mi? Bu iddia ile, ZATEN istemci tarafında bir oluşturma modeli yapıyorsunuz. Şimdi soru, projenizin web sitesi sürümü için neden aynı modeli kullanmıyorsunuz? Biraz beyinsiz. Daha sonra soru, sunucu tarafı sayfalarını yalnızca SEO avantajları ve paylaşılabilir / yer imi eklenebilir URL'lerin kolaylığı için oluşturmak isteyip istemediğinize dönüşür

Ben bir pragmatistim, bu yüzden buna maliyetler ve faydalar açısından bakmaya çalışacağım.

Verdiğim herhangi bir dezavantaj için bunların çözülebilir olduklarının farkındayım. Bu yüzden hiçbir şeye siyah beyaz olarak bakmıyorum, aksine maliyetler ve faydalar görüyorum.

Avantajları

• Daha kolay durum izleme - 2 sayfa yükleme arasındaki durumu hatırlamak için çerezler, form gönderme, yerel depolama, oturum depolama vb. Kullanmaya gerek yoktur.
• Her sayfada bulunan kazan plakası içeriği (üstbilgi, altbilgi, logo, telif hakkı başlığı vb.) Her tipik tarayıcı oturumu için yalnızca bir kez yüklenir.
• "Sayfalar" arasında geçiş yaparken ek bir gecikme yaşanmaz.

Dezavantajları

• Performans izleme - bağlı eller: Gördüğüm çoğu tarayıcı düzeyi performans izleme çözümü, yalnızca ilk bayta kadar süre, DOM oluşturma süresi, HTML için ağ gidiş dönüşü, onload etkinliği vb. Gibi yalnızca sayfa yükleme süresine odaklanır. AJAX yoluyla yük sonrası ölçülmez. Bir bağlantıyı tıklamak, bir zamanlayıcı başlatmak, ardından AJAX sonuçlarını oluşturduktan sonra bir zamanlayıcıyı sonlandırmak ve bu geribildirimi göndermek gibi kodunuzu açık bir şekilde kaydetmek için cihazınızı kullanmanızı sağlayan çözümler vardır. Örneğin New Relic bu işlevi desteklemektedir. Bir SPA kullanarak, kendinizi sadece birkaç olası araca bağladınız.
• Güvenlik / sızma testi - bağlı eller: Otomatik güvenlik taramaları, sayfanızın tamamı bir SPA çerçevesi tarafından dinamik olarak oluşturulduğunda bağlantıları bulmakta güçlük çekebilir. Muhtemelen bunun çözümleri var, ama yine de kendinizi sınırladınız.
• Paketleme: İlk sayfa yüklemesinde tüm web sitesi için gerekli olan tüm kodu indirdiğinizde, düşük bant genişlikli bağlantılar için korkunç performans gösterebilecek bir duruma girmek kolaydır. JavaScript ve CSS dosyalarınızı gittikçe daha doğal yığınlara yüklemeye çalışmak için paketleyebilirsiniz, ancak şimdi bu eşleştirmeyi sürdürmeniz ve gerçekleşmemiş bağımlılıklar yoluyla (sadece başıma geldi) istenmeyen dosyalara dikkat etmeniz gerekir. Yine, çözülebilir, ancak bir maliyetle.
• Büyük patlama yeniden düzenleme: Riski en aza indirmek için büyük bir mimari değişiklik yapmak istiyorsanız, örneğin bir çerçeveden diğerine geçmek istiyorsanız, artımlı değişiklikler yapmak istenir. Yani, yeni kullanmaya başlayın, sayfa başına, özellik başına vb.Gibi bir şekilde taşıyın, sonra eski olanı bırakın. Geleneksel çok sayfalı uygulama ile, bir sayfayı Angular'dan React'a ve ardından bir sonraki sprint'te başka bir sayfaya geçebilirsiniz. Bir SPA ile, hepsi ya da hiçbir şey. Değiştirmek isterseniz, tek seferde tüm uygulamayı değiştirmeniz gerekir.
• Gezinmenin karmaşıklığı: Geçmiş URL'leri, Angular 2 gibi SPA'larda gezinme bağlamının korunmasına yardımcı olan araçlar, çoğu URL çerçevesine (#) veya daha yeni geçmiş API'sine dayanır. Her sayfa ayrı bir sayfaysa, bunlardan herhangi birine ihtiyacınız yoktur.
• Kod çözmenin karmaşıklığı: Doğal olarak web sitelerini sayfa olarak düşünüyoruz. Çok sayfalı bir uygulama genellikle kodu sayfalara göre bölümlere ayırır ve bu da sürdürülebilirliğe yardımcı olur.

Yine, bu sorunların her birinin bir maliyetle çözülebileceğini kabul ediyorum. Ama ilk etapta kaçınabileceğiniz sorunları çözmek için tüm zamanınızı harcadığınız bir nokta var. Avantajlar ve sizin için ne kadar önemli oldukları ile ilgili.

Dezavantajları

1. İstemci javascript'i etkinleştirmelidir. Evet, bu SPA'nın açık bir dezavantajıdır. Benim durumumda, kullanıcılarımın JavaScript'in etkin olmasını bekleyebileceğimi biliyorum. Eğer yapamazsan, SPA yapamazsın, nokta. Bu, .NET Framework yüklü olmayan bir makineye bir .NET uygulaması dağıtmaya çalışmak gibidir.

2. Siteye yalnızca bir giriş noktası. Bu sorunu SammyJS kullanarak çözüyorum . Yönlendirmenizi düzgün bir şekilde ayarlamak için 2-3 günlük bir çalışma ve kullanıcılar uygulamanızda düzgün çalışan derin bağlantı yer imleri oluşturabilir. Sunucunuzun yalnızca bir uç noktayı açması gerekir - "bana bu uygulama için HTML + CSS + JS ver" uç noktası (önceden derlenmiş bir uygulama için indirme / güncelleme konumu olarak düşünün) - ve yazdığınız istemci tarafı JavaScript uygulamaya gerçek girişi işlemek.

3. Güvenlik.Bu sorun SPA'lara özgü değildir, bir "eski okul" istemci-sunucu uygulamanız (sayfalar arasında bağlantı oluşturmak için Köprü Metni kullanma HATEOAS modeli) olduğunda güvenlikle tamamen aynı şekilde ilgilenmeniz gerekir. Sadece kullanıcı JavaScript'iniz yerine istekleri yapıyor ve sonuçlar JSON veya bazı veri formatları yerine HTML biçiminde. SPA olmayan bir uygulamada, sunucudaki tek tek sayfaları korumanız gerekirken, bir SPA uygulamasında veri uç noktalarını güvenli hale getirmeniz gerekir. (Ve müşterinizin tüm kodlara erişmesini istemiyorsanız, indirilebilir JavaScript'i ayrı alanlara ayırmanız gerekir. Bunu sadece SammyJS tabanlı yönlendirme sistemime bağlarım, böylece tarayıcı sadece isterse kullanıcının rollerinin başlangıçtaki yüküne dayanarak, müşterinin erişimi olması gerektiğini bildiği şeyler,

Avantajları

1. Birçok durumda bir SPA'nın (nadiren bahsedilir) önemli bir mimari avantajı, uygulamanızın "konuşkanlığındaki" büyük azalmadır. İstemcideki çoğu işlemi (sonuçta tüm nokta) işlemek için düzgün bir şekilde tasarlarsanız, sunucuya yapılan isteklerin sayısı ("kullanıcı deneyiminizi bozan 503 hata olasılıklarını okuyun") önemli ölçüde azalır. Aslında, bir SPA bazı durumlarda çok büyük olan tamamen çevrimdışı işlemeyi mümkün kılar .

2. Doğru yaparsanız performans, istemci tarafı oluşturma ile kesinlikle daha iyidir, ancak bu bir SPA oluşturmak için en zorlayıcı neden değildir. (Sonuçta ağ hızları artıyor.) SPA'yı sadece bu temelde yapmayın.

3. UI tasarımınızdaki esneklik belki de bulduğum diğer önemli avantaj. API'mı tanımladıktan sonra (JavaScript'te bir SDK ile), bazı statik kaynak dosyalarının yanı sıra sunucu üzerinde sıfır etkisi olacak şekilde ön ucumu tamamen yeniden yazabildim . Bunu geleneksel bir MVC uygulamasıyla yapmayı deneyin! :) (API'nızın endişelenecek canlı dağıtımları ve sürüm tutarlılığı olduğunda bu değer kazanır.)

Yani, sonuç olarak: Çevrimdışı işlemeye ihtiyacınız varsa (veya en azından müşterilerinizin zaman zaman sunucu kesintilerinden kurtulmasını istiyorsanız) - kendi donanım maliyetlerinizi önemli ölçüde azaltırsanız ve JavaScript ve modern tarayıcıları varsayabilirsiniz, o zaman bir SPA'ya ihtiyacınız vardır. Diğer durumlarda daha çok bir ödünleşmedir.

SPA'nın büyük bir dezavantajı - SEO. Sadece son zamanlarda Google ve Bing, tarama sırasında JavaScript'i çalıştırarak Ajax tabanlı sayfaları dizine eklemeye başladı ve yine de çoğu durumda sayfalar yanlış dizine ekleniyor.

SPA geliştirirken, muhtemelen tüm sitenizi post-render ederek ve tarayıcının kullanımı için statik html anlık görüntüleri oluşturarak SEO sorunlarını ele almak zorunda kalacaksınız. Bu, uygun altyapılara sağlam bir yatırım gerektirecektir.

Güncelleme 19.06.16:

Bu yanıtı bir süre önce yazdığından beri, Tek Sayfa Uygulamaları (AngularJS 1.x) ile çok daha fazla deneyim kazanıyorum - bu yüzden paylaşmak için daha fazla bilgiye sahibim.

Bence, SPA uygulamalarının ana dezavantajı SEO'dur ve onları sadece "gösterge paneli" uygulamalarıyla sınırlandırmaktadır. Buna ek olarak, klasik çözümlere kıyasla önbellekleme ile çok daha zor zamanlar geçireceksiniz. Örneğin, ASP.NET'te önbelleğe alma işlemi son derece kolaydır - yalnızca OutputCaching'i açın ve iyisiniz: HTML sayfasının tamamı URL'ye (veya diğer parametrelere) göre önbelleğe alınır. Ancak, SPA'da önbelleğe almanız gerekir (ikinci düzey önbellek, şablon önbellekleme vb. Gibi bazı çözümler kullanarak).

Veriye Dayalı Uygulamalar için SPA'nın en iyi durumda olmasını istiyorum. gmail, elbette tüm verilerle ilgilidir ve bu nedenle bir SPA için iyi bir adaydır.

Ancak sayfanız çoğunlukla örneğin bir hizmet şartları sayfası görüntülemek içinse, bir SPA tamamen aşırıya kaçar.

Ben tatlı nokta belirli bir sayfaya bağlı olarak, hem SPA hem de statik / MVC tarzı sayfaların karışımı olan bir site sahip olduğunu düşünüyorum.

Örneğin, inşa ettiğim bir sitede, kullanıcı standart bir MVC dizin sayfasına ulaşır. Ama sonra gerçek uygulamaya gittiklerinde, SPA'yı çağırır. Bunun bir diğer avantajı, SPA'nın yükleme süresinin ana sayfada değil, uygulama sayfasında olmasıdır. Ana sayfada yer alan yükleme süresi, ilk kez site kullanıcılarının dikkatini dağıtabilir.

Bu senaryo biraz Flash kullanmaya benzer. Birkaç yıllık deneyimden sonra, yalnızca Flash sitelerinin sayısı yük faktörü nedeniyle sıfıra yaklaştı. Ancak bir sayfa bileşeni olarak, hala kullanımdadır.

Sunucuları 7/24 modda maksimum kapasitede çalışan google, amazon vb. Şirketler için, trafiği azaltmak gerçek para demektir - daha az donanım, daha az enerji, daha az bakım. CPU kullanımını sunucudan istemciye kaydırmak işe yarar ve SPA'lar parlar. Avantajları aşırı kilolu dezavantajları. Bu nedenle, SPA veya SPA değil, büyük ölçüde kullanım durumuna bağlıdır.

Sadece SPA'lar için muhtemelen çok açık olmayan (Web geliştiricileri için) bir kullanım örneğinden bahsetmek için: Şu anda gömülü sistemlerde GUI'leri uygulamak için bir yol arıyorum ve tarayıcı tabanlı mimari bana çekici geliyor. Geleneksel olarak gömülü sistemlerde UI'ler için pek fazla olasılık yoktu - Java, Qt, wx, vb. Veya uygun ticari çerçeveler. Birkaç yıl önce Adobe pazara flaşla girmeye çalıştı, ancak o kadar başarılı görünmüyor.

Günümüzde, "gömülü sistemler" birkaç yıl önce ana bilgisayarlar kadar güçlü olduğu için, REST aracılığıyla kontrol ünitesine bağlı tarayıcı tabanlı bir UI olası bir çözümdür. Avantajı, UI için ücretsiz bir araç paleti. (örn. Qt, telif ücreti üzerinden satılan birim başına 20-30 $ artı geliştirici başına 3000-4000 $ gerektirir)

Böyle bir mimari için SPA birçok avantaj sunar - örneğin, masaüstü uygulaması geliştiricileri için daha tanıdık geliştirme yaklaşımı, azaltılmış sunucu erişimi (genellikle araba endüstrisinde UI ve sistem karışıklıkları, sistem bölümünün bir RT OS'ye sahip olduğu ayrı bir donanımdır).

Tek istemci yerleşik tarayıcı olduğundan, JS kullanılabilirliği, sunucu tarafı günlük kaydı, güvenlik gibi bahsedilen dezavantajlar artık sayılmamaktadır.

2. SPA ile sayfaları indirmek için sunucuya fazladan sorgu kullanmamız gerekmez.

Hala çok şey öğrenmem gerekiyor ama SPA'yı öğrenmeye başladığımdan beri onları seviyorum.

Bu özel nokta büyük bir fark yaratabilir.

SPA olmayan birçok web uygulamasında, yine de ajax istekleri yapan sayfalara içerik ekleyeceklerini ve içerik ekleyeceklerini göreceksiniz. Bu yüzden SPA'nın düşünerek ötesine geçtiğini düşünüyorum: Ya ajax kullanılarak alınacak ve görüntülenecek içerik tüm sayfa ise? ve sayfanın sadece küçük bir kısmı değil?

Bir senaryo sunayım. 2 sayfanız olduğunu düşünün:

1. ürün listesini içeren bir sayfa
2. belirli bir ürünün ayrıntılarını görüntülemek için bir sayfa

Liste sayfasında olduğunuzu düşünün. Ardından ayrıntıları görüntülemek için bir ürünü tıklarsınız. İstemci tarafı uygulaması 2 ajax isteğini tetikleyecektir:

1. ürün detayları ile bir json nesnesi alma isteği
2. ürün ayrıntılarının ekleneceği bir html şablonu alma isteği

Ardından, istemci tarafı uygulaması verileri html şablonuna ekler ve görüntüler.

Sonra listeye geri dönersiniz (bunun için herhangi bir talep yapılmaz!) Ve başka bir ürün açarsınız. Bu kez, ürünün ayrıntılarını almak için sadece bir ajax isteği olacak. Html şablonu aynı olacak, bu yüzden tekrar indirmenize gerek yok.

SPA olmayan bir ortamda, ürün ayrıntılarını açtığınızda yalnızca 1 istekte bulunduğunuzu ve bu senaryoda 2 yaptığımızı söyleyebilirsiniz. Evet. Ancak kazancı genel bir perspektiften elde edersiniz, birçok sayfada gezindiğinizde, istek sayısı daha düşük olacaktır. Ve html şablonları yeniden kullanılacağı için istemci tarafı ile sunucu arasında aktarılan veriler de daha düşük olacaktır. Ayrıca, tüm isteklerde tüm sayfalarda bulunan tüm bu css, resimler, javascript dosyalarını indirmenize gerek yoktur.

Ayrıca, sunucu tarafı dilinizin Java olduğunu düşünelim. Bahsettiğim 2 isteği analiz ederseniz, 1 veri indirir (herhangi bir görünüm dosyasını yüklemenize ve görünüm oluşturma motorunu çağırmanıza gerek yoktur) ve diğer indirmeler ve statik html şablonu, böylece alabileceğiniz bir HTTP web sunucusuna sahip olabilirsiniz Java uygulama sunucusunu aramak zorunda kalmadan, hiçbir hesaplama yapılmaz!

Son olarak, büyük şirketler SPA kullanıyor: Facebook, GMail, Amazon. Oynamıyorlar, tüm bunları inceleyen en büyük mühendislere sahipler. Avantajları görmüyorsanız, başlangıçta onlara güvenebilir ve onları yolda keşfetmeyi umabilirsiniz.

Ancak iyi SPA tasarım desenleri kullanmak önemlidir. AngularJS gibi bir çerçeve kullanabilirsiniz. İyi tasarım desenleri kullanmadan bir SPA uygulamaya çalışmayın çünkü bir karışıklık yaşayabilirsiniz.

Dezavantajları : Teknik olarak, SPA'nın tasarımı ve ilk gelişimi karmaşıktır ve önlenebilir. Bu SPA'yı kullanmamanın diğer nedenleri şunlar olabilir:

• a) Güvenlik: Siteler arası komut dosyası oluşturma (XSS) nedeniyle tek sayfa uygulaması geleneksel sayfalara göre daha az güvenlidir.
• b) Bellek Sızıntısı: JavaScript'te bellek sızıntısı, güçlü Bilgisayarın yavaşlamasına bile neden olabilir. Geleneksel web siteleri sayfalar arasında gezinmeyi teşvik ettiğinden, önceki sayfanın neden olduğu bellek sızıntısı neredeyse temizlenir ve geride daha az kalıntı kalır.
• c) İstemci, SPA'yı çalıştırmak için JavaScript'i etkinleştirmelidir, ancak çok sayfalı uygulamada JavaScript'ten tamamen kaçınılabilir.
• d) SPA optimum boyuta büyür, uzun bekleme süresine neden olur. Örneğin: Daha yavaş bağlantı ile Gmail üzerinde çalışma.

Yukarıdakilerin dışında, diğer mimari sınırlamalar Navigasyon Veri kaybı, Tarayıcıda Navigasyon Geçmişi kaydı yok ve selenyum ile Otomatik Fonksiyonel Testte zorluktur.

Bu bağlantı Tek Sayfa Uygulamasının Avantaj ve Dezavantajlarını açıklar.

Gelişimimde SPA kullanmak için iki ayrı avantaj buldum. Bu, geleneksel bir web uygulamasında aşağıdakilerin gerçekleştirilemeyeceği anlamına gelmiyor, sadece ek dezavantajlar getirmeden artan fayda görüyorum.

• Yeni içerik oluşturma nedeniyle daha az sunucu isteği potansiyeli, yeni bir html sayfası için her zaman veya hatta bir http sunucusu talebi değildir. Ancak potansiyel diyorum çünkü yeni içerik veri çekmek için kolayca bir Ajax çağrısı gerektirebilir, ancak bu veriler kendisinden ve net bir fayda sağlayan biçimlendirmeden aşamalı olarak daha hafif olabilir.

• “Devlet” i sürdürme yeteneği. En basit ifadeyle, uygulamaya girişte bir değişken ayarlayın ve kullanıcının deneyimi boyunca diğer bileşenler tarafından geçmeden veya yerel bir depolama düzenine ayarlanmadan kullanılabilir. Bununla birlikte, bu yeteneği akıllıca yönetmek, üst düzey kapsamı düzenli tutmak için anahtardır.

JS (web uygulamalarının gerektirdiği çılgın bir şey değildir) dışında, dikkat çeken diğer dezavantajlar bence SPA'ya özgü değildir veya iyi alışkanlıklar ve geliştirme kalıpları ile hafifletilebilir.

Önce sunucu tarafında güvenlik ve API kararlılığını nasıl ele alacağınızı tanımlamadan bir SPA kullanmayı düşünmemeye çalışın. O zaman bir SPA kullanmanın gerçek avantajlarından bazılarını göreceksiniz. Özellikle, güvenlik için OAUTH 2.0'ı uygulayan bir RESTful sunucusu kullanıyorsanız, geliştirme ve bakım maliyetlerinizi düşürebilen endişelerin iki temel ayrımını elde edersiniz.

1. Bu, oturumu (ve güvenliğini) SPA'ya taşıyacak ve sunucunuzu tüm bu yükten kurtaracaktır.
2. API'leriniz hem kararlı hem de kolayca genişletilebilir hale gelir.

Daha önce ima etti, ancak açık değildi; Amacınız Android ve Apple uygulamalarını dağıtmaksa, ekranı bir tarayıcıda (Android veya Apple) barındırmak için yerel bir çağrı ile sarılmış bir JavaScript SPA yazmak, hem Apple kod tabanını hem de Android kod tabanını koruma ihtiyacını ortadan kaldırır.

Bunun daha eski bir soru olduğunu anlıyorum, ancak Tek Sayfa Uygulamalarının başka bir dezavantajını da eklemek istiyorum:

Sonuçları biçimlendirme dili yerine (HTML gibi) bir veri dilinde (XML veya JSON gibi) döndüren bir API oluşturursanız, örneğin işletmeler arası (B2B) uygulamalarda daha fazla uygulama birlikte çalışabilirliği sağlarsınız. Bu birlikte çalışabilirliğin büyük faydaları vardır, ancak kişilerin verilerinizi "benimsemesi" (veya çalması) için yazılım yazmasına izin verir. Bu dezavantaj, genel olarak SPA'lar için değil, bir veri dili kullanan tüm API'lar için ortaktır (aslında, sunucudan önceden oluşturulmuş HTML'yi isteyen bir SPA bunu önler, ancak zayıf model / görünüm ayrımı pahasına). Bu dezavantajın maruz kaldığı bu risk, talep sınırlama ve bağlantı engelleme gibi çeşitli yollarla hafifletilebilir.