Desenvolvimento extremamente rápido com estruturas full stack e a Cloudflare

Olá, desenvolvedores da web! No ano passado, lançamos uma série de melhorias que tornaram a implantação de aplicativos web na Cloudflare muito mais fácil e em resposta vimos um grande crescimento do Astro, do Next.js, Nuxt, Qwik, Remix, SolidStart, SvelteKit e outros aplicativos web hospedados na Cloudflare. Hoje anunciamos grandes melhorias em nossa integração com esses frameworks da web que facilitam o desenvolvimento de aplicativos sofisticados que usam nosso banco de dados SQL D1 , armazenamento de objetos R2 , modelos de IA e outros recursos poderosos da plataforma para desenvolvedores da Cloudflare.

No passado, se você quisesse desenvolver um aplicativo web baseado em framework com D1 e executá-lo localmente, você teria que criar uma versão de produção do seu aplicativo e então executá-lo localmente usando `wrangler pages dev`. Embora isso funcionasse, cada uma das suas iterações de código levaria segundos ou dezenas de segundos para aplicativos grandes. A iteração usando compilações de produção é simplesmente muito lenta, tira você do fluxo e não permite que você aproveite todas as otimizações DX nas quais os autores de frameworks trabalharam duro. Isso está mudando hoje.

Nosso objetivo é integrar os frameworks da web da maneira mais natural possível, sem que os desenvolvedores precisem aprender e adotar alterações significativas no fluxo de trabalho ou APIs personalizadas ao implantar seus aplicativos na Cloudflare. Não importa se você é um desenvolvedor Next.js, um desenvolvedor Nuxt ou prefere outro framework, agora você pode continuar usando o fluxo de trabalho de desenvolvimento local extremamente rápido que lhe é familiar e enviar seu aplicativo pela Cloudflare.

Todos os frameworks da web full stack vêm com um servidor de desenvolvimento (dev server) local que é personalizado para a estrutura e muitas vezes oferece uma excelente experiência de desenvolvimento, com apenas uma exceção: eles não são compatíveis de forma nativa com alguns recursos importantes da plataforma de desenvolvimento da Cloudflare, especialmente nossas soluções de armazenamento.

Então, até recentemente, você tinha que fazer uma escolha difícil. Você pode usar o dev server específico do framework para desenvolver seu aplicativo, mas abrir mão do acesso a muitos dos recursos da Cloudflare. Como alternativa, você poderia aproveitar ao máximo a plataforma da Cloudflare, incluindo vários recursos como D1 ou R2, mas teria que desistir de usar as ferramentas de desenvolvedor específicas do framework. Nesse caso, seu ciclo de iteração seria mais lento e levaria segundos em vez de milissegundos para você ver os resultados de suas alterações de código no navegador. Agora, não é mais. Vamos dar uma olhada.

Vamos criar um novo aplicativo usando C3 nossa CLI create-cloudflare. Podemos usar qualquer cliente npm de nossa escolha (alguém quer pnpm?), mas, para simplificar as coisas neste post, vamos nos ater ao cliente npm padrão. Para começar, basta executar:

$ npm create cloudflare@latest

Dê um nome para o seu aplicativo ou fique com o nome gerado aleatoriamente. Em seguida, selecione a categoria "site ou aplicativo web " e escolha um framework full stack de sua escolha. Somos compatíveis com muitos: Astro, Next.js, Nuxt, Qwik, Remix, SolidStart, e SvelteKit.

Como o C3 delega a estruturação do aplicativo à versão mais recente da CLI específica do framework, você estrutura o aplicativo exatamente como os autores do framework pretendiam, sem perder nenhum recurso ou opção do framework. Em seguida, o C3 adiciona ao seu aplicativo tudo o que é necessário para integrar e implantar na Cloudflare, para que você não precise configurá-lo sozinho.

Com nosso aplicativo estruturado, vamos fazer com que ele exiba uma lista de produtos armazenados em um banco de dados em apenas algumas etapas. Primeiro, adicionamos a configuração do nosso banco de dados ao nosso arquivo de configuração wrangler.toml:

[[d1_databases]]
binding = "DB"
database_name = "blog-products-db"
database_id = "XXXXXXXXXXXXXXXX"

Isso mesmo. Agora você pode configurar seus recursos vinculados por meio do arquivo wrangler.toml, mesmo para aplicativos full stack implantados no Pages. Vamos falar muito mais sobre as melhorias de configuração do Pages em um anúncio específico.

Agora vamos criar um arquivo schema.sql simples representando o esquema do nosso banco de dados:

CREATE TABLE products(product_id INTEGER PRIMARY KEY, name TEXT, price INTEGER);
INSERT INTO products (product_id, name, price) VALUES (1, 'Apple', 250), (2, 'Banana', 100), (3, 'Cherry', 375);

E inicializar nosso banco de dados:

$ npx wrangler d1 execute blog-products-db --local --file schema.sql

Observe que usamos o sinalizador –local do wrangler d1 execute para aplicar as alterações ao nosso banco de dados D1 local. Este é o banco de dados ao qual nosso dev server se conecta.

Em seguida, se você usar o TypeScript, informe o TypeScript sobre seu banco de dados executando:

$ npm run build-cf-types

Esse comando é pré-configurado para todos os aplicativos full stack criados via C3 e executa wrangler types para atualizar a interface do ambiente da Cloudflare, contendo todas as vinculações configuradas.

Agora podemos iniciar o dev server fornecido por seu framework por meio de um atalho útil:

$ npm run dev

Esse atalho iniciará o dev server do seu framework, seja ele alimentado por next dev, nitro ou vite.

Agora, para acessar nosso banco de dados e listar os produtos, podemos usar uma abordagem específica do framework. Por exemplo, em um aplicativo Next.js que usa o app router, poderíamos atualizar aplicativo/api/hello/route.ts com o seguinte:

const db = getRequestContext().env.DB;
 const productsResults = await db.prepare('SELECT * FROM products').all();
 return Response.json(productsResults.results);

Ou, em um aplicativo Nuxt, podemos criar um arquivo server/api/hello.ts e preenchê-lo com:

export default defineEventHandler(async ({ context }) => {
   const db = context.cloudflare.env.DB;
   const productsResults = await db.prepare('SELECT * FROM products').all();
   return productsResults.results;
 });

Supondo que o dev server do framework esteja sendo executado na porta 3000, você pode testar a nova rota da API em qualquer um dos frameworks navegando para http://localhost:3000/api/hello. Para simplificar, escolhemos as rotas de API nesses exemplos, mas o mesmo se aplica a qualquer rota de geração de IU.

Cada framework da web tem sua própria maneira de definir rotas e passar informações contextuais sobre a solicitação em todo o aplicativo, portanto, a forma como você acessa seus bancos de dados, armazenamentos de objetos e outros recursos dependerá de seu framework. Você pode ler nossos guias sobre framework full stack atualizados para saber mais:

• Guia Astro

• Guia Next.js

• Guia Nuxt

• Guia Qwik

• Guia Remix

• Guia SolidStart

• Guia SvelteKit

Agora que você sabe como acessar os recursos da Cloudflare no framework de sua escolha, tudo o mais que sabe sobre seu framework permanece o mesmo. Agora você pode desenvolver seu aplicativo localmente, usando o servidor de desenvolvimento otimizado para seu framework, que geralmente inclui suporte para substituição de módulo quente (HMR), ferramentas de desenvolvimento personalizadas, suporte à depuração aprimorado e muito mais, tudo isso enquanto ainda se beneficia das APIs e recursos específicos da Cloudflare. Todos ganham.

Para diminuir a latência de desenvolvimento e preservar as experiências personalizadas específicas do framework, precisávamos permitir que os frameworks da web e seus dev servers se integrassem com o Wrangler e o Miniflare de forma perfeita, quase invisível.

O Miniflare é um componente-chave nesse quebra-cabeça. É o nosso simulador local para recursos específicos da Cloudflare, que é alimentado pelo workerd, o nosso tempo de execução JavaScript (JS). Confiando no workerd, garantimos que as APIs JavaScript da Cloudflare sejam executadas localmente de forma a simular com fidelidade o nosso ambiente de produção. O problema é que os dev servers do framework já dependem do Node.js para executar o aplicativo, então trazer outro tempo de execução de JS para a mistura invalida muitas suposições sobre como esses dev servers foram arquitetados.

Nossa equipe, no entanto, teve uma abordagem interessante para preencher a lacuna entre esses dois tempos de execução JS. Nós a chamamos de API getPlatformProxy() , que agora faz parte do Wrangler e é superpotencializada pelo do Magic proxy do Miniflare. Essa API expõe um objeto proxy JS que se comporta como o objeto env do Workers usual, que contém todos os recursos vinculados. O objeto proxy permite que o código do Node.js invoque de forma transparente o código JavaScript em execução no workerd, bem como acesse APIs de tempo de execução específicas da Cloudflare.

Com essa ponte entre o Node.js e os tempos de execução do workerd, seu aplicativo agora pode acessar diretamente os simuladores da Cloudflare em D1, R2, KV e outras soluções de armazenamento, enquanto é executado em um servidor de desenvolvimento com tecnologia Node.js. Ou você pode até mesmo escrever um script Node.js para fazer o mesmo:

 import {getPlatformProxy} from 'wrangler';


 const {env} = getPlatformProxy();
 console.dir(env);
 const db = env.DB;


 // Now let’s execute a DB query that runs in a local D1 db
 // powered by miniflare/workerd and access the result from Node.js
 const productsResults = await db.prepare('SELECT * FROM products').all();
 console.log(productsResults.results);

Com a API getPlatformProxy() disponível, o trabalho restante foi atualizar todos os adaptadores de framework, plug-ins e, em alguns casos, os próprios framework para fazer uso dessa API. Agradecemos o apoio que recebemos das equipes de framework nessa jornada, especialmente o Alex da Astro, o pi0 da Nuxt, o Pedro da Remix, o Ryan da Solid, o Ben e o Rich da Svelte, além do nosso colaborador do projeto next-on-pages, James Anderson.

Embora a API getPlatformProxy() seja uma boa solução para muitos cenários, podemos fazer melhor. Se pudéssemos executar todo o aplicativo em nosso tempo de execução JS em vez de no Node.js, poderíamos simular com ainda mais fidelidade o ambiente de produção e reduzir o atrito para desenvolvedores e as surpresas de produção.

No mundo ideal, gostaríamos que você desenvolvesse no mesmo tempo de execução que implanta na produção, e isso só pode ser alcançado integrando o workerd diretamente nos dev servers de todos os frameworks, o que não é uma tarefa fácil considerando o número de frameworks e as diferenças entre eles.

No entanto, tivemos um pouco de sorte. Quando iniciamos esse esforço, percebemos que o Vite, um dev server popular usado por muitos frameworks full stack, ganhava uma adoção cada vez maior. Na verdade, o Remix só mudou para o Vite recentemente e confirmou a popularidade do Vite como a base comum para o desenvolvimento web atual.

Se o Vite tivesse suporte de primeira classe para executar um aplicativo full stack em um tempo de execução alternativo do JavaScript, poderíamos permitir que qualquer pessoa usando o Vite desenvolvesse seus aplicativos localmente com acesso completo à plataforma para desenvolvedores da Cloudflare . Chega de integrações personalizadas e soluções alternativas específicas de framework. Todos os recursos de um framework full stack, Vite e Cloudflare acessíveis a todos os desenvolvedores.

Parece bom demais para ser verdade? Talvez. Estamos muito entusiasmados em trabalhar com a equipe da Vite na proposta de ambientes Vite, que pode permitir exatamente isso. Essa proposta ainda está em evolução, então fique atento às atualizações.

Nosso objetivo é tornar a Cloudflare a melhor plataforma de desenvolvimento para desenvolvedores da web. Tornar seu aplicativo rápido e fácil com frameworks e ferramentas com as quais você já está familiarizado é uma grande parte da nossa história. Inicie sua jornada conosco executando um único comando:

$ npm create cloudflare@latest