Client vs Server Side Rendering i inne

Cześć !
Witaj w kolejnym newsletterze Ahoy Dev! Jak zwykle mamy dla Ciebie serię linków ze świata Full-Stack, podsumowanie ostatniego tygodnia na Ahoy! oraz merytoryczny artykuł, tym razem od Jakuba Fedoszczaka.
Pamiętaj, że możesz dać nam znać co sądzisz o naszym newsletterze w dedykowanej do tego ankiecie - dzięki!
Trzymaj się!
Jarek

CSR, SSR? Co to ma być?

Każdy z nas jest lub będzie developer'em (tak myślę), więc musimy zdawać sobie sprawę, że oprócz tego, że korzystamy z jakiś frame-work'ów to musimy wiedzieć w jaki sposób one działają i jak zadziałają na produkcji.
Właśnie dlatego pojawiam się ja z tym postem.
Otóż każdy frame-work oprócz tego, że charakteryzuje się innym wzorcem pracy, to może różnić się również'pod spodem' i dać inny efekt użytkownikowi.
Jest to tzw. metoda renderowania aplikacji, czyli sposób, w jaki nasz frame-work będzie pracował ze stroną i w jaki sposób ją zaserwuje.
To coś w stylu kelnera w sklepie - są różni. Jeden podejdzie sam, drugiego trzeba zawołać, a trzeciego nie ma, bo się obsługuje samemu w tej restauracji. Najprościej mówiąc - chodzi właśnie o sposób, w jaki nasza aplikacja wyląduje u odbiorcy.

CSR - Client-Side Rendering

Pierwszym sposobem (na którym bazuje np. React) jest CSR.
CSR, czyli Client-Side Rendering (renderowanie po stronie klienta), bazuje w pełni na sprzęcie użytkownika. Jak sama nazwa mówi - to klient się zajmuje renderowaniem aplikacji. Wykorzystujemy jego procesor do lokalnej obsługi JS'a, który nam zbuduje stronę na zawołanie.
Jednocześnie - jak pewnie się domyślasz - skoro korzystamy z procesora użytkownika, to serwer za wiele do roboty nie ma. I masz rację! Serwer kończy swoją pracę na zaserwowaniu plików (robi to tylko jeden raz!).

No dobra, a jak to działa w akcji?

Jak zbudujemy aplikację w React'cie, to mamy w katalogu /build pliki, które następnie trafiają na jakiś hosting.
Ten hosting na 'zawołanie' od użytkownika (a raczej jego maszyny) wysyła do niego te pliki, które u nas po wybudowaniu aplikacji wylądowały w katalogu /build.
Później, użytkownik otrzymując te pliki, uruchamia w tym samym momencie skrypty JS, które budują całą stronę. Wykorzystujemy jego moc obliczeniową. Każda akcja na stronie, przejdzie przez procesor naszego odbiorcy.

SSR - Server-Side Rendering

Drugim sposobem (który obsługuje np. NextJS) jest SSR.
SSR, czyli Server-Side Rendering (renderowanie po stronie serwera) to zupełnie inna para kaloszy. Jak się pewnie domyślasz - tutaj, w drugiej drużynie, która wszystkie siły pakuje w serwer - odciążamy użytkownika do granic możliwości. To nasza maszyna hostująca aplikację weźmie na siebie ciężar renderu strony.
No i znowu jest pewna dziwna zależność - skoro użytkownik dostaje gotowy interfejs z danymi, to jego procesor nie ma zbyt wiele do roboty, a nasz serwer się poci!

No dobra, ale jak to działa w praktyce?

Po wybudowaniu aplikacji w NextJS (a tak naprawdę to przygotowaniu jej do działania), dostajemy zestaw plików w folderze /build. Te pliki trafiają... no właśnie.
Zwykły serwer obsługujący strony internetowe za zadanie ma postawione serwowanie plików strony klientowi... i tyle. A co w przypadku, kiedy wymagamy od niego dodatkowej pracy, którą jest renderowanie stron po jego stronie?
Odpowiedź jest prosta - potrzebujemy odpowiedniego przygotowania takiego serwera. Vercel dostarcza w swoim hostingu gotowy stack technologiczny na którym lądują aplikacje NextJS, przez co mogą one działać bez problemu i w ciągu kilku sekund. Hostowanie na własną rękę jest również możliwe, ale wymaga więcej pracy.
Także wracając - pliki aplikacji, która jest skierowana na SSR, muszą trafić na specjalnie skonfigurowany serwer.
W momencie, gdy klient wchodzi na stronę, dzieje się mniej więcej coś takiego:

Request do serwera

Serwer sprawdza, czy już wcześniej wybudował stronę, o którą prosi klient.
Jeżeli tak - wysyła stronę w postaci HTML + CSS
Jeżeli nie - buduje stronę po swojej stronie, wkłada do folderu z gotowymi stronami i wysyła w postaci HTML + CSS
Jeżeli strona została ustawiona jako "pobierająca dane na żywo", czyli np. zawsze na niej ma się wyświetlać aktualna pogoda, to serwer za każdym razem musi ją budować po swojej stronie. Ale robi to w ten sposób:
a. Wysyła request o aktualną pogodę
b. Pobiera dane, podmienia zmienne w kodzie strony c. Buduje ją
d. Serwuje wynik w postaci HTML + CSS
Mądre? Mądre.

Czy istnieje coś pomiędzy SSR, a CSR?

Ze stabilnych rozwiązań, które testowałem - nie ma takich. Sam osobiście jeszcze nie miałem doczynienia z czymś, co byłoby realnie pomostem między tymi dwoma światami.
Nie jest z kolei powiedziane, że to jest problem, którego nie da się rozwiązać - coraz częściej się mówi o nadchodzących w React'cie "Server Components", które mają stworzyć coś w stylu CSR + SSR.
Także przysłość może być ciekawa i przełomowa.

Który koncept jest lepszy?

Trudne pytanie i myślę, że to kwestia tego, na czym nam zależy i jakimi środkami dysponujemy. Jako iż lubię ludziom pozostawiać pole do własnej opinii, to tylko wypiszę plusy i minusy obu rozwiązań.
Nie będzie to jakieś wygórowane porównanie, aczkolwiek myślę, że bardzo konkretne.

CSR - plusy i minusy

Plusy:
bardzo tanie w hostowaniu (wręcz darmowe)
jeżeli użytkownik dysponuje dobrym sprzętem, to strona będzie działała pięknie
Minusy:
jeżeli użytkownik nie ma dobrego sprzętu, to strona mu będzie się zacinać
nie ma mowy o korzystaniu z atutów serwera jak np. funkcje po jego stronie

SSR - plusy i minusy

Plusy:
użytkownik zawsze dostanie stronę szybko i zgrabnie bez względu na jego sprzęt
możemy korzystać z atutów serwera np. funkcje po jego stronie
Minusy:
drogi (a przynajmniej niebezpłatny w utrzymaniu)
więcej pracy przy setup'ie hostingu na własną rękę
Sekcja bonusowa dla Ahoy! ⚡
Inne metody - SSG i ISR
SSG - Static Site Generation
SSG, to sposób renderowania aplikacji, w którym tak naprawdę to renderujemy ją tylko jeden raz - przy wypuszczaniu jej na produkcję. Z takiego sposobu generowania stron słynie chociażby Gatsby.
Oznacza to, że wszystkie dane, które mają być zaciągnięte z innych serwisów, zostają właśnie przyjęte na etapie build'u.
Dla użytkownika jest to bardzo wygodne, gdyż nie jest to dla niego obciążające. Tak samo dla serwera. Spoczywają na nim tylko pliki statyczne.

No dobra, ale jak to działa w praktyce?

Oto schemat tego, jak działa mniej więcej SSG:
Zaczynamy budować aplikację
Frame-work zaciąga wszystkie dane, które pochodzą z zewnątrz i wsadza je do zmiennych
Renderuje strony
Wypluwa kod HTML + CSS
Czyli na naszym serwerze wyląduje znowu garść prostych plików - same HTML'y i CSS'y.
Z minusów jest fakt, że nie ma tu żadnej dynamiki dopóki znowu nie uruchomimy build'a.
ISR - Incremental Static Regeneration
ISR, to rozszerzony sposób SSG. Co to oznacza?Strony wygenerowane w ten sposób, tak jak w przypadku SSG są budowane tylko raz w ciągu build'a, ale można dodatkowo określić, które podstrony mają się regenerować i w jakim czasie.
Czyli np. mamy taki stack stron:
Strona Główna - statyczna (SSG)
O nas - statyczna (SSG)
Sklep - statyczna (ISR)
Dzięki ISR nasz sklep może regenerować się co określoną liczbę sekund. Jest to na tyle ciekawy mechanizm, że zalecam indywidualną lekturę.
Źródła dodatkowe
Hello Roman - React vs Next vs Gatsby (klik!)
"A closer look at CSR & SSR" (klik!)

Ciekawe linki

Rozmowa Lexa Fridmana z Johnem Carmackiem wzbudziła na Ahoy spore zainteresowanie, dlatego jestem przekonany, że może trafić również do Ciebie. Warto jej posłuchać, a jeśli jesteś członkiem Ahoy, to przeczytać dodatkowo notatki od Tomka Świstaka, które pojawiły się w jednym wątku
Jeżeli interesuje Cię React, to warto zajrzeć do 5 praktyk, które pomogą skalować projekty, ale też to złych nawyków, których warto się pozbyć. Idealne artykuły, żeby przemyśleć swoje podejście codzienne.
Świetna seria artykułów JavaScript visualized - ma aż 7 części, więc wolę odesłać Cię, do nadrzędnej listy, żeby nie przekładać niepotrzebnie linków, ale uwierz, warto zajrzeć do środka!

Na Społeczności

Jira + Confluence do zarządzania projektem i tworzenia dokumentacji, czy….? Właśnie na taki temat dyskusję rozpoczął Daniel Roziecki. Oczywiście ile głów, tyle podejść, ale warto popatrzeć, z czego korzystają inni.
Co robicie, aby wyprodukować jak najwięcej dobrej jakości kodu w jak najkrótszym czasie? Jakie stosujecie rytuały/nawyki? Jakich narzędzi używacie? Jakie procesy automatyzujecie i w jaki sposób? Jak radzicie sobie z przerywnikami typu spotkania, pytania innych osób w zespole etc. To kilka trudnych pytań, które w wątku o produktywności dewelopera poruszył Krzysztof Tutak
Jak rekrutować? Jak sprawdzać wiedzę? Płacić za wykonywanie zadań, czy nie? Pytań w kontekście rekrutacji można zadawać wiele - nie tylko kandydatom. Właśnie dlatego o tym rozmwialiśmy na Ahoy w wątku zainicjowanym przez Tomasza Piątka

Wydarzenia

Niedawno odbyło się kolejne wydarzenie z serii Full Stack Q&A z Wojtkiem Połowniakiem - tym razem z wątkiem przewodnim… wystąpień publicznych. Zajrzyj, jeśli masz ochotę poznać podejście praktyka.
Już niebawem (18.08) kolejny Full Stack Live, w którym tym razem Wojtek Dasiukiewicz, który opowie o tym, jak budować Start-up na etacie! Wojtek jest programistą z 10 letnim stażem, ale - co ciekawe - nie zatrzymał się tylko na funkcji etatowego Team Lada, ale od ponad roku rozwija Zencal. Jeśli jeszcze go nie znasz, to koniecznie sprawdź (zarówno Zencal, jak i Live z Wojtkiem)