Todos nós já passamos pela frustração de carregar sites com lentidão ou de um aplicativo que parece travar quando precisa chamar uma API para uma atualização. Qualquer coisa que não seja instantânea e sua mente vaga para outra coisa...

Uma maneira de acelerar as coisas é trazer os recursos para o mais perto possível do usuário. É isso que a Cloudflare tem feito com a computação, executando em milissegundos da maior parte da população mundial. Mas, por mais contraintuitivo que possa parecer, às vezes trazer a computação para mais perto do usuário pode realmente desacelerar os aplicativos. Se seu aplicativo precisa se conectar a APIs, bancos de dados ou outros recursos que não estejam localizados perto do usuário final, pode ser melhor executar o aplicativo perto dos recursos em vez de do usuário.

Assim, hoje temos o prazer de anunciar o Smart Placement for Workers e o Pages Functions, que tornam todas as interações o mais rápidas possíveis. Com o Smart Placement, a Cloudflare leva a computação sem servidor para a Supercloud, movendo os recursos de computação para locais ideais para acelerar os aplicativos. A melhor parte é que é totalmente automático, sem a necessidade de nenhuma entrada extra (como a temida "região").

O Smart Placement já está disponível, em beta aberto, para todos os clientes do Workers e do Pages.

Confira nossa demonstração sobre como o Smart Placement funciona.

A rede anycast da Cloudflare foi criada para processar solicitações instantaneamente e próximo ao usuário. Como desenvolvedores, é isso que torna o Cloudflare Workers, nossa oferta de computação sem servidor tão atraente. Os concorrentes são limitados por "regiões", enquanto o Workers funciona em todos os lugares, portanto, temos uma região: a Terra. As solicitações tratadas inteiramente pelo Workers podem ser processadas ali mesmo, sem precisar atingir um servidor de origem.

Embora esse conceito de sem servidor tenha sido originalmente considerado para tarefas leves, a computação sem servidor vem passando por uma mudança nos últimos anos. Está sendo usada para substituir a arquitetura tradicional, que depende de servidores de origem e de uma infraestrutura autogerenciada, ao invés de simplesmente aumentá-la. Estamos vendo cada vez mais casos desses com usuários do Workers e do Pages.

Com a mudança para sem servidor e a criação aplicativos inteiros no Workers, surge a necessidade de dados. O armazenamento de informações sobre ações ou eventos anteriores permite criar aplicativos interativos personalizados. Digamos que você precise criar perfis de usuário, armazenar em qual página um usuário parou, quais SKUs um usuário tem em seu carrinho tudo isso é mapeado para pontos de dados usados para manter o estado. Serviços de back-end como bancos de dados relacionais, armazenamentos de chave-valor, armazenamento de blobs e APIs permitem criar aplicativos com estado.

Temos nosso próprio pacote crescente de ofertas de armazenamento: Workers KV, Durable Objects, D1, R2. À medida que amadurecemos nossos produtos de dados, pensamos profundamente em suas interações com o Workers, para que você não precise fazer isso. Por exemplo, outra abordagem que tem melhor desempenho em alguns casos é mover o armazenamento, em vez de a computação, para perto dos usuários. Se você estiver usando o Durable Objects para criar um jogo em tempo real, podemos mover o Durable Objects para minimizar a latência para todos os usuários.

Nosso objetivo para o estado futuro é que você defina modo = "inteligente" e nós avaliamos o posicionamento ideal de todos os seus recursos sem a necessidade de configuração adicional.

Hoje, o principal caso de uso do Smart Placement é quando você usa serviços que não são da Cloudflare, como bancos de dados externos ou APIs de terceiros para seus aplicativos.

Muitos serviços de back-end, sejam serviços auto-hospedados ou gerenciados, são centralizados, o que significa que os dados são armazenados e gerenciados em um único local. Seus usuários são globais e o Workers é global, mas seu back-end é centralizado.

Se seu código faz várias solicitações aos seus serviços de back-end, elas podem cruzar o mundo várias vezes, causando um grande impacto no desempenho. Alguns serviços oferecem replicação de dados e armazenamento em cache, o que ajuda a melhorar o desempenho, mas também apresenta compensações, como consistência de dados e custos mais altos, que devem ser ponderados em relação ao seu caso de uso.

A rede da Cloudflare está a cerca de 50 ms de 95% da população mundial conectada. Invertendo isso, também estamos muito próximos dos seus serviços de back-end.

Vamos entender como mover a computação para perto dos serviços de back-end pode diminuir a latência do aplicativo analisando um exemplo:

Digamos que você tenha um usuário em Sydney, Austrália, que está acessando um aplicativo em execução no Workers. Esta aplicativo faz três viagens de ida e volta a um banco de dados localizado em Frankfurt, na Alemanha, para atender à solicitação do usuário.

Intuitivamente, você pode adivinhar que o gargalo será o tempo que o Worker leva para realizar várias viagens de ida e volta ao seu banco de dados. Em vez de o Worker ser invocado perto do usuário, o que aconteceria se ele fosse invocado em um data center mais próximo do banco de dados?

Vamos testar isso.

Medimos a duração de uma solicitação do Worker sem o Smart Placement e a comparamos com uma com o Smart Placement ativado. Para ambos os testes, enviamos 3.500 solicitações de Sydney para um Worker que faz três viagens de ida e volta para uma instância Upstash (nível gratuito) localizada em eu-central-1 (Frankfurt).

Os resultados são claros. Nesse exemplo, mover o Worker para perto do back-end melhorou o desempenho do aplicativo de 4 a 8 vezes.

Como desenvolvedor, você deve se concentrar no que faz de melhor, criar aplicativos, sem precisar se preocupar com as decisões de rede que tornam seu aplicativo mais rápido.

A Cloudflare tem um ponto de vista privilegiado: nossa rede reúne inteligência em torno dos caminhos ideais entre usuários, data centers da Cloudflare e servidores de back-end temos muita experiência nessa área com o Argo Smart Routing. O Smart Placement leva esses fatores em consideração para colocar automaticamente seu Worker no melhor local para minimizar a duração geral da solicitação.

Então, como funciona o Smart Placement?

O Smart Placement pode ser habilitado para cada Worker na guia "Configurações" ou no seu arquivo wrangler.toml:

[placement]
mode = "smart"

Depois de ativar o Smart Placement no seu Worker ou no Pages Function, o algoritmo do Smart Placement analisa as solicitações de busca (também conhecidas como subsolicitações) que o Worker está fazendo em tempo real. Em seguida, ele as compara com os dados de latência agregados pela nossa rede. Se detectarmos que, em média, seu Worker faz mais de uma subsolicitação a um recurso de back-end, seu Worker será invocado automaticamente a partir do data center ideal .

Existem alguns serviços de back-end que, por um bom motivo, não são considerados pelo algoritmo do Smart Placement:

• Serviços distribuídos globalmente: se os serviços com os quais seu Worker se comunica estiverem distribuídos geograficamente em muitas regiões, o Smart Placement não será uma boa opção. Nós os excluímos automaticamente da otimização do Smart Placement.

• Analytics ou serviços de logging: as solicitações de analytics ou serviços de logging não precisam estar no caminho crítico do seu aplicativo. WaitUntil() deve ser usado para que a resposta aos usuários não seja bloqueada ao instrumentar seu código. Como o WaitUntil() não afeta a duração da solicitação do ponto de vista do usuário, eliminamos automaticamente os serviços de analytics/logging da otimização do Smart Placement.

Consulte nossa documentação para obter uma lista de serviços não considerados pelo algoritmo do Smart Placement.

Assim que o Smart Placement for ativado, você poderá ver uma nova guia "Duração da solicitação" no seu Worker. Encaminhamos 1% das solicitações sem o Smart Placement ativado para que você possa observar o impacto na duração da solicitação.

E sim, é realmente fácil assim.

Experimente o Smart Placement verificando nossa demonstração (é muito divertido brincar com ele). Para saber mais, visite nossa documentação para desenvolvedores.

Estamos apenas no começo! Temos muitas ideias sobre como podemos melhorar o Smart Placement:

• Suporte para calcular a localização ideal quando o aplicativo usa vários back-ends

• Posicionamento ajustado (por exemplo, se o Worker usa vários back-ends, dependendo do caminho Calculamos o posicionamento ideal por caminho em vez de por Worker)

• Suporte para conexões baseadas em TCP

Queremos ouvir a sua opinião. Se você tiver comentários ou solicitações de recursos, entre em contato pelo Discord para desenvolvedores da Cloudflare.

Alguns meses depois, quando anunciamos que o Pages era uma plataforma full stack, em novembro de 2021, essa visão se tornou realidade. Criar uma plataforma de desenvolvimento apenas para sites estáticos não foi o fim da história do Pages e, com o Cloudflare Workers já fazendo parte do nosso ecossistema, sabíamos que estávamos diante de um potencial inexplorado. Com a introdução do Pages Functions, capacitamos os desenvolvedores a usar qualquer site estático e adicionar facilmente conteúdo dinâmico com o poder do Cloudflare Workers.

No ano passado, desde que o Functions entrou em beta aberto, exploramos quais tipos de recursos full stack os desenvolvedores buscavam para seus projetos e ajustamos a experiência do Functions para a forma como está hoje.

Temos o prazer de anunciar que o Pages Functions já está em disponibilidade geral.

Embora sejam chamadas de “Functions” no contexto do Pages, essas funções executadas na rede da Cloudflare são o Cloudflare Workers “disfarçado”. O Pages aproveita o poder e a escalabilidade do Workers e especializa os recursos para se alinharem com a experiência do Pages que nossos usuários conhecem e amam.

Com o Functions, você pode criar possibilidades de funcionalidade dinâmica para adicionar ao seu site como, integrar soluções de armazenamento, conectar serviços de terceiros, usar a renderização do lado do servidor com suas estruturas de full stack favoritas e muito mais. À medida que o Pages Functions abre suas portas para o tráfego de produção, vamos explorar alguns dos recursos interessantes que aprimoramos e adicionamos nesta versão.

Gosta de codificar? Nós cuidamos da infraestrutura e deixamos você fazer isso.

Simplesmente escreva uma função JavaScript/Typescript e insira em um diretório de funções enviando seu código para seu provedor Git. Nosso sistema de CI, extremamente rápido, cria seu código e o implanta junto com seus ativos estáticos.

Prefere desenvolver você mesmo? Tem um provedor Git especial que ainda não é compatível com o Pages? Sem problemas. Depois de inserir o Functions na sua pasta de funções, você pode criar com suas ferramentas de CI preferidas e, em seguida, carregar seu projeto no Pages para ser implantado.

Durante a versão beta, aprendemos que você e suas equipes valorizam a visibilidade acima de tudo. Assim como no Cloudflare Workers, criamos uma maneira simples de você observar suas funções enquanto elas processam solicitações. Quanto mais rápido você entende um problema, mais rápido pode reagir.

Agora você pode visualizar facilmente os registros do Functions "seguindo" seus registros. Para obter informações básicas, como resultado e IP de solicitação, você pode navegar até o painel do Pages para obter os registros relevantes.

Para filtros mais específicos, você pode usar

para receber um feed ao vivo do console e registros de exceção para cada solicitação que o Functions recebe.

wrangler pages deployment tail

No painel, o Pages agrega dados no Functions na forma de métricas de sucesso/erro de solicitações e status de invocação. Você pode consultar seu painel de métricas não apenas para entender melhor seu uso por projeto, mas também para obter uma verificação de pulso sobre a integridade do Functions, capturando volumes de sucesso/erro.

Quer se tornar realmente full stack? Sabemos que encontrar uma solução de armazenamento que atenda às suas necessidades e ao seu ecossistema não é uma tarefa fácil. Mas, pode ser.

Com o Functions, você pode aproveitar nossa ampla gama de produtos de armazenamento, incluindo Workers KV, Durable Objects, R2, D1 e, muito em breve, Queues e Workers Analytics Engine. Basta criar seu namespace, bucket ou banco de dados e adicionar sua vinculação no painel do Pages para colocar seu site full stack em funcionamento com apenas alguns cliques.

Desde a inserção de um sistema de comentários rápidos até a implantação de sua própria autenticação e a criação de sites de comércio eletrônico com base em banco de dados, a integração com produtos existentes em nossa plataforma para desenvolvedores desbloqueia um conjunto exponencial de casos de uso para seu site.

Além de adicionar variáveis de ambiente que estão disponíveis para o seu projeto em tempo de desenvolvimento e em tempo de execução, agora você também pode adicionar “segredos” ao seu projeto. Essas são variáveis de ambiente criptografadas que não podem ser visualizadas por nenhuma interface de painel e são um ótimo local para dados confidenciais, como tokens de API ou senhas.

Nosso objetivo com o Pages é sempre atender você onde estiver quando se trata das ferramentas que adora usar. Durante esse período beta, também notamos alguns padrões consistentes na forma como você estava empregando o Functions para integrar-se a serviços comuns de terceiros. Os Pages Plugins, nossos snippets de código prontos, oferecem uma experiência plug and play para você construir o ecossistema de sua escolha em torno de seu aplicativo.

Na essência, o Pages Plugins é uma parte reutilizável, e personalizável, de código de tempo de execução que pode ser incorporado em qualquer lugar dentro de seu aplicativo Pages. É um Pages Functions “combinável”, concedendo ao Plugins todo o poder do Functions (ou seja, Workers), incluindo a capacidade de configurar middleware, rotas parametrizadas e ativos estáticos.

Com o Pages Plugins, você pode se integrar a uma infinidade de aplicativos de terceiros, incluindo Sentry, Honeycomb, Stytch, MailChannels e muitos mais.

Temos o ideal de ajudar os desenvolvedores em qualquer ponto que estejam, isso também se reflete na forma de frameworks Javascript. Como grandes apoiadores não apenas de estruturas amplamente adotadas, mas também de estruturas emergentes, nossa equipe trabalha com uma infinidade de autores de estruturas para criar oportunidades para você experimentar sua nova tecnologia e implantar no Pages imediatamente.

Recentemente, anunciamos nossa compatibilidade com aplicativos Next.js que aceitam o Edge Runtime. Hoje, temos o prazer de anunciar que agora somos compatíveis com o Next.js 13. O Next.js 13 traz alguns paradigmas modernos mais solicitados para a estrutura do Next.js, incluindo roteamento aninhado, componentes de servidor do React 18 e streaming.

Prefere outra estrutura? Sem problemas.

Use a full stack no Pages para aproveitar a renderização do lado do servidor (SSR) com uma das muitas outras estruturas oficialmente compatíveis, como Remix, SvelteKit, QwikCity, SolidStart, Astro e Nuxt. Você pode conferir nosso post no blog sobre compatibilidade com SSR no Pages e como começar a usar algumas dessas estruturas.

Embora o Pages Functions seja desenvolvido no Workers, entendemos que, superficialmente, eles não são exatamente a mesma coisa. No entanto, para os usuários que talvez já usem o Workers e queiram experimentar o Cloudflare Pages, temos um caminho direto para começar rapidamente.

Se você já tem o Workers e quer uma maneira fácil de obter uma full stack no Pages, pode usar o “modo avançado” do Pages Functions. Gere um módulo ES no Workers chamado _worker.js no diretório de saída do seu projeto e implante.

Isso pode ser muito útil se você for um autor de estrutura ou talvez tenha um caso de uso mais complexo que não se encaixe em nosso roteador baseado em arquivos.

Assim, hoje, ao anunciarmos o Functions com disponibilidade geral, estamos entusiasmados em permitir que seu tráfego seja ampliado. Durante o período de beta aberto, determinamos um limite diário de 100 mil solicitações gratuitas por dia para permitir que você experimentasse o recurso. Hoje, as 100 mil solicitações por dia continuam sendo o limite gratuito, mas agora você pode pagar para ter acesso ilimitado.

Como o Functions é apenas um Workers “especial”, a partir deste comunicado você vai começar a ver o uso do Functions mostrado em sua fatura na assinatura do Workers pago ou através de seu contrato do Workers Enterprise. Assim como no Workers, em um plano pago, você tem a opção de escolher entre nossos dois modelos de uso, Bundled e Unbound, e vai ser cobrado de acordo com sua escolha.

Ao manter o Pages na marca como o “presente para a internet” da Cloudflare, você vai receber solicitações ilimitadas de ativos estáticos gratuitos e será cobrado somente pelas solicitações dinâmicas. Você pode ler mais sobre como o faturamento do Functions funciona em nossa documentação.

Para começar a improvisar, acesse os documentos do Pages Functions e confira nosso post no blog sobre algumas das melhores estruturas a serem usadas para implantar seu primeiro aplicativo full stack. Ao começar a desenvolver seus projetos, informe-nos no canal #functions em Pages do nosso Discord para desenvolvedores da Cloudflare. Divirta-se desenvolvendo!

Introdução

Existem muitas maneiras de armazenar dados em seus aplicativos. Por exemplo, nos aplicativos do Cloudflare Workers, temos o Workers KV para armazenamento de valor-chave e o Durable Objects para armazenamento coordenado em tempo real sem comprometer a consistência. Fora do ecossistema da Cloudflare, você também pode conectar outras ferramentas como NoSQL e bancos de dados gráficos.

Mas, às vezes, você quer SQL. Os índices nos permitem recuperar dados rapidamente. As junções nos permitem descrever relacionamentos complexos entre tabelas diferentes. O SQL descreve declarativamente como os dados de nosso aplicativo são validados, criados e consultados de maneira eficiente.

O D1 foi lançado hoje em alfa aberto e, para comemorar, quero compartilhar minha experiência na criação de aplicativos com o D1: especificamente, como começar e por que estou animado com o D1 se juntando à longa lista de ferramentas que você pode usar para criar aplicativos na Cloudflare.

O D1 é notável porque agrega valor instantâneo aos aplicativos sem precisar de novas ferramentas ou sair do ecossistema da Cloudflare. Usando o Wrangler, podemos fazer o desenvolvimento local em nossos aplicativos do Workers e, com a adição do D1 ao Wrangler, também podemos desenvolver aplicativos com estado apropriados localmente agora. Então, quando é hora de implantar o aplicativo, o Wrangler nos permite acessar e executar comandos para seu banco de dados D1, bem como para sua própria API.

Nesta postagem do blog, mostro como usar o D1 para adicionar comentários a um blog estático. Para fazer isso, vamos criar um novo banco de dados D1 e uma API JSON simples que permite a criação e recuperação de comentários.

Como mencionei, separar o D1 do próprio aplicativo, uma API e um banco de dados que permanece separado do site estático, nos permite abstrair as partes estáticas e dinâmicas do nosso site uma da outra. Também facilita a implantação do nosso aplicativo: vamos implantar o front-end no Cloudflare Pages e a API com tecnologia D1 no Cloudflare Workers.

Primeiro, adicionamos uma API básica no Workers. Crie um novo diretório e dentro dele um novo projeto Wrangler:

Neste exemplo, usaremos o Hono, um framework estilo Express.js, para criar nossa API rapidamente. Para usar o Hono neste projeto, instale-o usando o NPM:

$ mkdir d1-example && d1-example
$ wrangler init

Em seguida, em src/index.ts, inicializamos um novo aplicativo Hono e definimos alguns endpoints - GET /API/posts/:slug/comments e POST /get/api/:slug/comments.

$ npm install hono

Agora vamos criar um banco de dados D1. No Wrangler 2, há suporte para o subcomando wrangler d1, que permite criar e consultar seus bancos de dados D1 diretamente da linha de comando. Assim, por exemplo, podemos criar um novo banco de dados com um único comando:

import { Hono } from 'hono'
import { cors } from 'hono/cors'

const app = new Hono()

app.get('/api/posts/:slug/comments', async c => {
  // do something
})

app.post('/api/posts/:slug/comments', async c => {
  // do something
})

export default app

Com nosso banco de dados criado, podemos pegar o ID do nome do banco de dados e associá-lo a uma vinculação dentro do wrangler.toml, arquivo de configuração do wrangler. As vinculações nos permitem acessar os recursos da Cloudflare, como bancos de dados D1, namespaces KV e buckets R2, usando um nome de variável simples em nosso código. Abaixo, criaremos o DB de vinculação e o usaremos para representar nosso novo banco de dados:

$ wrangler d1 create d1-example

Observe que nesta diretiva, o campo [[d1_databases]], atualmente requer uma versão beta do wrangler. Você pode instalá-lo para o seu projeto usando o comando npm install -D wrangler/beta.

[[ d1_databases ]]
binding = "DB" # i.e. available in your Worker on env.DB
database_name = "d1-example"
database_id = "4e1c28a9-90e4-41da-8b4b-6cf36e5abb29"

Com o banco de dados configurado em nosso wrangler.toml, podemos começar a interagir com ele a partir da linha de comando e dentro de nossa função do Workers.

Primeiro, você pode emitir comandos SQL diretos usando wrangler d1 execute:

Você também pode transferir um arquivo SQL. Perfeito para a propagação inicial de dados em um único comando. Crie src/schema.sql, que vai produzir uma nova tabela de comments para o nosso projeto:

$ wrangler d1 execute d1-example --command "SELECT name FROM sqlite_schema WHERE type ='table'"
Executing on d1-example:
┌─────────────────┐
│ name │
├─────────────────┤
│ sqlite_sequence │
└─────────────────┘

Com o arquivo criado, execute o arquivo de esquema no banco de dados D1 transferindo-o com o sinalizador --file:

drop table if exists comments;
create table comments (
  id integer primary key autoincrement,
  author text not null,
  body text not null,
  post_slug text not null
);
create index idx_comments_post_id on comments (post_slug);

-- Optionally, uncomment the below query to create data

-- insert into comments (author, body, post_slug)
-- values ("Kristian", "Great post!", "hello-world");

Criamos um banco de dados SQL com apenas alguns comandos e o semeamos com os dados iniciais. Agora podemos adicionar uma rota à nossa função do Workers para recuperar dados desse banco de dados. Com base em nossa configuração wrangler.toml, o banco de dados D1 agora pode ser acessado por meio da vinculação do DB. Em nosso código, podemos usar a vinculação para preparar instruções SQL e executá-las, por exemplo, para recuperar comentários:

$ wrangler d1 execute d1-example --file src/schema.sql

Nesta função, aceitamos um parâmetro de consulta de URL slug e configuramos uma nova instrução SQL onde selecionamos todos os comentários com um valor post_slug correspondente ao nosso parâmetro de consulta. Podemos então retorná-lo como uma resposta JSON simples.

app.get('/api/posts/:slug/comments', async c => {
  const { slug } = c.req.param()
  const { results } = await c.env.DB.prepare(`
    select * from comments where post_slug = ?
  `).bind(slug).all()
  return c.json(results)
})

Até agora, criamos acesso somente leitura aos nossos dados. Mas "inserir" valores no SQL também é possível. Então, vamos definir outra função que permite fazer POST em um endpoint para criar um novo comentário:

Neste exemplo, criamos uma API de comentários para alimentar um blog. Para ver a fonte dessa API de comentários com tecnologia D1, você pode acessar cloudflare/templates/worker-d1-api.

app.post('/API/posts/:slug/comments', async c => {
  const { slug } = c.req.param()
  const { author, body } = await c.req.json<Comment>()

  if (!author) return c.text("Missing author value for new comment")
  if (!body) return c.text("Missing body value for new comment")

  const { success } = await c.env.DB.prepare(`
    insert into comments (author, body, post_slug) values (?, ?, ?)
  `).bind(author, body, slug).run()

  if (success) {
    c.status(201)
    return c.text("Created")
  } else {
    c.status(500)
    return c.text("Something went wrong")
  }
})

Uma das coisas mais empolgantes do D1 é a oportunidade de aumentar os aplicativos ou sites existentes com dados relacionais dinâmicos. Como ex-desenvolvedor da Ruby on Rails, uma das coisas que mais sinto falta dessa estrutura no mundo do JavaScript e das ferramentas de desenvolvimento sem servidor é a capacidade de criar rapidamente aplicativos completos orientados por dados sem precisar ser um especialista em gerenciamento de infraestrutura de banco de dados. Com o D1 e seu acesso fácil aos dados baseados em SQL, podemos criar verdadeiros aplicativos orientados por dados sem comprometer o desempenho ou a experiência do desenvolvedor.

Essa mudança corresponde muito bem ao advento de sites estáticos nos últimos anos, usando ferramentas como Hugo ou Gatsby. Um blog criado com um gerador de site estático, como o Hugo, tem um desempenho incrível, ele é criado em segundos com ativos pequenos.

Mas ao trocar uma ferramenta como o WordPress por um gerador de sites estáticos, você perde a oportunidade de adicionar informações dinâmicas ao seu site. Muitos desenvolvedores corrigiram esse problema adicionando mais complexidade aos seus processos de desenvolvimento: buscar e recuperar dados e gerar páginas usando esses dados como parte do desenvolvimento.

Essa adição de complexidade no processo de criação tenta corrigir a falta de dinamismo nos aplicativos, mas ainda não é genuinamente dinâmico. Em vez de poder recuperar e exibir novos dados à medida que são criados, o aplicativo é reconstruído e reimplantado sempre que os dados são alterados para que pareçam uma representação em tempo real e dinâmica dos dados. Seu aplicativo pode permanecer estático e os dados dinâmicos vão residir geograficamente próximos aos usuários de seu site, acessíveis por meio de uma API expressiva e consultável.

Há cerca de quatro anos, anunciamos o Cloudflare Workers, uma plataforma sem servidor que é executada diretamente na borda.

Ao longo desta semana, vamos falar sobre as muitas formas pelas quais a Cloudflare está ajudando a tornar mais rápidos os aplicativos que já existem na web. Mas se hoje for o dia em que você decidir dar vida à sua ideia, desenvolver seu projeto na borda da Cloudflare e implantá-lo diretamente nos tubos da internet é a melhor maneira de garantir que seu aplicativo sempre seja rápido, para todos os usuários, independentemente da sua localização.

Já se passaram alguns anos desde que falamos sobre a comparação entre o Cloudflare Workers e outras plataformas sem servidor quando se trata de desempenho, então decidimos que era hora de uma atualização. Embora a maior parte do nosso trabalho na plataforma Workers nos últimos anos tenha sido tornar a plataforma mais poderosa: introduzindo novos recursos, APIs, armazenamento, depuração e ferramentas de observabilidade, o desempenho não foi negligenciado.

Hoje, o Workers está 30% mais rápido do que há três anos no P90. Também está 210% mais rápido que o Lambda@Edge e 298% mais rápido que o Lambda.

E também eliminamos partidas a frio.

No passado, executei centenas de benchmarks de desempenho entre CDNs e a fórmula é simples: usamos uma ferramenta chamada Catchpoint, que faz solicitações de nós de todo o mundo para o mesmo ativo e envia relatórios sobre o tempo que levou para cada um retornar uma resposta.

Medir o desempenho sem servidor é um pouco diferente. Como o que você está comparando é o desempenho de computação, em vez de um ativo estático, queríamos garantir que todas as funções executassem a mesma operação.

Em nosso blog de 2018 sobre testes de velocidade, fizemos com que cada função simplesmente retornasse ao horário atual. Para os fins deste teste, os produtos "sem servidor" que não conseguiram atender aos critérios mínimos para realizar essa tarefa foram desqualificados. Os produtos sem servidor usados nesta rodada de testes executaram a mesma função, com complexidade computacional idêntica, para garantir resultados precisos e justos.

Também é importante observar o que estamos medindo. O motivo pelo qual o desempenho é importante é que ele afeta a experiência dos clientes finais reais. Não importa qual seja a origem da latência: DNS, congestionamento de rede, inicializações a frio... o cliente não se importa com a origem, mas sim em perder tempo esperando que seu aplicativo seja carregado.

Portanto, é importante medir o desempenho em termos da experiência do usuário final, de ponta a ponta, e é por isso que usamos referências globais para medir o desempenho.

O resultado abaixo mostra os testes executados em 50 nós em todo o mundo, na América do Norte, América do Sul, Europa, Ásia e Oceania.

Azul: Cloudflare Workers Vermelho: Lambda@Edge Verde: Lambda

(Link para os resultados).

Como você pode ver pelos resultados, não importa onde os usuários estejam no mundo, quando se trata de velocidade, o Workers pode garantir a melhor experiência para os clientes.

No caso do Workers, obter o melhor desempenho em todo o mundo não requer nenhum esforço adicional por parte dos desenvolvedores. Os desenvolvedores não precisam fazer nenhum balanceamento de carga adicional ou configuração de regiões. Cada implantação é ativada instantaneamente na extensa rede de borda da Cloudflare.

Mesmo que você não esteja tentando se dirigir a um público global e sua base de clientes esteja convenientemente localizada na costa leste dos Estados Unidos, o Workers é capaz de garantir a resposta mais rápida a todas as solicitações.

Acima, temos os resultados de Washington, DC, o mais próximo possível de us-east-1. E, novamente, sem nenhuma otimização, o Workers é 34% mais rápido.

Por quê?

Além do desempenho do próprio código, do ponto de vista do usuário final, o desempenho de um aplicativo sem servidor é fundamentalmente uma função de duas variáveis: a distância que um aplicativo é executado do usuário e o tempo que o próprio tempo de execução leva para processar. A percepção de que a distância do usuário está se tornando um gargalo cada vez maior para o desempenho dos aplicativos está fazendo com que muitos fornecedores de sem servidor se aprofundem cada vez mais na borda. A execução de aplicativos na borda, mais perto do usuário final, aumenta o desempenho. À medida que o 5G fica on-line, essa tendência só continuará a acelerar.

No entanto, muitos fornecedores de nuvem no espaço sem servidor se deparam com um problema crítico ao abordar a questão quando competem por um desempenho mais rápido. E isso é: a arquitetura legada que eles estão usando para construir suas ofertas não funciona bem com as limitações inerentes da borda.

Como o objetivo por trás do modelo sem servidor é abstrair intencionalmente a arquitetura subjacente, nem todos entendem com clareza como provedores de nuvem legados, como o AWS, criaram ofertas sem servidor como o Lambda. Os provedores de nuvem legados oferecem ofertas sem servidor, criando um processo conteinerizado para seu código. O provedor escala automaticamente todos os diferentes processos em segundo plano. Toda vez que um contêiner é ativado, todo o tempo de execução da linguagem é ativado com ele, não apenas o seu código.

Para ajudar a abordar o primeiro gráfico, que mede o desempenho global, os fornecedores estão tentando se afastar de sua arquitetura grande e centralizada (alguns data centers grandes) para um mundo distribuído na borda (um número maior de data centers menores em todo o mundo mundo) para diminuir a distância entre aplicativos e usuários finais. Mas há um problema com sua abordagem: data centers menores significam menos máquinas e menos memória. Cada vez que os fornecedores buscam uma estratégia de pequenos, mas muitos data centers, para operar mais perto da borda, a probabilidade de ocorrer uma inicialização a frio em qualquer processo individual aumenta.

Isto cria efetivamente um teto de desempenho para aplicativos sem servidor em arquiteturas baseadas em contêineres. Se os fornecedores legados com pequenos data centers moverem seu aplicativo para mais perto da borda (e dos usuários), haverá menos servidores, menos memória e é mais provável que um aplicativo precise de uma inicialização a frio. Para reduzir a probabilidade disso, eles voltaram a usar um modelo mais centralizado, mas isso significa executar seus aplicativos em um dos poucos grandes data centers centralizados. Esses data centers centralizados maiores, por definição, quase sempre estarão mais distantes de seus usuários.

Você pode ver isso em ação no gráfico acima, observando os resultados dos testes executados no Lambda@Edge. Apesar da proximidade reduzida com o usuário final, o desempenho do p90 é mais lento do que o do Lambda, pois os contêineres precisam acelerar com mais frequência.

Arquiteturas sem servidor construídas em contêineres podem se mover para cima e para baixo na fronteira, mas, em última análise, não há muito que possam fazer para mudar essa curva da fronteira.

O Workers foi projetado desde o início para ser um modelo sem servidor que prioriza a borda. Como a Cloudflare começou com uma rede de borda distribuída, em vez de tentar forçar a computação de grandes data centers centralizados para a borda, trabalhar com essas restrições nos forçou a inovar.

Em um de nossos posts anteriores no blog, discutimos como essa inovação se traduziu em uma nova mudança de paradigma com a arquitetura do Workers sendo construída em isolados V8 leves que podem ser ativados rapidamente, sem introduzir uma inicialização a frio em todas as solicitações.

A execução de isolados não apenas nos deu uma vantagem pronta para uso, mas à medida que o V8 fica melhor, nossa plataforma também melhora. Por exemplo, quando o V8 anunciou o Liftoff, um compilador para WASM, todos os WASM do Workers ficaram mais rápidos instantaneamente.

Da mesma forma, sempre que são feitas melhorias na rede da Cloudflare (por exemplo, quando adicionamos novos data centers) ou na pilha (por exemplo, compatibilidade com novos protocolos mais rápidos como HTTP/3), o Workers se beneficia instantaneamente.

Além disso, estamos sempre buscando melhorias no próprio Workers para tornar a plataforma ainda mais rápida. Por exemplo, no ano passado, lançamos uma melhoria que ajudou a eliminar partidas a frio para nossos clientes.

Uma grande vantagem que ajuda o Workers a identificar e abordar as lacunas de desempenho é a escala na qual ele opera. Hoje, o Workers atende centenas de milhares de desenvolvedores, de amadores a empresas em todo o mundo, atendendo a milhões de solicitações por segundo. Sempre que fazemos melhorias para um único cliente, toda a plataforma fica mais rápida.

O objetivo final do modelo sem servidor é permitir que os desenvolvedores se concentrem no que fazem de melhor: criar experiências para seus usuários. Escolher uma plataforma sem servidor que possa oferecer o melhor desempenho pronta para uso significa uma coisa a menos com que os desenvolvedores precisam se preocupar. Se você gasta seu tempo otimizando para inicializações a frio, não está gastando seu tempo criando o melhor recurso para seus clientes.

Assim como os desenvolvedores desejam criar a melhor experiência para seus usuários melhorando o desempenho de seus aplicativos, também estamos constantemente nos esforçando para melhorar a experiência dos desenvolvedores que criam no Workers .

Da mesma forma que os clientes não querem esperar por respostas lentas, os desenvolvedores não querem esperar por ciclos de implantação lentos.

É aqui que a plataforma Workers se destaca mais uma vez.

Qualquer implantação no Cloudflare Workers leva menos de um segundo para se propagar globalmente, então você não quer perder tempo esperando a implantação do seu código e os usuários podem ver as alterações o mais rápido possível.

Claro, não é apenas o tempo de implantação em si que é importante, mas a eficiência do ciclo completo de desenvolvimento, e é por isso que estamos sempre buscando aprimorá-lo em cada etapa: desde a inscrição até a depuração.

Nem é preciso dizer que, por mais que tentemos permanecer neutros, sempre seremos um pouco tendenciosos. Felizmente, você não precisa acreditar no que dizemos.

Convidamos você a se inscrever e implantar seu primeiro Worker hoje mesmo, só alguns minutos!