Deno Queues

 (deno.com)
1 pontos por GN⁺ 2023-09-29 | 1 comentários | Compartilhar no WhatsApp
  • Deno Queues é uma fila distribuída serverless construída sobre o Deno KV, permitindo delegar tarefas demoradas para execução assíncrona ou agendar sua execução para um momento futuro
  • Desenvolvedores só precisam inserir mensagens com .enqueue() e processá-las com .listenQueue(), sem configurar nem manter uma infraestrutura de filas separada
  • Localmente, usa SQLite; no Deno Deploy, usa FoundationDB, e o Deploy inicia um V8 isolate sob demanda no momento de processar a mensagem
  • O modelo de entrega é at-least-once delivery, portanto, em situações de falha ou nova tentativa, a mesma mensagem pode ser processada várias vezes
  • Não há cobrança separada pela fila, mas enqueue conta como escrita no KV, e o recebimento de mensagens é contabilizado como escrita no KV e requisição do Deno Deploy; por isso, é preciso considerar tanto o processamento duplicado quanto a estrutura de custos

O que o Deno Queues faz

  • Deno Queues é um recurso de filas baseado no Deno KV, que permite delegar parte do processamento de uma aplicação para tarefas assíncronas ou agendar tarefas para execução posterior
  • O objetivo do Deno é reduzir configurações repetitivas e composição de infraestrutura no desenvolvimento de software em nuvem, oferecendo elementos básicos que permitam aos desenvolvedores projetar, melhorar e lançar mais rapidamente
  • Deno KV é uma opção de persistência baseada em FoundationDB e atualmente está em beta aberto
  • Queues oferece, sobre o Deno KV, mensageria escalável e gerenciamento de processamento em segundo plano

API básica e modelo de execução

  • A API central do Deno Queues tem duas partes
    • .enqueue(): coloca uma nova mensagem na fila para ser entregue imediatamente ou em um momento futuro
    • .listenQueue(): usado como handler que recebe e processa novas mensagens da fila
  • O fluxo básico consiste em abrir o KV com Deno.openKv(), enviar mensagens ao Slack em listenQueue e definir { delay: 60000 } em enqueue para que o processamento aconteça 60 segundos depois
  • O armazenamento varia conforme o ambiente de execução
    • Usa SQLite em execução local
    • Usa FoundationDB ao executar no Deno Deploy
  • No Deno Deploy, quando chega o momento em que uma mensagem pode ser processada, um V8 isolate é executado sob demanda e a mensagem é despachada
  • O código da aplicação só precisa receber novas mensagens por meio do handler listenQueue; o restante do gerenciamento de execução fica a cargo do Deno Deploy

Garantias de entrega e novas tentativas

  • Deno Queues garante at-least-once delivery
  • A maioria das mensagens enfileiradas chama o handler listenQueue apenas uma vez, mas, em algumas situações de falha, o mesmo handler pode ser chamado várias vezes para garantir a entrega
  • Portanto, a aplicação deve lidar com processamento duplicado de mensagens de forma segura
  • Se o handler listenQueue lançar uma exceção, o runtime tentará automaticamente chamar novamente
  • As novas tentativas continuam até o sucesso ou até atingir o número máximo de tentativas; o valor máximo padrão atual é 5 vezes
  • Mensagens que atingem o número máximo de tentativas são excluídas

Uso com KV atomic transactions

  • Deno Queues pode ser combinado com KV atomic transactions
  • Ao enfileirar uma mensagem como parte de uma transação KV, a mensagem só entra na fila se a transação inteira for bem-sucedida
  • Um fluxo de exemplo verifica e atualiza os saldos de Bob e Liz e, em seguida, enfileira mensagens de notificação para ambos
    • Verifica o estado com check(bob, liz)
    • Reduz o saldo de Bob e aumenta o saldo de Liz
    • Adiciona mensagens de notificação para Liz e Bob, respectivamente, com enqueue
    • commit() precisa ser bem-sucedido para que todas as alterações e o enqueue sejam refletidos
  • Dentro do handler listenQueue, também é possível atualizar o estado do Deno KV
  • Para executar atualizações por mensagem apenas uma vez, é possível configurar um fluxo de prevenção de processamento duplicado armazenando e removendo um nonce
    • Armazena o nonce junto no momento do enqueue
    • Durante o processamento, se o nonce não existir, retorna imediatamente
    • Em caso de processamento bem-sucedido, exclui o nonce e atualiza conjuntamente o contador e o estado dos saldos

Casos de uso adequados para filas

  • Filas são úteis para escalar aplicações, pois permitem que o servidor delegue processamento assíncrono e agende tarefas futuras

  • Notificações de e-mail agendadas

    • Quando uma tarefa iniciada pelo usuário demora muito ou não exige aguardar uma resposta de conclusão, é possível delegá-la para a fila e manter a responsividade do servidor ou app
    • No exemplo, a mensagem welcome_email é enfileirada imediatamente, e a mensagem survey_email é executada com atraso usando { delay: 259200000 }

  • Processamento confiável de webhooks

    • Ao colocar uma requisição de webhook na fila em vez de processá-la imediatamente, é possível separar a resposta do processamento real
    • Usando Oak junto com Queues, ao receber uma requisição POST em /webhook, o corpo da requisição é colocado na fila e um HTTP 200 é retornado
    • O processamento real do webhook é feito de forma assíncrona em listenQueue com processWebHook

  • Bots para Slack e Discord

Modelo de cobrança

  • Deno Queues não tem um item de cobrança dedicado separado
  • O custo é calculado com base nas operações do Deno KV e nas requisições do Deno Deploy
    • Enqueue de mensagem: cada operação de enqueue corresponde a 1 operação de escrita no KV
    • Recebimento de mensagem: para cada mensagem recebida, são cobradas 1 escrita no KV e 1 tarifa de requisição
  • A estrutura cobra apenas pelas operações utilizadas

Documentação e roadmap

Leituras relacionadas

1 comentários

 
GN⁺ 2023-09-29
Opiniões do Hacker News

  • Acabei de vasculhar por dentro a versão local em SQLite e organizei algumas anotações: https://til.simonwillison.net/deno/deno-kv#user-content-deno...
    A parte mais interessante talvez seja o esquema usado para esse recurso:
    CREATE TABLE queue ( ts integer not null, id text not null, data blob not null, backoff_schedule text not null, keys_if_undelivered blob not null, primary key (ts, id) );
    CREATE TABLE queue_running( deadline integer not null, id text not null, data blob not null, backoff_schedule text not null, keys_if_undelivered blob not null, primary key (deadline, id) );
    CREATE INDEX kv_expiration_ms_idx on kv (expiration_ms);

    • Acho que criar duas tabelas com campos quase iguais e mover linhas entre elas normalmente não é uma má prática?
      Índices não foram projetados justamente para esse tipo de uso?
    • O que é especialmente interessante do ponto de vista de “modelo de negócios open source” é que a Deno está colocando em recursos centrais do framework funcionalidades que só a sua própria plataforma SaaS consegue oferecer bem como um upgrade em escala global
      É algo bem novo, mas também um pouco inquietante. É claro que eles precisam comercializar, mas não precisava ser de uma forma totalmente fechada; talvez pudessem usar outra licença, como BSL ou PolyForm, na camada de expansão

  • Acho que a direção que o Deno está mirando aqui é bem voltada para o futuro
    Comecei a usar Go este ano, e parte da linguagem é muito parecida com C. Além das diferenças em relação a C — por exemplo, graças ao garbage collection, ser possível retornar de uma função valores que parecem ponteiros alocados na stack —, recursos embutidos como map[string]string entram de forma natural. Se alguém criasse uma nova linguagem depois de 2023, eu sentiria que quase não faz sentido ela não ter uma sintaxe embutida para lidar com tipos de mapa
    Então me parece lógico que um ecossistema centrado em servidores web tenha bibliotecas — e talvez algum dia até sintaxe da linguagem — para as funcionalidades primitivas que usamos com frequência. Não lembro do último projeto em que um servidor web distribuído não tivesse nem um armazenamento chave-valor para cache, nem um mecanismo de lock, nem mesmo uma fila temporária. Um sistema distribuído sem armazenamento chave-valor lembra vagamente uma linguagem de programação sem tipo de mapa, e é realmente uma tecnologia tipo canivete suíço
    O problema potencial é que o Deno está seguindo esse caminho sozinho. É difícil ter certeza se os novos recursos que o Deno está adicionando também serão oferecidos por plataformas concorrentes e, mesmo que a API seja aberta como open source, ela fica no namespace Deno, então não sei se simplesmente funcionaria quando eu quisesse trocar FoundationDB por Redis na AWS
    Por isso fico com a sensação de querer evitar o Deno. A sintaxe e as funcionalidades expostas são realmente atraentes, mas me preocupa ter de fazer uma grande cirurgia no código depois de ficar dependente, para torná-lo implantável em várias infraestruturas de nuvem. Muitos clientes exigem isso. Por exemplo, se um dia eu quiser vender para a Oracle ou a Salesforce e eles exigirem execução on-premises, vai sobrar para mim descobrir como adaptar o armazenamento chave-valor disponível do lado deles aos recursos do pacote Deno
    É uma faca de dois gumes. O Deno pode conseguir empurrar essa visão para um público mais amplo, mas por enquanto acho que vou olhar com cautela

    • Neste caso, o KV Connect, que é o protocolo de conexão remota, também está documentado: https://github.com/denoland/deno/tree/main/ext/kv#kv-connect
      Dei uma testada rápida no kv-connect-kit, uma implementação desse protocolo em TypeScript puro, e ele oferece uma API de cliente KV em qualquer runtime JavaScript. Isso inclui Cloudflare Workers, que não têm nenhum namespace Deno
      GitHub: https://github.com/skymethod/kv-connect-kit / npm: https://www.npmjs.com/package/kv-connect-kit / deno/x: https://deno.land/x/kv_connect_kit / demo: https://keyspace.deno.dev/
      O protocolo parece funcionar como descrito, e escrever outros backends também parece bem simples
    • Não concordo. Acoplar o runtime da linguagem a uma interface KV específica vinculada a um serviço de hospedagem específico é o oposto de ser voltado para o futuro
      A indústria de tecnologia avançou bastante para sair de stacks com dependência de fornecedor, e isso, pelo contrário, lembra aqueles tempos
      Não vejo qual é a diferença prática entre Deno.KV fazer parte do runtime e adicionar import KV no topo do arquivo. Com a segunda opção, você pode importar de onde quiser, seja no Deno ou em outro lugar
      E qual é a chance de a equipe do Deno oferecer bindings para outras linguagens além da própria? Se o Google começasse a colocar recursos primitivos nativos exclusivos do Google Cloud em Go, você chamaria isso de voltado para o futuro?
    • Gosto do Deno, mas pelo mesmo motivo acabo sendo cauteloso para adotá-lo. Para o Deno vencer, acho que os concorrentes de hospedagem também precisariam ter suporte completo
      Ao mesmo tempo, a hospedagem própria deles também precisaria ser igual ou melhor que a dos líderes do setor. Outro caminho seria abandonar a hospedagem própria e oferecer uma solução multicloud com uma margem pequena em cima de adaptadores para parceiros de hospedagem. Assim o Deno não precisaria competir diretamente como provedor de hospedagem
    • O Deno só está tentando competir com outros SaaS de JS/TS com isso. Vercel/NextJS também tem serviço KV, a Cloudflare também tem, e em outros casos há o Firebase
      Vejo isso menos como algo voltado para o futuro e mais como uma forma de monetizar o Deno como SaaS. É o que todo mundo no mundo JavaScript faz hoje com produtos de “cloud”: empacota um framework e revende AWS. Por isso existe uma tabela de preços
      Se o KV do Deno depende do FoundationDB, também parece pouco provável que eles criem ativamente adaptadores para outros bancos de dados. Trocar a tecnologia de banco de dados é sempre algo grande, porque cada uma tem usos e características de desempenho diferentes
    • GC allowing one to return what look like stack allocated pointers from functions não me parece ser por causa do garbage collection, mas sim graças à análise de escape e ao SSA

  • Não acho muito convincente o argumento de que “para aproveitar a infraestrutura de nuvem pública, é preciso vasculhar código boilerplate e configurações complexas, o que consome muito tempo e energia dos desenvolvedores”
    No fim das contas, estamos criando infraestrutura que precisa ser confiável. Gastar 30 minutos configurando uma tecnologia comprovada como filas SQS não parece pior do que confiar totalmente numa fila de brinquedo que o Deno criou “em cima de SQLite / FoundationDB”. O custo de 30 minutos de configuração e a “experiência do desenvolvedor” melhorada valem mesmo assumir esse risco? Para começo de conversa, com que frequência se configura uma fila?

    • Acho que isso depende do tipo de pessoa que eu sou
      Como programador por hobby, não uso muito grandes provedores como AWS ou Google, porque parecem bastante complexos. Talvez, quando se está acostumado, não seja tão ruim
      Também quero manter cada projeto como um repositório independente no GitHub. Idealmente, qualquer outra pessoa deveria conseguir colocar uma aplicação web no ar com facilidade em um domínio separado, como se fosse sua própria aplicação web independente. É porque não quero ficar responsável pelos dados dos outros
      Isso se parece, em certa medida, com o caso de uso do Sandstorm. Uma instrução de instalação do tipo “teste localmente e, se for usar de verdade, crie uma conta no Deno Deploy” soa bem razoável
    • Muita gente não tem experiência com AWS ou SQS, e mesmo quem tem ainda precisa se preocupar com isso. O Deno adotou uma abordagem batteries included, para que o desenvolvedor possa pegar algo e usar imediatamente
      Se alguém oferecer uma biblioteca equivalente para a nuvem, certamente haverá pessoas que a adotarão. No caso do Deno, parece que eles estão tentando identificar problemas comuns enfrentados pelos desenvolvedores do próprio ecossistema e resolvê-los empacotando uma solução razoável
    • Dizendo de forma radical, acho que hoje é melhor não usar filas diretamente. É parecido com usar HTTP/2 puro ou gerenciar threads manualmente
      Se você usa um motor de workflow que abstrai a fila, dá para “simplesmente escrever código” sem gerenciar tarefas, agendamentos, estado e tentativas
      https://www.inngest.com/blog/how-durable-workflow-engines-wo...
      Dito isso, sou autor de um motor de workflow, então tenho viés
    • Por essa lógica, tudo que é novo é basicamente um “projeto de brinquedo”, e só a AWS é comprovada, então ninguém deveria lançar produtos novos
    • Como você sabe que é uma fila de brinquedo?

  • Pela minha experiência anterior lidando com “semântica de entrega pelo menos uma vez” e “código de usuário”, usuários não entendem corretamente entrega pelo menos uma vez
    No momento em que uma mensagem é reenviada, começam a chover reclamações de usuários e incidentes
    Acho que ou se faz o quase impossível e se inventa semântica de entrega exatamente uma vez, ou então 0,1% de todas as mensagens deveriam ser sempre reenviadas, para impedir que os usuários passem a depender de que elas serão entregues apenas uma vez

    • O SQS inicial era praticamente assim. Não sei se era intencional, mas isso fez a gente aprender rapidamente que precisava respeitar reentregas
    • Se as mensagens precisam ser idempotentes, recomendo muito criar testes de integração no lado de quem envia para garantir isso

  • Atualmente estou usando Deno Deploy e, para um projeto feito por uma pessoa só, o desempenho é excelente e é realmente simples
    Tendo trabalhado com desenvolvimento em AWS em uma equipe grande, fico feliz com esse movimento de escapar da complexidade e conseguir colocar algo no ar facilmente sem pensar em configuração. O DNS também foi muito simples, e os certificados SSL automáticos foram ótimos. Não tenho nenhuma reclamação sobre o rumo que este produto está buscando, e estou ansioso pelo roadmap

  • A menos que eu tenha deixado passar algo, parece haver apenas uma fila por instância de Deno.openKv()
    Na versão local, talvez dê para criar várias filas chamando Deno.openKv("db-2.db") com um caminho de arquivo SQLite diferente a cada vez, mas isso parece ter um overhead grande para uma necessidade bastante comum
    Talvez esse seja o estilo de arquitetura do Deno. Ao criar uma aplicação complexa em Deno, será que a expectativa é uma estrutura no estilo microsserviços, com vários scripts funcionando juntos, cada um com seu próprio armazenamento KV e sua própria fila?

    • Correto. Atualmente há apenas uma única fila
      Um dos desenvolvedores principais confirmou isso no Discord: https://discord.com/channels/684898665143206084/115671428253...
      Citando: “Correto. Atualmente só há suporte a uma única fila. No entanto, é possível multiplexar vários tipos de mensagens em uma única fila.”

  • Como fica o preço?
    Eu pensava no Deno como uma espécie de substituto do Node.js; estou deixando passar alguma coisa? Dá para usar isso localmente ou em self-hosting sem custo?

    • Isso funciona da mesma forma que o restante do Deno KV. A versão open source usa SQLite, mas, quando você faz deploy no produto de nuvem do Deno, passa a usar a FoundationDB proprietária no lugar
      Como “Queues are built on Deno KV”, a explicação é que localmente ele usa SQLite e, no Deno Deploy, usa FoundationDB para obter máxima disponibilidade e throughput
      Escrevi um pouco mais sobre esse padrão aqui: https://til.simonwillison.net/deno/deno-kv
    • Segundo o texto, durante o desenvolvimento local ele usa SQLite e, ao fazer deploy no Deno, passa a fazer parte da funcionalidade oferecida pela nuvem

  • Se por acaso os desenvolvedores estiverem vendo isto, acho que a controle de acesso na excelente usabilidade atual do KV pode acabar causando dor mais adiante
    Fico curioso se a solução é simplesmente “implemente você mesmo no espaço do usuário e não crie bugs”, ou se há algo planejado

    • Você se refere a controle de acesso em nível de usuário, por exemplo ACLs para usuários autenticados, ou é outra coisa? Se você compartilhar uma reflexão mais longa, vou continuar mantendo essa preocupação em mente

  • O suporte recente a Jupyter e agora esse recurso de filas me deixam animado. São coisas realmente muito legais
    Mas acho que não escreveria um servidor em Deno para colocá-lo em produção no meu próprio servidor. Não gosto de serverless
    O modelo de negócios do Deno e do Bun é construído em torno de serverless, ou seja, Deno Deploy. E o Deno Deploy é mais um runtime
    Isso fica claro no KV e nas filas. Localmente ou em self-hosting, você acaba com uma versão que mal funciona, montada sobre outras tecnologias
    Ou seja, você estaria fazendo self-hosting de uma versão do Deno diferente daquela usada pela maioria dos clientes do Deno
    Quantas pessoas usam Deno para rodar servidores em seu próprio hardware? Se esse número for pequeno, eu preferiria usar Node

  • O Deno é realmente interessante. É ótimo por ter um modelo de negócios viável, boa usabilidade e não exigir tarefas inúteis de configuração

    • Tentei criar expectativas em relação ao Deno, mas não sei. Não vejo o que ele tem de diferente do que já foi feito inúmeras vezes no passado
      O Deno em si é, essencialmente, Node.js com compilação automática de TypeScript. Originalmente, isso só exigiria um arquivo de configuração a mais. Quando o projeto foi lançado, ele destacava bastante a ideia de escapar do ecossistema bagunçado do NPM, mas no fim teve que voltar atrás e adicionar suporte ao NPM, e esse diferencial também desapareceu
      O Deno Deploy é igual às dezenas de serviços do tipo Lambda que já existem. O armazenamento KV e, agora, as filas equivalem a Redis, LevelDB, RocksDB, Dynamo, SQS ou inúmeras opções semelhantes. Ainda não vi nenhum recurso que realmente diferencie o Deno dos demais
      Se você prefere que uma única empresa cuide do runtime da linguagem, da hospedagem de computação e do armazenamento de dados, isso pode ser atraente. Mas, pessoalmente, eu preferiria evitar, especialmente se essa empresa não tiver histórico nessa área
    • Por que você acredita que o Deno tem um modelo de negócios viável?