Nasze doświadczenia z dodawaniem Edge Runtime do SDK Next.js
SDK Next.js Logto obsługuje teraz Edge Runtime. W tym artykule podzielimy się
aszą przygodą, patrząc
a przeszkody, z którymi się zetknęliśmy, jak je pokonaliśmy i co ciekawego poznaliśmy po drodze.
SijieDeveloper
Przestań tracić tygodnie na uwierzytelnianie użytkowników
Uruchamiaj bezpieczne aplikacje szybciej z Logto. Zintegruj uwierzytelnianie użytkowników w kilka minut i skup się na swoim głównym produkcie.
Edge Runtime stał się buzzwordem w pejzażu technologicznym,
apędzając dynamiczne,
iskie opóźnienia funkcji
a platformach od AWS Lambda@Edge i Cloudflare Workers do Vercel Edge. Podkreślając jego znaczenie, Vercel
iedawno zmieniło "experimental-edge"
a "edge", sygnalizując oficjalne wsparcie w ich popularnym frameworku Next.js.
Wraz z
aszym SDK Next.js zdobywającym poważną popularność, my w Logto pomyśleliśmy, "Dlaczego by
ie dodać wsparcia Edge Runtime?" Więc podnieśliśmy rękawy i wskoczyliśmy
a główkę. W tym artykule podzielimy się
aszą przygodą, patrząc
a przeszkody, z którymi się zetknęliśmy, jak je pokonaliśmy i co ciekawego poznaliśmy po drodze.
Praca z Edge Runtime stanowi pewne unikalne wyzwania, głównie dlatego, że
ie obsługuje wszystkich modułów i zależności powszechnie używanych w Node.js. Napotkaliśmy
a ten problem z modułami crypto, lodash i iron-session, co wymagało
ieco innowacyjnych obejść.
W środowisku Node.js, moduł kryptograficzny służy jako osłona dla funkcji kryptograficznych OpenSSL. Niestety, Edge Runtime tego
ie obsługuje. Ale bez paniki - większość Edge Runtimes ratuje sytuację, obsługując API Web Crypto. Pomimo drobnych różnic, jest to solidny zamiennik dla modułu krypto. Na przykład, aby generować losowe bajty:
Lodash jest ulubieńcem wielu deweloperów ze względu
a swoją użyteczność, ale Edge Runtime
ie jest fanem. Nasze obejście? Zamieniliśmy funkcje Lodash
a
atywne metody JavaScript, zachowując
asz kod zarówno efektywny, jak i czytelny.
Chociaż zastępowanie większości funkcji Lodash
ie było herkulesowym zadaniem, wymagało pewnej finezji. Spójrzmy, jak
aśladowaliśmy użyteczność "once"
a
asz sposób:
Najnowsza wersja modułu iron-session jest przyjazna dla Edge Runtime, więc wszystko, co musieliśmy zrobić, to zaktualizować
aszą wersję. Proste jak to!
Poruszanie się w zawiłościach "Odpowiedzi" w Edge Runtime#
Kolejnym wyzwaniem, z którym się zetknęliśmy, dostosowując
asze SDK do Edge Runtime, były różnice w obiekcie "Response". Oto, jak pokonaliśmy te różnice:
W przeciwieństwie do Node.js, żądanie w Edge Runtime
ie jest związane z odpowiedzią. Oznacza to, że musimy ją utworzyć, wywołując new Response(), oto przykład zwracania danych:
W Edge Runtime, Response.body to sprawa tylko do odczytu. Oznacza to, że
ie mogliśmy zainicjować odpowiedzi, zanim dane były przygotowane. Jako wynik,
asze zaufane "withIronSessionApiRoute" (wraz z innym oprogramowaniem pośredniczącym) musiało zostać wyłączone.
Aby zrozumieć, co zastąpiliśmy,
ajpierw rozpakujmy, co withIronSessionApiRoute robi:
Rzuca okiem
a ciasteczko, konstruuje obiekt sesji i związuje go z res.
Automatycznie dodaje
agłówek "set-cookie" do res w przypadku zmian w sesji.
Więc jak odtworzyliśmy tę funkcję w
aszym
owym środowisku Edge Runtime?
Czytanie: Wykorzystaliśmy istniejącą funkcję getIronSession. Dając jej pustą i fałszywą odpowiedź, otrzymuje sesję jak to konieczne. To zastąpiło metodę "get" z req.session.
Zapis: Przygotowaliśmy odpowiedź z danymi
a początku, a
astępnie użyliśmy getIronSession
a tej instancji responses, aby uzyskać obiekt sesji. Kiedy miała go w rękach, mogła modyfikować sesję tak, jak to wymagała.
Zastanawialiśmy się
ad stworzeniem osobnego pakietu dla Edge, ale szybko zauważyliśmy, że to
iepotrzebne. Większość
aszego kodu była współdzielona między dwoma środowiskami, tylko kilka linii wymagało zmian. Ponadto, korzystanie z SDK jest mniej więcej takie samo w obu środowiskach, więc utrzymanie jednego pakietu miało
ajwięcej sensu.
Zamiast dublować wysiłki, zdecydowaliśmy się
a rozszerzenie istniejącego pakietu. Dodaliśmy folder "edge" bezpośrednio w korzeniu pakietu, tuż obok starego folderu "src". Następnie zaktualizowaliśmy plik package.json, dodając
ową ścieżkę do "exports". W ten sposób zarówno środowisko Edge, jak i Node.js mogły żyć w harmonii w obrębie tego samego pakietu, bez większych kłopotów.
Dzieląc się
aszą podróżą pochłaniania Edge Runtime, mamy
adzieję zainspirować i pokierować innych, którzy szukają podobnych ścieżek. Czekaj
a kolejne aktualizacje z
aszym SDK Next.js.
