Aplikacja jednostronicowa: zalety i wady [zamknięta]

Jestem pragmatykiem, więc postaram się spojrzeć na to w kategoriach kosztów i korzyści.

Zauważ, że za każdą wadę, którą podaję, uznaję, że są one rozwiązywalne. Dlatego nie patrzę na nic czarno-białego, ale raczej na koszty i korzyści.

Zalety

• łatwiejsze śledzenie stanu-nie ma potrzeby korzystania z plików cookie, przesyłania formularzy, przechowywania lokalnego, przechowywania sesji itp. aby zapamiętać stan pomiędzy 2 ładowaniami stron.
• zawartość płyty kotła, która jest na każda strona (Nagłówek, Stopka, logo, baner praw autorskich itp.) ładuje się tylko raz na typową sesję przeglądarki.
• brak opóźnień przy przełączaniu "stron".

Wady

• monitorowanie wydajności-hands tied: większość rozwiązań do monitorowania wydajności na poziomie przeglądarki, które widziałem, skupia się wyłącznie na czasie ładowania strony, jak czas na pierwszy bajt, czas na zbudowanie DOM, sieć round trip dla HTML, Zdarzenie onload, itp. Aktualizacja strony po załadowaniu przez AJAX nie należy mierzyć. Istnieją rozwiązania, które pozwalają instrument kodu do nagrywania jawnych środków, jak po kliknięciu łącza, uruchomić timer, a następnie zakończyć timer po renderowaniu wyników AJAX, i wysłać tę informację zwrotną. Na przykład New Relic obsługuje tę funkcjonalność. Korzystając ze SPA, przywiązałeś się tylko do kilku możliwych narzędzi.
• Security / penetration testing-hands tied: Automatyczne skanowanie zabezpieczeń może mieć trudności z wykrywaniem linków, gdy cała strona jest zbudowana dynamicznie przez ramy SPA. Prawdopodobnie są na to rozwiązania, ale znowu się ograniczyłeś.
• łączenie w Pakiety: łatwo jest znaleźć się w sytuacji, gdy pobierasz cały kod potrzebny dla całej witryny przy początkowym ładowaniu strony, co może działać okropnie w przypadku połączeń o niskiej przepustowości. Możesz spakować pliki JavaScript i CSS, aby próbować ładować je w bardziej naturalny sposób, ale teraz musisz zachować to mapowanie i uważać na niezamierzone pliki wciągnięty przez niezrealizowane zależności (właśnie mi się to przydarzyło). Ponownie, rozwiązywalne, ale z kosztami.
• Big bang refactoring: jeśli chcesz dokonać poważnej zmiany architektonicznej, jak np. przełączyć się z jednego frameworka na inny, aby zminimalizować ryzyko, pożądane jest wprowadzanie zmian przyrostowych. Oznacza to, że zacznij używać nowego, migruj na jakiejś podstawie, jak na stronę, na funkcję itp., potem porzuć stare. Dzięki tradycyjnej aplikacji wielostronicowej możesz przełączyć jedną stronę z Angular na React, a następnie przełączyć kolejna strona w następnym sprincie. Z SPA, wszystko albo nic. Jeśli chcesz zmienić, musisz zmienić całą aplikację za jednym zamachem.
[[9]}złożoność nawigacji: Narzędzia istnieją, aby pomóc w utrzymaniu kontekstu Nawigacyjnego w SPA, jak historia.js, Angular 2, z których większość opiera się na frameworku URL (#) lub nowszym interfejsie history API. Jeśli każda strona była osobną stroną, nie potrzebujesz żadnej z nich.
• złożoność wymyślania kodu: naturalnie myślimy o stronach internetowych jak o stronach. Aplikacja wielostronicowa zazwyczaj partycjonuje kod po stronie, co ułatwia konserwację.

Ponownie, zdaję sobie sprawę, że każdy z tych problemów jest rozwiązywalny, za pewną cenę. Ale przychodzi moment, w którym spędzasz cały swój czas na rozwiązywaniu problemów, których mogłeś po prostu uniknąć. To wraca do korzyści i jak ważne są one dla Ciebie.

Wady

1. Klient musi włączyć obsługę javascript. tak, jest to wyraźna wada SPA. W moim przypadku wiem, że mogę oczekiwać, że moi użytkownicy będą mieli włączoną obsługę JavaScript. Jeśli nie możesz to nie możesz zrobić SPA, kropka. To jak próba wdrożenia aplikacji. net na komputerze bez zainstalowanego. NET Framework.

2. Tylko jeden punkt wejścia na stronę. rozwiązuję ten problem używając SammyJS. 2-3 dni pracy, aby uzyskać routing prawidłowo skonfigurowany, a ludzie będą mogli tworzyć zakładki głębokiego łącza w aplikacji, które działają poprawnie. Twój serwer będzie musiał ujawnić tylko jeden punkt końcowy - punkt końcowy "give me the HTML + CSS + JS for this app" (pomyśl o tym jak o lokalizacji pobierania/aktualizacji dla wstępnie skompilowanej aplikacji) - a napisany po stronie klienta JavaScript obsłuży rzeczywisty wpis do aplikacji.

3. Ochrona. ten problem nie jest unikalny dla uzdrowisk, trzeba mieć do czynienia z bezpieczeństwem w dokładnie tak samo, gdy masz "oldschoolową" aplikację klient-serwer (model HATEOAS używania hipertekstu do łączenia stron). Chodzi o to, że Użytkownik składa żądania, a nie twój JavaScript, i że wyniki są w HTML, a nie JSON lub jakiś format danych. W aplikacji non-SPA musisz zabezpieczyć poszczególne strony na serwerze, podczas gdy w aplikacji SPA musisz zabezpieczyć punkty końcowe danych. (A jeśli nie chcesz, aby twój klient miał dostęp do całego kodu, musisz podziel pobrany JavaScript na osobne obszary. Po prostu przywiązuję to do mojego systemu routingu opartego na SammyJS, więc przeglądarka żąda tylko rzeczy, do których klient wie, że powinien mieć dostęp, na podstawie początkowego obciążenia ról użytkownika, a potem staje się to nie problemem.)

Zalety

1. Główną zaletą architektoniczną SPA (o której rzadko się wspomina) w wielu przypadkach jest ogromne zmniejszenie "chattiness" aplikacji. Jeśli go zaprojektujesz właściwie, aby obsłużyć większość przetwarzania na kliencie (w końcu cały punkt), liczba żądań do serwera (Czytaj "możliwości 503 błędów, które niszczą doświadczenie użytkownika") jest znacznie zmniejszona. W rzeczywistości SPA umożliwia całkowicie offline przetwarzania, który jest ogromny w niektórych sytuacjach.

2. Wydajność jest z pewnością lepsza przy renderowaniu po stronie klienta, jeśli zrobisz to dobrze, ale nie jest to najbardziej przekonujący powód, aby zbudować SPA. (Sieć w końcu Prędkość się poprawia.) Nie róbcie sprawy o SPA tylko na tej podstawie.

3. Elastyczność w projekcie interfejsu użytkownika jest być może inną główną zaletą, którą znalazłem. Po zdefiniowaniu mojego API (z SDK w JavaScript), byłem w stanie całkowicie przepisać mój front-end z zero wpływ na serwer oprócz niektórych statycznych plików zasobów. Spróbuj to zrobić za pomocą tradycyjnej aplikacji MVC! :) (Staje się to cenne, gdy masz wdrożenia na żywo i spójność wersji Twoje API, o które musisz się martwić.)

Podsumowując: jeśli potrzebujesz przetwarzania offline (lub przynajmniej chcesz, aby Twoi klienci mogli przetrwać sporadyczne przerwy w działaniu serwera) - radykalnie zmniejszając koszty własnego sprzętu - i możesz założyć JavaScript i nowoczesne przeglądarki, potrzebujesz SPA. W innych przypadkach jest to bardziej kompromis.

Jedną z głównych wad SPA-SEO. Dopiero niedawno Google i Bing zaczęły indeksować strony oparte na Ajaxie, wykonując JavaScript podczas indeksowania, a mimo to w wielu przypadkach strony są indeksowane nieprawidłowo.

Podczas tworzenia SPA, będziesz zmuszony do radzenia sobie z problemami SEO, prawdopodobnie przez renderowanie całej witryny i tworzenie statycznych migawek html do użytku crawlera. Będzie to wymagało solidnych inwestycji w odpowiednią infrastrukturę.

Aktualizacja 19.06.16:

Od napisania ta odpowiedź jakiś czas temu zdobywam znacznie więcej doświadczenia z aplikacjami Jednostronicowymi (mianowicie AngularJS 1.x) - więc mam więcej informacji do podzielenia.

Moim zdaniem główną wadą aplikacji SPA jest SEO, co ogranicza je tylko do aplikacji typu "dashboard". Ponadto będziesz miał znacznie trudniejsze czasy z buforowaniem, w porównaniu do klasycznych rozwiązań. Na przykład w ASP.NET buforowanie jest niezwykle łatwe - po prostu włącz OutputCaching i jesteś dobry: cała strona HTML będzie buforowana według adresu URL (lub innych parametrów). Jednak w SPA będziesz musiał samodzielnie obsługiwać buforowanie (używając niektórych rozwiązań, takich jak buforowanie drugiego poziomu, buforowanie szablonów itp..).

Chciałbym, aby SPA było najlepsze dla aplikacji opartych na danych. gmail, oczywiście chodzi o dane, a więc dobry kandydat na SPA.

Ale jeśli Twoja strona jest głównie do wyświetlania, na przykład strony Warunków świadczenia usług, to SPA jest całkowicie przesada.

Myślę, że sweet spot to posiadanie strony z mieszanką zarówno SPA, jak i statycznych stron w stylu MVC, w zależności od konkretnej strony.

Na przykład na jednej stronie, którą buduję, użytkownik ląduje na standardowa strona z indeksem MVC. Ale kiedy pójdą do właściwego wniosku, to zadzwoni do SPA. Kolejną zaletą jest to, że czas ładowania SPA nie jest na stronie głównej, ale na stronie aplikacji. Czas ładowania strony głównej może być rozproszeniem dla pierwszych użytkowników witryny.

Ten scenariusz jest trochę jak używanie Flasha. Po kilku latach doświadczenia liczba witryn Flash spadła do zera ze względu na współczynnik obciążenia. Ale jako komponent strony, jest nadal w użyciu.

Dla takich firm jak google, amazon itp., których serwery działają z maksymalną wydajnością w trybie 24/7, zmniejszenie ruchu oznacza prawdziwe pieniądze - mniej sprzętu, mniej energii, mniej konserwacji. Przenoszenie wykorzystania CPU z serwera na klienta opłaca się, a uzdrowiska świecą. Zalety nadwagi wady zdecydowanie. Tak więc SPA lub nie SPA zależy w dużej mierze od przypadku użycia.

Tylko za wzmiankę o innym, chyba nie tak oczywistym (dla Web-developerów) przypadku użycia Spa: Obecnie szukam sposobu na implementacja Gui w systemach wbudowanych i architekturze opartej na przeglądarce wydaje mi się atrakcyjna. Tradycyjnie nie było zbyt wielu możliwości Ui w systemach embedded-Java, Qt, WX, etc czy property commercial Framework. Kilka lat temu Adobe próbował wejść na rynek z Flashem, ale wydaje się, że nie jest tak udany.

Obecnie ,jako że "systemy wbudowane" są tak potężne jak mainframe kilka lat temu, możliwym rozwiązaniem jest interfejs użytkownika oparty na przeglądarce podłączony do jednostki sterującej za pośrednictwem REST. Na zaletą jest ogromna paleta narzędzi dla interfejsu użytkownika bez kosztów. Qt wymaga 20-30$ za sprzedaną jednostkę z opłat licencyjnych plus 3000-4000$ za dewelopera)

Dla takiej architektury SPA oferuje wiele zalet-np. bardziej znane podejście programistyczne dla programistów aplikacji desktopowych, ograniczony dostęp do serwera(często w przemyśle samochodowym interfejs użytkownika i błoto systemowe są oddzielnym sprzętem, gdzie część systemu ma RT OS).

Ponieważ jedynym klientem jest wbudowana przeglądarka, wymienione wady jak Js-dostępność, logowanie po stronie serwera, bezpieczeństwo już się nie liczy.

2. Dzięki SPA nie musimy używać dodatkowych zapytań do serwera, aby pobierać strony.

Muszę się jeszcze wiele nauczyć, ale odkąd zaczęłam uczyć się o SPA, uwielbiam je.

Ten konkretny punkt może zrobić ogromną różnicę.

W wielu aplikacjach internetowych, które nie są SPA, zobaczysz, że nadal będą pobierać i dodawać treści do stron składających żądania ajax. Myślę więc, że SPA wykracza poza to, rozważając: co jeśli zawartość, która zostanie pobrana i wyświetlona korzystanie z ajax jest cała strona? a nie tylko mała część strony?

Przedstawię scenariusz. Weź pod uwagę, że masz 2 Strony:

1. strona z listą produktów
2. strona do przeglądania szczegółów konkretnego produktu

Weź pod uwagę, że jesteś na stronie listy. Następnie kliknij produkt, aby wyświetlić szczegóły. Aplikacja po stronie klienta uruchomi 2 żądania ajax:

1. Prośba o uzyskanie obiektu json ze szczegółami produktu
2. a Prośba o uzyskanie szablonu html, w którym zostaną wstawione szczegóły produktu

Następnie aplikacja po stronie klienta wstawi dane do szablonu html i wyświetli je.

Następnie wróć do listy(nie ma prośby o to!) i otwierasz inny produkt. Tym razem będzie tylko żądanie ajax, aby uzyskać szczegóły produktu. Szablon html będzie taki sam, więc nie musisz ponownie pobierać.

Można powiedzieć, że w nie SPA, po otwarciu szczegóły produktu, składasz tylko 1 żądanie, a w tym scenariuszu zrobiliśmy 2. Tak. Ale zyskujesz z ogólnej perspektywy, gdy poruszasz się po wielu stronach, liczba żądań będzie niższa. A dane, które są przesyłane między Klientem a serwerem, będą również niższe, ponieważ szablony html będą ponownie używane. Ponadto nie musisz pobierać w każdym żądaniu wszystkich tych plików css, obrazów, javascript, które są obecne we wszystkich stron.

Załóżmy również, że językiem po stronie serwera jest Java. Jeśli przeanalizujesz 2 żądania, o których wspomniałem, 1 pobiera dane (nie musisz ładować żadnego pliku widoku i wywoływać silnika renderowania widoku) i inne pliki do pobrania i statyczny szablon html, dzięki czemu możesz mieć serwer WWW HTTP, który może pobrać go bezpośrednio bez konieczności wywoływania serwera aplikacji Java, żadne obliczenia nie są wykonywane!

Wreszcie, duże firmy korzystają z SPA: Facebook, GMail, Amazon. Oni nie Odtwórz: mają najlepszych inżynierów studiujących to wszystko. Jeśli więc nie widzisz zalet, możesz początkowo im zaufać i mieć nadzieję, że odkryjesz je po drodze.

Ale ważne jest, aby używać dobrych wzorców projektowych SPA. Możesz użyć frameworka takiego jak AngularJS. Nie próbuj wdrażać SPA bez korzystania z dobrych wzorców projektowych, ponieważ możesz skończyć się bałaganem.

Wady : Technicznie, projekt i wstępny rozwój SPA jest złożony i można go uniknąć. Inne powody Nie korzystania z tego SPA mogą być:

• A) BEZPIECZEŃSTWO: Aplikacja jednostronicowa jest mniej bezpieczna w porównaniu z tradycyjnymi stronami ze względu na cross Site scripting(XSS).
• b) wyciek pamięci: wyciek pamięci w JavaScript może nawet spowodować spowolnienie pracy potężnego komputera. Jak tradycyjne strony internetowe zachęcają do poruszania się między stronami, a więc każdy wyciek pamięci spowodowany przez poprzednią stronę jest prawie oczyszczony, pozostawiając mniej pozostałości.
• c) klient musi włączyć JavaScript, aby uruchomić SPA, ale w aplikacji wielostronicowej można całkowicie uniknąć JavaScript.
D) SPA rośnie do optymalnego rozmiaru, powoduje długi czas oczekiwania. Np: praca na Gmailu z wolniejszym połączeniem.

Oprócz powyższych, inne ograniczenia architektoniczne to utrata danych nawigacyjnych, brak logowania historii nawigacji w przeglądarce i trudności w automatycznym testowaniu funkcjonalności z selen.

Ten link wyjaśnia zalety i wady aplikacji Jednostronicowej.

Staraj się nie rozważać korzystania z SPA bez uprzedniego zdefiniowania, w jaki sposób zajmiesz się bezpieczeństwem i stabilnością API po stronie serwera. Wtedy zobaczysz niektóre z prawdziwych zalet korzystania z SPA. W szczególności, jeśli używasz serwera RESTful, który implementuje OAUTH 2.0 Dla bezpieczeństwa, osiągniesz dwa fundamentalne rozdzielenie problemów, które mogą obniżyć koszty rozwoju i konserwacji.

1. to przeniesie sesję (i jej bezpieczeństwo) na SPA i odciąży Twój serwer od wszystkich to nad głową.
2. twoje API stało się stabilne i łatwo rozszerzalne.

Rozumiem, że to starsze pytanie, ale chciałbym dodać jeszcze jedną wadę aplikacji jednostronicowych:

Jeśli tworzysz API, które zwraca wyniki w języku danych (takim jak XML lub JSON), a nie w języku formatowania (takim jak HTML), umożliwiasz większą interoperacyjność aplikacji, na przykład w aplikacjach business-to-business (B2B). Taka interoperacyjność ma ogromne korzyści, ale pozwala ludziom pisać oprogramowanie, aby "wydobywać" (lub kraść) Twoje dane. To szczególna wada jest wspólna dla wszystkich API, które używają języka danych, a nie dla Spa w ogóle (w rzeczywistości SPA, które prosi serwer o wstępnie renderowany HTML, unika tego, ale kosztem słabego oddzielenia modelu/widoku). Ryzyko to narażone na tę niekorzyść można złagodzić za pomocą różnych środków, takich jak ograniczanie żądań i blokowanie połączeń itp.

W moim rozwoju znalazłem dwie wyraźne zalety korzystania z SPA. To nie znaczy, że następujące nie można osiągnąć w tradycyjnej aplikacji internetowej tylko, że widzę przyrostowe korzyści bez wprowadzania dodatkowych wad.

• Możliwość mniejszej liczby żądań serwera, ponieważ renderowanie nowej zawartości nie zawsze lub nawet nigdy nie jest żądaniem serwera http dla nowej strony html. Ale mówię potencjalny, ponieważ nowa treść może łatwo wymagać wywołania Ajax, aby wyciągnąć dane, ale te dane może być stopniowo lżejszy niż sam Plus znaczniki zapewniające korzyści netto.

• Zdolność do utrzymania "stanu". Najprościej mówiąc, Ustaw zmienną przy wprowadzaniu do aplikacji, a będzie ona dostępna dla innych komponentów w całym środowisku użytkownika bez przekazywania jej lub ustawiania na lokalny wzorzec przechowywania. Inteligentne zarządzanie tą umiejętnością jest jednak kluczem do utrzymania najwyższego poziomu zakresu klarowności.

Inny niż wymagający JS (który nie jest crazy thing to require of web apps) inne zauważone wady są moim zdaniem albo nie specyficzne dla SPA lub można je złagodzić poprzez dobre nawyki i wzorce rozwojowe.