Next.js SDK'ye Edge Runtime Ekleme Deneyimimiz

Giriş#

Edge Runtime, teknoloji alanında bir buzz kelimesi haline geldi, dinamik, düşük gecikmeli fonksiyonları AWS Lambda@Edge ve Cloudflare Workers'dan Vercel Edge'e kadar platformlarda sürüyor. Önemini vurgulamak için, Vercel yakın zamanda "experimental-edge"i "edge"e çevirdi, popüler Next.js platformlarında resmi desteği işaretleyerek.

Next.js SDK'mızın ciddi şekilde ilerlemesiyle, biz Logto'da, "Neden Edge Runtime desteği eklemiyoruz?" diye düşündük. Böylece, kollarımızı sıvadık ve hemen atladık. Bu makalede, maceramızı paylaşacak, karşılaştığımız engellere, onların asıl aşıldığına ve yol boyunca öğrendiğimiz ilginç şeylere bakacağız.

Edge Runtime desteği için modüllerin ve bağımlılıkların geçişi#

Edge Runtime ile çalışmak bazı benzersiz zorluklar sunar, çünkü genellikle Node.js'te yaygın olarak kullanılan tüm modülleri ve bağımlılıkları desteklemez. Bu sorunu crypto, lodash ve iron-session modülleriyle karşılaştık, bu da bazı yenilikçi çözümler gerektirdi.

Crypto#

Bir Node.js ortamında, crypto modülü OpenSSL kriptografik fonksiyonları için bir kaplama görevi görür. Ne yazık ki, Edge Runtime bunu desteklemiyor. Ama endişelenmeyin - çoğu Edge Runtime, Web Crypto API'yi desteklemek için imdada yetişir. Bazı küçük farklara rağmen, crypto modülü için sağlam bir yedek birimdir. Örneğin, rastgele byte'ları oluşturmak için:

Ve karma:

Lodash#

Lodash, kullanışlılığı edeniyle birçok geliştiricinin favorisidir, ancak Edge Runtime bir hayranı değildir. Çözümümüz mü? Lodash fonksiyonlarını yerel JavaScript metotlarıyla değiştirdik, kodumuzu hem verimli hem de okunabilir tuttuk.

Çoğu Lodash fonksiyonunu değiştirmek Herkül'ün bir görevi olmasa da, biraz incelik gerektirdi. "once"ın kullanışlılığını kendi şeklimizde asıl yeniden oluşturduğumuza bir göz atalım:

Iron Session#

iron-session modülünün son versiyonu Edge Runtime dostu, bu yüzden yapmamız gereken sadece sürümümüzü güncellemek oldu. Bu kadar basit!

Edge Runtime'da "Response"un Karmaşıklıklarını Aşmak#

SDK'mızı Edge Runtime için uyarlamaya çalışırken karşılaştığımız başka bir zorluk, "Response" esnesindeki farklılıkları ele almaktı. Bu farklılıkları asıl aştığımıza bakalım:

Bir yanıtı manuel olarak oluşturma#

Node.js'teki gibi, Edge Runtime'da bir istek, karma bir yanıtla gelmez. Bu, onu new Response() çağırarak yarattığımız anlamına gelir, burada veri döndürme örneği:

"withIronSessionApiRoute"dan Vazgeçmek#

Edge Runtime'da, Response.body sadece okunabilir bir konudur. Bu, veri hazırlanmadan önce bir yanıt başlatamayacağımız anlamına geliyor. Sonuç olarak, güvendiğimiz "withIronSessionApiRoute" (ve diğer ara yazılımlar) yedeklenmek zorunda kaldı.

Ne değiştirdiğimizi anlamak için, withIronSessionApiRoute'un aslında e yaptığını önce açmalıyız:

1. Bir çerezin içine bakar, bir oturum esnesi oluşturur ve res e bağlar.
2. Eğer oturumda bir değişiklik varsa, otomatik olarak "set-cookie" başlığını res e ekler.

Yeni Edge Runtime ayarlarındayken bu işlevselliği asıl taklit ettik?

1. Okuma: Mevcut getIronSession fonksiyonunu kullandık. Buna boş ve sahte bir response verdikten sonra, ihtiyaç duyuldukça oturumu alır. Bu, req.session dan "get" metodunu değiştirdi.
2. Yazma: Veriyle birlikte upfront bir response hazırladık, sonra bu response örneği üzerinde getIronSession'u kullandık ve oturum esnesini elde ettik. Bu esneyi elimizde tuttuktan sonra, oturumu gerektiği gibi değiştirme imkanımız oldu.

Yönlendirme#

Edge Runtime'daki yönlendirme, yanıtlarımıza manuel olarak bir Location başlığı eklememizi gerektirdi.

Bir paket, iki runtime#

Bu yolculuğumuzda, hem Edge hem de Node.js runtime'larını desteklemek için tek bir pakete bağlı kalmaya karar verdik.

İşte#

eden

Edge için ayrı bir paket oluşturmayı düşündük, ancak çoğu kodumuzun iki runtime arasında paylaşıldığını, sadece birkaç satırın ayarlamaya ihtiyaç duyduğunu hızla fark ettik. Ayrıca, SDK'yı her iki runtime'da da pretty much aynı kullanıyoruz, yani birleşik bir paket tutmak en mantıklı oldu.

İşte#

e yaptık

Çaba sarf etmek yerine, mevcut paketi genişletmeye karar verdik. Paketin kökünde, eski "src" klasörünün yanına bir "edge" klasörü ekledik. Daha sonra, package.json dosyasını güncelledik, "exports"a yeni bir yol ekledik. Bu şekilde, hem Edge hem de Node.js runtime'ları, aynı paketin içinde, en az karışıklıkla uyum içinde yaşayabilirdi.

Sonuçlanıyor#

Next.js SDK'mızın tam kaynak kodunu burada kontrol edebilirsiniz.

Edge Runtime kucaklama yolculuğumuzu paylaşarak, benzer yolları keşfeden diğerlerine ilham vermeyi ve rehberlik etmeyi umuyoruz. Next.js SDK'mızla daha fazla güncelleme için bizi takip edin.