Jakie zalety daje renderowanie strony po stronie serwera?

19

Tworzę aplikację internetową i obecnie napisałem całą witrynę w html / js / css, a na zapleczu mam serwlety obsługujące niektóre usługi RESTFUL. Cała logika prezentacji odbywa się poprzez pobieranie obiektów Json i modyfikowanie widoku za pomocą javascript.

Aplikacja jest zasadniczo wyszukiwarką, ale będzie miała konta użytkowników z różnymi rolami.

Badałem niektóre frameworki, takie jak Play i Spring. Jestem całkiem nowy w tworzeniu stron internetowych, więc zastanawiałem się, jakie korzyści przyniesie renderowanie stron po stronie serwera?

Czy to: prędkość? Łatwiejszy rozwój i przepływ pracy? Dostęp do istniejących bibliotek? Więcej? Wszystkie powyższe?

użytkownik1303881
źródło
4
Bezpieczeństwo jest duże. W szczególności, gdy aplikacja jest dynamiczna i musi komunikować się z bazą danych.
Oded
2
@Oded - Dlaczego bezpieczeństwo jest łatwiejsze, gdy renderujesz stronę w porównaniu do interfejsu API? Zawsze uważałem, że to, co musisz zaprogramować, jest równoważne tak czy inaczej, ale łatwiej (przynajmniej dla mnie) psychicznie jest pamiętać, aby nie ufać klientowi podczas wykonywania interfejsu API. Pytam, bo jeśli przeoczam coś, co naprawdę chcę wiedzieć.
psr
1
@ psr Może on nie odnosić się do bezpieczeństwa danych bardziej niż do bezpieczeństwa użytkownika (np. wykorzystuje MITM). Tylko zgadnij.
wałek klonowy
1
@psr - uzgodniony. Jednak wczoraj odpowiedziałem na pytanie, w którym OP ma ciąg połączenia osadzony w JS ...
Oded
1
@maple_shaft - MITM to coś, o czym warto pomyśleć, ale znowu nie jestem pewien, dlaczego to robi różnicę w API i HTML generowanym przez serwer. Przypuszczam, że interfejs API jest wygodniejszy w programowaniu, więc byłoby to znacznie łatwiejsze złamanie, ale wątpię, o to ci chodzi.
psr

Odpowiedzi:

16

Renderowanie HTML po stronie serwera:

  • Najszybsze renderowanie w przeglądarce
  • Buforowanie stron jest możliwe jako szybki i brudny wzrost wydajności
  • W przypadku „standardowych” aplikacji wiele funkcji interfejsu użytkownika jest już wbudowanych
  • Czasami uważany za bardziej stabilny, ponieważ komponenty zwykle podlegają sprawdzeniu podczas kompilacji
  • Opiera się na wiedzy specjalistycznej
  • Czasami szybciej się rozwija *

* Gdy wymagania interfejsu użytkownika dobrze pasują do ram.


Renderowanie HTML po stronie klienta:

  • Niższe wykorzystanie pasma
  • Wolniejsze renderowanie strony początkowej. Może nawet nie być zauważalny w nowoczesnych przeglądarkach na komputery. Jeśli potrzebujesz obsługi IE6-7 lub wielu przeglądarek mobilnych (mobilny webkit nie jest zły), możesz napotkać wąskie gardła.
  • Zbudowanie interfejsu API po pierwsze oznacza, że ​​klient może równie łatwo być zastrzeżoną aplikacją, cienkim klientem, inną usługą internetową itp.
  • Opiera się na wiedzy JS
  • Czasami szybciej się rozwija **

** Gdy interfejs użytkownika jest w dużej mierze niestandardowy, z ciekawszymi interakcjami. Ponadto znajduję kodowanie w przeglądarce z interpretowanym kodem zauważalnie szybsze niż oczekiwanie na kompilacje i restart serwera.


Możesz również rozważyć model hybrydowy z lekką implementacją backendu, używając systemu szablonów front-end / back-end, takich jak wąsy .

peteorpeter
źródło
1
Zaraz zapomniałem o możliwościach buforowania!
Michael K
„W przypadku„ standardowych ”aplikacji wiele funkcji interfejsu użytkownika jest już wbudowanych. Nie ma to znaczenia, zarówno serwer, jak i klient mają to.
Raynos,
@Raynos Nie wspominał o używaniu frameworka po stronie klienta , ale jeśli go używa, to jest dobry punkt.
peteorpeter
1
Dzięki, to jest głównie odpowiedź, której szukałem. Nie zrobiłem zbyt wiele z frameworkami po stronie klienta, ale przeprowadziłem badania nad plikiem dust.js na podstawie wyboru LinkedIn. Wiem, że wąsy są alternatywą, ale będę je więcej badał. Prawdopodobnie zrobię coś hybrydowego, przede wszystkim chciałbym przesunąć sprawy na stronę serwera, jeśli to może poprawić wydajność. Dzięki jeszcze raz.
user1303881,
Naprawdę nie uważałbym niczego za „renderowanie HTML po stronie klienta” za zaletę. „Czasami szybciej się rozwija” wyskakuje z okna jeszcze raz, niż brane są pod uwagę najnowocześniejsze przeglądarki (IE 8 itp.).
null
3

generowanie HTML po stronie serwera:

  • łatwiej debugować;
  • brak problemów ze zgodnością przeglądarki;
  • przy klasycznym generowaniu całostronicowych stron po stronie serwera trudniej jest buforować HTML, nawet jeśli zawiera duże niezmienne części; (rozwiązaniem jest pobieranie fragmentów HTML za pomocą wywołań AJAX);
  • niewykorzystywanie buforujących serwerów proxy i CDN do dynamicznego HTML;

generowanie HTML po stronie klienta:

  • trudniejszy do debugowania;
  • niektóre problemy z przestarzałymi przeglądarkami;
  • bez problemów buforowanie szablonów HTML po stronie klienta;
  • korzystając z buforowania proxy i CDN dla szablonów HTML i kodu JS;
  • znacznie niższe wykorzystanie sieci;

Pamiętaj, że generowanie po stronie klienta to sposób, w jaki robi się to w przypadku udanych witryn mobilnych, ponieważ najwyraźniej jest o wiele bardziej wydajny w przypadku nowoczesnych przeglądarek (przeglądarki oparte na WebKit mają około 70-80% rynku mobilnego).

LinkedIn ma artykuł o zaletach podejścia po stronie klienta na przykładzie dust.js : „Pozostawienie stron JSP w pyle: przeniesienie LinkedIn do szablonów po stronie klienta dust.js”

vartec
źródło
1
+1 Na nowoczesnych smartfonach (głównie korzystających z webkit mobile) JS raczej nie będzie wąskiego gardła, podczas gdy przepustowość sieci komórkowej jest .
peteorpeter
1

To zależy od twoich wymagań. Jeśli potrzebujesz wysokowydajnego rozwiązania o niskim opóźnieniu, które zależy od wielu małych zadań, możesz wybrać strukturę podobną do tego, co opisujesz. Jednak najczęściej stosowane rozwiązania w Javie, PHP i C # nie są domyślnie stosowane.

Większość aplikacji internetowych zależy w bardzo dużym stopniu od baz danych - większość z nich tak bardzo, że strony nie mogły się renderować bez co najmniej jednego wywołania. Oczywiście nie chcesz publicznie udostępniać swojej bazy danych z kilku powodów:

  • Bezpieczeństwo (jak wspomina Oded ) - zdecydowanie nie chcesz publicznie ujawniać swojej sieci! Idealnie jedynym interfejsem do twoich systemów z zewnątrz powinien być https na twoim serwerze.
  • Łatwość programowania - naprawdę, naprawdę , naprawdę nie chcesz pisać SQL w JavaScript, a języki zaprojektowane do prezentacji internetowej nie działają dobrze z RDB. Nie mają na przykład pojęcia państwa.

Tak więc, kiedy potrzebujesz bazy danych, używasz języków, które dobrze się z nimi bawią, takich jak Java, C #, PHP itp. Najprostszym sposobem na wygenerowanie strony jest: Używanie języka szablonów (najsłynniejszego PHP, ale JSP i ASP to dwa inne bardzo popularne języki) do budowy strony. Język zapewnia konstrukcje wywołujące inne moduły. W PHP jest to zwykle na stronie lub w innym pliku PHP, używając wzorca MVC. W JSP używasz skryptletów lub języka wyrażeń JSP. Te inne moduły mogą ciężko pracować z łączeniem się z bazą danych, wykonywaniem logiki i zwracaniem wartości do warstwy widoku. Wynikiem końcowym jest wygenerowana strona HTML, renderowana na serwerze i wysyłana do klienta.

Gdy baza danych znajduje się w tej samej sieci co moduł renderujący strony, również uzyskuje się lepszą wydajność. Klient musi wykonać tylko jedno żądanie i otrzymać stronę - może być konieczne wykonanie 10-15 żądań DB, zanim uzyska się wszystkie informacje potrzebne użytkownikowi. Opóźnienie w milisekundach w sieci wyniesie od sekund do minut, jeśli klient będzie musiał wykonać je wszystkie.

Gdy systemy stają się większe, kluczowe staje się rozdzielenie problemów i kluczowych kompetencji. HTML jest dobry do wyświetlania. JavaScript jest dobry dla dynamicznych treści. SQL doskonale nadaje się do tworzenia zapytań do bazy danych, a inne języki są dobre w logice biznesowej. Naszym zadaniem jako programistów jest wykorzystanie wszystkich dostępnych narzędzi do zbudowania możliwego do utrzymania systemu. Łatwość rozwoju to ogromna część dobrego systemu. Moim zdaniem jest to prawie tak samo ważne jak wydajność i użyteczność. Wielkie systemy ewoluują z czasem. Słabe systemy od samego początku były źle napisane i nigdy nie zostały poprawione.

Michael K.
źródło
you can't write SQL in Javascript Naprawdę?! Czy kiedykolwiek spojrzał na pytania StackOverflow dla JavaScript? Chciałbym niestety się różnić. To prawda, że ​​jest to najgorsza rzecz, jaką możesz zrobić w kodzie klienta, ale ...
maple_shaft
... również zapomniałem o Node.JS, ale to jest serwer JS, który jest zupełnie innym zwierzęciem.
wałek klonowy
Najwyraźniej możesz - TIL! Tylko ... wow. Ale mów o nadużyciach językowych!
Michael K,
2
Interfejs REST to sposób, w jaki klient obecnie uzyskuje dostęp do danych bazy danych za pośrednictwem obiektów json. Nie ujawnia wszystkiego, a ta aplikacja jest częścią prywatnej sieci przedsiębiorstw. Jedną z zalet interfejsów jest możliwość wykorzystania przez dowolne aplikacje w przedsiębiorstwie dowolnej usługi. Z perspektywy programistycznej mogę pozwolić programistom frontendowym na robienie tego, co im się podoba w html / js / css, a następnie po prostu pingować interfejs RESTful zaprojektowany przez programistów Java. Jednak większość z nas ma mieszany zestaw umiejętności i ten podział może nie być konieczny.
user1303881,
3
-1: @MichaelK: rozmawiasz ze słomkiem, którego sobie wyobrażałeś, ale nie ma absolutnie nic wspólnego z prawdziwym życiem. RESTful używa HTTP. Nikt nie musi pisać SQL w JS, do tego właśnie służy interfejs RESTful. Również RESTful nie oznacza, że ​​istnieje mapowanie 1 do 1 z zapytaniami DB. Twoja odpowiedź mogła być ważna w latach 90., ale teraz mamy rok 2012.
vartec,
0

Klienci mobilni są zwykle ograniczeni pod względem mocy, przepustowości i pamięci. Prawdopodobnie lepiej jest renderować strony dla nich na serwerze.

W przypadku klientów stacjonarnych możesz rozważyć wysłanie js + json w celu renderowania strony na kliencie, umożliwienia jej dynamicznej aktualizacji itp.

9000
źródło
W praktyce jednak często jest dokładnie odwrotnie. W rzeczywistości projekt jQuery Mobile jest całkowicie oparty na koncepcji renderowania po stronie klienta.
Pointy,
@Pointy: tak, może być na odwrót. Należy sprawdzić, jak zachowują się poszczególne strony na poszczególnych klientach. Podanie linku do alternatywy (takiej jak linki w wersji „mobilnej” i „komputerowej”) również może być pomocne dla użytkownika.
9000
Urządzenia mobilne charakteryzują się dziś znacznie większym opóźnieniem niż małą przepustowością lub mocą obliczeniową. W projekcie, nad którym ostatnio pracowałem, bardziej martwiliśmy się rozmiarem strony niż szybkością renderowania - nowoczesne telefony są całkiem dobre.
Michael K,
@Pointy Projekt jQuery Mobile to także duży stos okropnego kodu, którego nie należy używać. Popularność! == wartość
Raynos,
@Raynos Właściwie korzystamy z Jquery Mobile, z całkiem niezłym sukcesem. Wiesz coś, czego my nie wiemy? ;)
Michael K
0

Ogromną zaletą renderowania po stronie serwera jest dostępność - aplikacje oparte na javascript nadal stanowią duży problem dla osób bez wzroku. To i jest ten niewidomy facet o imieniu „googlebot”, do którego możesz się zaspokoić. On też nie robi tak dobrze javascript.

Wyatt Barnett
źródło
Dobra uwaga, chociaż ta aplikacja nie wymaga SEO, ponieważ jest prywatna, rozwijam też niektóre aplikacje osobiste i jest to kwestia ważna na tym polu.
user1303881,
Googlebot nie interpretują JS / AJAX dłuższego czasu: searchenginewatch.com/article/2122137/...
vartec
@vartec: Myślę, że kluczowym przesłaniem tego artykułu jest „można teraz czytać i rozumieć niektóre dynamiczne komentarze zaimplementowane przez AJAX i JavaScript”. Podejrzewam, że obejmuje disqus i facebook, ale nie twoją niestandardową konfigurację ajax.
Wyatt Barnett,