Sposoby generowania aplikacji w Next.js

Next.js jest aktualnie jednym z najbardziej popularnych frameworków w świecie JavaScript.

Dużo osób i projektów, przechodzi ze standardowo używanego Create React App, właśnie na Nexta. Jednym z powodów jest to, że Next.js daje nam większą kontrolę nad sposobem generowania SPA.

Zacznijmy może od definicji podstawowych sposobów generowania aplikacji frontendowej. Możemy tutaj wymienić między innymi:

• CSR (Client Side Rendering) - czyli zbudowana przez nas aplikacja, posiada w sobie dużo skryptu JS, który odczytywany jest przez interpreter przeglądarki. Można powiedzieć, że cały tekst, obrazki i inne elementy strony, opakowane są w skrypt JavaScript. Może to powodować spore obciążenie po stronie przeglądarki użytkownika
• SSR (Server Side Rendering) - w tym przypadku, treści strony pobierane są z backendu. Wchodząc na taką aplikacje, zazwyczaj musimy poczekać chwilę, aż nasza przeglądarka wyśle zapytanie o treść do serwera, odbierze ją w formie responsa, a następnie wyświetli otrzymaną zawartość. Takie rozwiązanie powoduje, że przeglądarka użytkownika jest mniej obciążona, natomiast właściciel aplikacji, musi wyposażyć się w stosowny serwer i bazę danych, gdzie będą przechowywane wszelkie treści.
• SSG (Static Site Generator) - ostatnim rozwiązaniem, jest generowanie statycznych treści. Takie podejście było standardem wiele lat temu, gdzie serwowane były zwykłe, statyczne pliki HTML i CSS. Teraz ponownie wraca do łask ze względu na swoje liczne zalety, jednak nie musimy już pisać czystych HTML ręcznie, bo mamy właśnie od tego tryb 'generatora' w nowoczesnych frameworkach. Główną zaletą tego rozwiązania, jak można się domyślić, jest minimalne obciążenie zarówno przeglądarki użytkownika, jak i serwera właściciela aplikacji. Wszystko działa błyskawicznie szybko, a to dzięki temu, że użytkownik wchodząc na naszą stronę otrzymuje nic innego, jak zwykły plik HTML. Bardzo często te rozwiązania, są od razu wyposażone w systemy cache'owania czy prerenderingu - o czym opowiemy przy innej okazji.

Teraz, gdy znamy już podstawowe sposoby generowania aplikacji (bo nie wymieniliśmy wszystkich!), możemy przejść dalej.

Poczciwy 'Create React App', standardowo buduje aplikację w formie CSR (Client Side Rendering). Jak już wspomnieliśmy, oznacza to, że wchodząc na naszą aplikacje, bardzo dużo rzeczy potrafi być przetważane bezpośrednio w naszej przeglądarce. CRA nie ma możliwości łatwego przechodzenia między trybami generowania aplikacji. Tak działa i tyle.

Między innymi dlatego, pojawiła się przestrzeń dla innych frameworków takich jak Gatsby, czy tytułowy Next.js.

Aktualnie, Next.js oferuje możliwość budowania stron zarówno w formie CSR jak i SSR i SSG a także, od niedawna w formie ISR (Incremental Static Regeneration).

W oficjalnej specyfikacji Next.js wyczytać możemy, że rekomendowanym rozwiązaniem jest właśnie SSG, ze względu na to, że generuje nam statyczne pliki które błyskawicznie potrafią zostać obsłużone przez przeglądarkę, a dodatkowo można je serwować w formie CDNa.

SSR oczywiście również jest bardzo dobrym rozwiązanem, jednak powinien być używany głównie tam, gdzie prezentowana treść może się często zmieniać na backendzie. Mówimy tutaj np o serwisach nad którymi pracuje więcej osób i operują na różnych danych liczbowych, konfiguracjach itp. Natomiast jeżeli chodzi o zwykłe blogi, gdzie raz na jakiś czas dodajemy posta, to SSG powinien być wystarczający.
Tym bardziej że.. Mamy jeszcze wspomniany ISR.

ISR jest nowym 'wynalazkiem', który polega na pewnego rodzaju połączeniu technologii SSG i SSR. Czyli, generujemy statyczne pliki, natomiast możemy ustawić czas, po którym nasza zawartość może ulec ponownej weryfikacji - czyli mówiąc wprost, dane zaktualizują się na podstawie nowej zawartości otrzymanej z serwera. Co najlepsze, nie ma tutaj jakiejś skomplikowanej konfiguracji aby wykorzystać takie podejście. Wystarczy, że przy standardowej definicji pobierania danych dla SSG (czyli przez użycie getStaticProps użyjemy dodatkowej opcji revalidate: <number> - która to definiuje, po jakim czasie nasza strona ma ulec rewalidacji. <numer> jest tutaj liczbą, wyrażaną w sekundach.

Co ciekawe, zarówno SSG jak i SSR czy nawet ISR, możn używać na przemiennie w ramach jednej aplikacji. Dlatego wybierając Next.js możemy bez problemu dobierać najlepiej pasujące rozwiązania generowania treści dla każdej strony, a nawet każdego komponentu. W zależności od tego, czy jest to treść statyczna, aktualizowana sporadycznie, czy też treść która będzie ulegała częstym zmianą w bazie danych.

Na koniec dodatkowa uwaga:
Pamiętajcie, że przy użyciu Static Site Generatora, wszelkie requesty są pobierane w trakcie budowania aplikacji! Z tego powodu, czas budowania może być odrobinę dłuższy, ale za to wygenerowane pliki HTML mają już treść otrzymaną z serwera. Jeżeli dojdzie do jakichś zmian na serwerze, to nie zostaną one wyświetlone odwiedzającym nas użytkownikom, do momentu, aż nie przebudujemy naszej aplikacji.