Nossa experiência adicionando o Edge Runtime ao SDK Next.js

Introdução#

O Edge Runtime se tornou um termo popular o cenário tecnológico, impulsionando funções dinâmicas e de baixa latência em plataformas que vão do AWS Lambda@Edge e Cloudflare Workers ao Vercel Edge. Enfatizando a sua importância, o Vercel mudou recentemente "experimental-edge" para "edge", sinalizando suporte oficial em seu popular framework Next.js.

Com osso SDK Next.js ganhando bastante adesão, ós da Logto pensamos, "Por que ão adicionar suporte ao Edge Runtime?" Então, arregaçamos as mangas e começamos. Neste artigo, vamos compartilhar ossa aventura, analisando os obstáculos que enfrentamos, como superamos e as coisas legais que aprendemos ao longo do caminho.

Transição de módulos e dependências para suporte ao Edge Runtime#

Trabalhar com o Edge Runtime apresenta alguns desafios únicos, principalmente porque ão suporta todos os módulos e dependências comumente usados em Node.js. Nos deparamos com esse problema com os módulos crypto, lodash e iron-session, ecessitando de algumas alternativas inovadoras.

Crypto#

Em um ambiente Node.js, o módulo crypto serve como um wrapper para funções criptográficas do OpenSSL. Infelizmente, o Edge Runtime ão oferece suporte. Mas ão se preocupe - a maioria dos Edge Runtimes vem para o resgate com o suporte para a API Web Crypto. Apesar de algumas pequenas diferenças, é uma alternativa sólida para o módulo crypto. Por exemplo, para gerar bytes aleatórios:

E para hashing:

Lodash#

Lodash é um favorito de muitos desenvolvedores por sua utilidade, mas o Edge Runtime ão é um fã. Nossa alternativa? Substituímos as funções Lodash por métodos JavaScript ativos, mantendo osso código eficiente e legível.

Embora a substituição da maioria das funções Lodash ão fosse uma tarefa hercúlea, exigiu algum trabalho. Vamos dar uma olhada em como recriamos a utilidade de "uma vez" à ossa maneira:

Iron Session#

A versão mais recente do módulo iron-session é compatível com o Edge Runtime, então, tudo que tivemos que fazer foi atualizar ossa versão. Simples assim!

Navegando#

as Intrincâncias de "Response" o Edge Runtime

Outro desafio que enfrentamos ao adaptar osso SDK para o Edge Runtime foi lidar com as diferenças o objeto "Response". Eis como superamos essas diferenças:

Criando uma resposta manualmente#

Diferentemente do Node.js, uma solicitação o Edge Runtime ão vem com uma resposta antecipada. Isso significa que temos que criá-la chamando new Response(), aqui está um exemplo de retorno de dados:

Deixando de lado "withIronSessionApiRoute"#

No Edge Runtime, o Response.body é algo somente leitura. Isso significa que ão poderíamos inicializar uma resposta antes que os dados fossem preparados. Como resultado, osso confiável "withIronSessionApiRoute" (junto com outros middleware) teve que ser deixado de lado.

Para entender o que substituímos, primeiro vamos entender o que withIronSessionApiRoute realmente faz:

1. Ele dá uma olhada o cookie, constrói um objeto de sessão e o associa a res.
2. Ele automaticamente anexa o cabeçalho "set-cookie" a res se houver uma mudança a sessão.

Então, como imitamos essa funcionalidade em osso ovo ambiente Edge Runtime?

1. Leitura: Utilizamos a função getIronSession existente. Ao fornecer um response vazio e falso, recupera a sessão conforme ecessário. Isso substituiu o método "get" de req.session.
2. Escrita: Preparamos um response com dados antecipadamente, depois usamos getIronSession esta instância de response para obter o objeto de sessão. Uma vez que tínhamos esse objeto em mãos, conseguíamos modificar a sessão conforme ecessário.

Redirecionando#

O redirecionamento o Edge Runtime os obrigou a adicionar manualmente um cabeçalho Location às ossas respostas.

Um pacote, dois runtimes#

Nesta ossa jornada, decidimos manter um único pacote para suportar tanto o Edge quanto o Node.js.

Aqui está o porquê#

Pensamos em criar um pacote separado para o Edge, mas rapidamente percebemos que era desnecessário. A maior parte do osso código era compartilhada entre os dois runtimes, com apenas algumas linhas precisando de ajustes. Além disso, o uso do SDK permanece praticamente o mesmo em ambos os runtimes, então, manter um pacote unificado fazia mais sentido.

Aqui está o que fizemos#

Em vez de duplicar esforços, decidimos expandir o pacote existente. Adicionamos uma pasta "edge" diretamente a raiz do pacote, ao lado da antiga pasta "src". Em seguida, atualizamos o arquivo package.json, adicionando um ovo caminho para as "exportações". Assim, os runtimes Edge e Node.js poderiam conviver harmoniosamente dentro do mesmo pacote, com o mínimo de problema.

Conclusão#

Você pode conferir o código fonte completo da parte edge do osso SDK Next.js aqui.

Ao compartilhar ossa jornada de abraçar o Edge Runtime, esperamos inspirar e orientar outros que buscam caminhos semelhantes. Fique ligado para mais atualizações com osso SDK Next.js.