Rewalidacja w Next.js 13

Problem

Chcemy rozwiązać następujący case: dane na stronie internetowej są bliskie statycznym - zmieniają się z częstotliwością np. tygodnia lub miesiąca. Chcemy pokazywać użytkownikom nową zawartość jak najszybciej, z zachowaniem jak największej wydajności.

Rozwiązanie pierwsze - Dynamic SSR

Dynamic SSR, czyli Dynamic Server-Side Rendering może być jednym z podejść do zastosowania w takim przypadku. Strona będzie budować HTMLa od nowa, za każdym razem kiedy user wejdzie na daną podstronę. To zapewnia użytkownikom dostęp do nowej zawartości praktycznie od razu. Implementacja polega na ustawieniu opcji revalidate na 0 w konfiguracji danej podstrony i wyłączeniu cache'a dla funkcji fetch(). Nie jest to jednak najlepsza opcja z punktu widzenia wydajności.

Rozwiązanie drugie - Time-based ISR

ISR to skrót od Incremental Static Regeneration. Polega ona na rebudowaniu stron, tak, aby miały one zawsze świeże dane, przy jednoczesnych serwowaniu ich jako gotowy, zacache'owany HTML. Jednym ze sposobów implementacji ISR w Next.js 13 jest ustawienie wyżej wspomnianego atrybutu revalidate na ilość sekund, która ma upłynąć między rebuildami strony. Przykładowo revalidate ustawione na 3600 spowoduje, że strona będzie aktualizować serwowanego użytkownikom HTMLa co godzinę. Jest to dla nas jednak problematyczne rozwiązanie ze względu na potrzebę ustawienia "sztywnej" liczby sekund. Mamy tutaj dwa problemy:
 

1. Aplikacja będzie budować od nowa widoki, które się nie zmieniły, pobierając te same dane wielokrotnie.
2. Użytkownik będzie musiał czekać (maksymalnie) podaną przez nas liczbę sekund, żeby zobaczyć nową zawartość. Jest to problematyczne, ponieważ usecase uwzględniał natychmiastową aktualizację zawartości.

Sprawia to że Time-based ISR jest dobrą opcją dla case'ów, które nie wymagają natychmiastowej aktualizacji zawartości, a zatem dla naszego usecase'u pozostaje opcją awaryjną.

Rozwiązanie trzecie - Path-based on-demand ISR

Path-based on-demand ISR polega na budowaniu od nowa tylko tych podstron, na których zawartość się zmieniła i tylko wtedy, kiedy się zmieniła. Brzmi to jak idealne rozwiązanie dla nas. Załóżmy, że mamy artykuły - każdy znajduje się pod ścieżką /blog/[slug]. Wystawmy sobie endpoint, który przyjmuje informacje o tym co się zmieniło (np. artykuł) i użyjmy w nim funkcji revalidatePath zaimportowanej z next/cache. Następnie używamy jej w następujący sposób:

revalidatePath('/blog/[slug]')

W ten sposób użytkownik otrzyma nowe dane za następnym razem, kiedy wejdzie na stronę artykułu. Kawałek kodu powyżej zrewaliduje wszystkie segmenty, a co za tym idzie - wszystkie artykuły. 

Rozwiązanie czwarte - Tag-based on-demand ISR

Tag-based on-demand ISR różni się od rozwiązania trzeciego tym, że nie musimy wiedzieć, w którym miejscu zostałe użyte dane. Wystarczy że do konfiguracji funkcji fetch() dodamy:

next: { tags: ['my-tag'] }

I w ten sposób nasz request zostaje powiązany z tagiem, który przekazaliśmy. Teraz w enpoincie do rewalidacji możemy skonstruować odpowiedni tag na podstawie danych, które otrzymaliśmy przy aktualizacji contentu i wywołać funkcję do rewalidacji tagu, zaimportowaną z next/cache:

revalidateTag('my-tag')

W ten sposób wszystkie podstrony używające danych z requestów z tym tagiem zostaną zbudowane od nowa kiedy użytkownik na nie wejdzie. Jest to bardzo wygodny feature Nexta, ułatwiający pracę z case'ami pokroju footera strony budowanego na podstawie danych z CMSa - po prostu rewalidujemy odpowiedni tag, a Next znajduje używające go route'y za nas.

Podsumowanie

Next.js 13 daje masę możliwości w kwestii aktualizacji contentu. Pamiętajmy że feature'y opisane wyżej są dostępne tylko jeśli używamy App Routera. Część funkcji może też nie działać prawidłowo jeśli nasza instancja Nexta jest self-hosted, bez użycia platformy Vercel dedykowanej dla tego frameworku.

Źródło: https://nextjs.org/docs