A
ossa experiência de adicionar o Edge Runtime ao SDK Next.js
O SDK Next.js da Logto agora suporta Edge Runtime. Neste artigo, vamos compartilhar a
ossa aventura, olhando para os obstáculos que enfrentamos, como os superamos e as coisas interessantes que aprendemos ao longo do caminho.
SijieDeveloper
Pare de perder semanas com autenticação de utilizadores
Lance aplicações seguras mais rapidamente com o Logto. Integre a autenticação de utilizadores em minutos e concentre-se no seu produto principal.
Edge Runtime tornou-se um termo da moda
a paisagem tecnológica, impulsionando funções dinâmicas e de baixa latência em plataformas de AWS Lambda@Edge e Cloudflare Workers para Vercel Edge. Destacando sua importância, Vercel recentemente mudou "experimental-edge" para "edge", sinalizando apoio oficial em seu popular framework Next.js.
Com
osso SDK Next.js ganhando sério impulso,
ós da Logto pensámos, "Porque
ão adicionar suporte ao Edge Runtime?". Então, arregaçamos as mangas e mergulhamos. Neste artigo, vamos compartilhar a
ossa aventura, olhando para os obstáculos que enfrentamos, como os superamos, e as coisas interessantes que aprendemos ao longo do caminho.
Transição de módulos e dependências para suporte ao Edge Runtime#
Trabalhar com Edge Runtime apresenta alguns desafios únicos, principalmente porque ele
ão suporta todos os módulos e dependências frequentemente usadas em Node.js. Deparamo-nos com este problema com os módulos crypto, lodash e iron-session, o que
ecessitou de algumas soluções inovadoras.
Em um ambiente Node.js, o módulo crypto serve como um wrapper para as funções criptográficas do OpenSSL. Infelizmente, Edge Runtime
ão o suporta. Mas
ão se preocupe - a maioria dos Edge Runtimes vêm ao resgate com suporte para a Web Crypto API. Apesar de algumas pequenas diferenças, é uma substituição sólida para o módulo crypto. Por exemplo, para gerar bytes aleatórios:
O Lodash é um favorito entre muitos desenvolvedores por sua utilidade, mas Edge Runtime
ão é fã. Qual foi a
ossa solução? Substituímos as funções do Lodash pelos métodos JavaScript
ativos, mantendo o
osso código eficiente e legível.
Substituir a maioria das funções do Lodash
ão foi uma tarefa hercúlea, mas requeriu algum requinte. Vejamos como recriamos a utilidade de "once" à
ossa maneira:
a complexidade do objeto "Response"
o Edge Runtime
Outro desafio que enfrentamos ao adaptar o
osso SDK para Edge Runtime foi lidar com as diferenças
o objeto "Response". Veja como superamos essas diferenças:
Diferente do Node.js, um pedido
o Edge Runtime
ão vem junto com uma resposta. Isso significa que
ós temos que criá-lo chamando 'new Response()', aqui está um exemplo de retorno de dados:
No Edge Runtime, o 'Response.body' é somente leitura. Isso significa que
ós
ão pudemos inicializar uma resposta antes que os dados estivessem preparados. Como resultado,
osso confiável "withIronSessionApiRoute" (juntamente com outros middlewares) teve que ser reservado.
Para entender o que substituímos, vamos primeiro desempacotar o que 'withIronSessionApiRoute' realmente faz:
Ele dá uma olhadela
o cookie, constrói um objeto de sessão e o ata ao 'res'.
Ele automaticamente acrescenta o cabeçalho 'set-cookie' ao 'res' se houve uma mudança
a sessão.
Então, como reproduzimos esta funcionalidade
o
osso
ovo ambiente Edge Runtime?
Leitura: Usamos a função existente 'getIronSession'. Ao dar-lhe uma resposta vazia e falsa, ela recupera a sessão conforme
ecessário. Isto substituiu o método 'get' de 'req.session'.
Escrita: Preparamos uma 'response' com dados à frente, depois usamos 'getIronSession'
esta instância 'response' para obter o objeto de sessão. Uma vez que tivemos este objeto em mãos, pudemos modificar a sessão conforme
ecessário.
Pensamos em criar um pacote separado para o Edge, mas rapidamente percebemos que era desnecessário. A maioria do
osso código foi compartilhado entre os dois runtimes, com apenas um punhado de linhas precisando de ajustes. Além disso, o uso do SDK permanece praticamente o mesmo em ambos os runtimes, por isso manter um pacote unificado fazia mais sentido.
Em vez de duplicar esforços, decidimos expandir o pacote existente. Adicionamos uma pasta "edge" logo
a raiz do pacote, ao lado da antiga pasta "src". Então, atualizamos o arquivo package.json, adicionando um
ovo caminho para "exports". Desta forma, tanto os runtimes Edge quanto Node.js poderiam viver em harmonia
o mesmo pacote, com o mínimo de confusão.
Ao compartilhar
ossa jornada de abraçar o Edge Runtime, esperamos inspirar e orientar outros que exploram caminhos semelhantes. Fique atento para mais atualizações com
osso SDK Next.js.
