Nossa experiência adicionando o Edge Runtime ao SDK Next.js
O SDK Next.js da Logto agora oferece suporte ao Edge Runtime. Neste artigo, vamos compartilhar
ossa aventura, analisando os obstáculos que enfrentamos, como superamos e as coisas legais que aprendemos ao longo do caminho.
SijieDeveloper
Pare de perder semanas com autenticação de usuários
Lance aplicativos seguros mais rapidamente com o Logto. Integre a autenticação de usuários em minutos e concentre-se no seu produto principal.
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.
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:
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:
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!
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:
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:
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:
Ele dá uma olhada
o cookie, constrói um objeto de sessão e o associa a res.
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?
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.
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.
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.
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.
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.
