Jakie zalety daje renderowanie strony po stronie serwera?

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?

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 .

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”

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.

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.

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.