Czy server side rendering ma sens w 2021?

Question

Pytanie jak w temacie. Czy w 2021 roku jest jeszcze sens bawić się w SSR ?  Aktualnie pracuję nad projektem, który w przyszłości ma być znacznie bardziej rozbudowany, ma logowanie, rejestrację itd i skupia się głównie na dostarczaniu contentu. Co jest lepszym rozwiązaniem CSR czy SSR ?

Answer 1

Ostatnio dużo czytałem na ten temat. Odpowiedz: to zależy. Jeżeli robisz stronę typu One Page(nie mylić z single page), albo jakąś stronę, która ma być dobrze pozycjonowana to SSR jest idealny. Większość wyszukiwarek średnio, albo wcale nie czyta kodu JS. Nawet Google ma z tym bardzo duże problemy. Głównie z tego co wyczytałem barierą jest moc obliczeniowa. Przeanalizować miliardy linków każdego dnia jest raczej ciężkim zadaniem. Osobiście uważam, że strony typu One Page czy portfolio powinny używać JS w minimalnym stopniu. Jeżeli robisz coś większego to czemu nie, ale problem z SEO nadal istnieje, więc SSR nadal będzie potrzebny.

Comments

Dokładnie jak pisze JakSky.

Do tego dochodzą sprawy bezpieczeństwa. Generalnie trudniej zabezpieczyć stronę typu REST API, niż starą, tradycyjną.

 

---

@JakSky,

Jeżeli robisz stronę typu One Page(nie mylić z single page), albo jakąś stronę, która ma być dobrze pozycjonowana to SSR jest idealny

Serio? Ręki sobie nie dam uciąć, ale wyczytałem, że aplikację SPA da się spokojnie przygotować pod SEO tylko wymaga to większego wysiłku niż SSR.

 Większość wyszukiwarek średnio, albo wcale nie czyta kodu JS. Nawet Google ma z tym bardzo duże problemy.

Poważnie? Skąd taka opinia? Ponownie nie dam sobie ręki uciąć, ale co nieco czytałem na ten temat i z tego co pamiętam nie stanowi to problemu.

 Głównie z tego co wyczytałem barierą jest moc obliczeniowa. Przeanalizować miliardy linków każdego dnia jest raczej ciężkim zadaniem

No nie wiem, a odpowiadać na miliardy zapytań jakoś daje radę? 

---

Większość wyszukiwarek średnio, albo wcale nie czyta kodu JS. Nawet Google ma z tym bardzo duże problemy.

Z tego co ja wiem, to faktycznie jest tak, że wyszukiwarki coraz lepiej sobie radzą z pozycjonowaniem stron SPA, i nie jest to już aż tak dużym problemem jak wtedy kiedy frameworki frontendowe wchodziły, ale jeśli masz stronę która może być stroną statyczną, to wygenerowanie strony statycznej da ci jedynie plusy (nawet kiedy korzystasz z ssg, to nie musisz robić wszystkiego w czasie budowania aplikacji, część możesz zostawić dynamiczną)

---

Generalnie trudniej zabezpieczyć stronę typu REST API, niż starą, tradycyjną.

Znowu, nie do końca, tak jak ci pisał Arkadiusz Waluk w pytaniu które podlinkowałeś, jeśli dobrze zabezpieczysz API, to jest tak samo podatna na złamanie zabezpieczeń jak ta "stara, tradycyjna". Na pewno łatwiej napisać bota jeśli masz do dyspozycji rest api. To raczej słaby argument bo na stronach bez rest api jest to jedynie minimalnie bardziej pracochłonne. No ale jeśli używasz ssr to i adresy api nie będą ujawnione.

Jedynym minusem rest api, mogą być jwt, które wiele osób źle zabezpiecza, ale jeśli access token ma małą żywotność i token jest przesyłany do aplikacji jako cookie http only to api jest raczej bardzo bezpieczne

---

Napisałem, że REST API trudniej zabezpieczyć niż tradycyjne strony (nie jest to moja opinia, tylko wyczytana w kilku miejscach w Sieci. Są to opinie osób, które znają się na tych sprawach dobrze). Co nie oznacza, że nie można ich zabezpieczyć bardzo dobrze. Jak ktoś jest specjalistą w tej dziedzinie, to może lepiej zabezpieczyć REST API niż ktoś zielony w temacie tradycyjną stronę. Ale potrzeba do tego dużej wiedzy i doświadczenia. No i nakład pracy jest większy w przypadku REST API niż starych stron.

---

Ale pod względem technicznym to jest praktycznie to samo. A samo zabezpieczenie WebAPI jest praktycznie identyczne.

Co do:

nakład pracy jest większy 

To też można by tu dyskutować. Owszem może być to bardziej pracochłonne na początku, ale w późniejszym czasie będzie to na pewno lepsze rozwiązanie. Modernizacja i ulepszanie kodu staję się sporo łatwiejsze.

Answer 2

Czy jeszcze ma sens? Każdy krok który robi web, pokazuje, że SSR/SSG jest coraz bardziej potrzebne. Co masz na myśli pisząc "bawiąc się w"? Zarówno w Reactcie jak i we Vue frameworki do ssr są bardzo przyjemne i ułatwiają masę rzeczy

Comments

Czy jeszcze ma sens? Każdy krok który robi web, pokazuje, że SSR/SSG jest coraz bardziej potrzebne

Możesz rozwinąć co masz na myśli? 

Co masz na myśli pisząc "bawiąc się w"?

Mam na myśli wykorzystywać po prostu 

Zarówno w Reactcie jak i we Vue frameworki do ssr są bardzo przyjemne i ułatwiają masę rzeczy

Możesz rozwinąć? 

---

Czy jeszcze ma sens? Każdy krok który robi web, pokazuje, że SSR/SSG jest coraz bardziej potrzebne

Coraz bardziej liczy się performance stron www, jednocześnie nasze aplikacje chcemy pisać z wykorzystaniem wielu bibliotek, skoro wiele z nich może być wykonywanych po stronie serwera i nie ma potrzeby wysyłać ich do klienta, to dlaczego by nie zaoszczędzić na transferze (który zwłąszcza na telefonach mocno się liczy). Ostatnio google "wypuścił" standardy web core vitals, o wiele łatwiej uzyskać na nich dobry wynik jeśli nie jesteś aplikacją SPA. No i nawet jeśli korzystamy z lazy loadingu, i importujemy bundle dopiero gdy użytkownik wejdzie na daną podstronę, to i tak w stronach SPA, jest duża część kodu która i tak jest przesyłana do przeglądarki a mogłaby zostać na serwerze.

 

Zarówno w Reactcie jak i we Vue frameworki do ssr są bardzo przyjemne i ułatwiają masę rzeczy

Chodzi mi głównie o Nuxt'a (który może być kompilowany do SPA, może tworzyć strony statyczne i może być ssr) i Next'a.

Jeśli masz jakąś "małą" stronę, a chcesz użyć jakiegoś frameworka (bo pisanie w nich jest przecież o wiele przyjemniejsze) to kiedy będziesz korzystać z ssr lub ssg (zwłaszcza z ssg) to koszt jaki musisz zapłacić za użycie frameworka jest praktycznie zerowy, a wręcz masz wiele optymalizacji (jak prefetching, service workery) prawie że out of the box