4 pontos por GN⁺ 2024-04-08 | 1 comentários | Compartilhar no WhatsApp

Demo do pgmock — Discord

  • pgmock é um servidor mock de PostgreSQL em memória para testes unitários e E2E.
  • Não possui dependências externas e roda inteiramente dentro de WebAssembly, tanto no Node.js quanto no navegador.

Instalação

  • Pode ser instalado com o comando npm install pgmock.
  • Se quiser executar o pgmock no navegador, consulte as instruções detalhadas na seção de suporte a navegadores.

Primeiros passos

  • É possível iniciar o servidor em memória da seguinte forma:
    import { PostgresMock } from "pgmock";
    const mock = await PostgresMock.create();
    const connectionString = await mock.listen(5432);
    
  • Se você usa node-postgres (pg no npm), ele fornece um objeto de configuração que funciona no navegador sem usar portas:
    import * as pg from "pg";
    const mock = await PostgresMock.create();
    const client = new pg.Client(mock.getNodePostgresConfig());
    await client.connect();
    console.log(await client.query('SELECT $1::text as message', ['Hello world!']));
    
  • Após o uso, é uma boa prática destruir o servidor mock para liberar recursos:
    mock.destroy();
    

Documentação

  • Para ver a lista de todos os métodos disponíveis e sua documentação, consulte o arquivo-fonte de PostgresMock.

Suporte a navegadores

  • pgmock oferece suporte completo a ambientes de navegador.
  • Embora apps web não possam escutar portas TCP, é possível usar PostgresMock.createSocket e a configuração do node-postgres.
  • Se o bundler analisar imports estaticamente, a configuração padrão pode exibir avisos por causa de módulos opcionais do Node.js ausentes.
  • Se você quer apenas rodar o banco de dados no navegador, pode considerar pglite, mas ele tem funcionalidades limitadas.
  • O pgmock foi projetado com o objetivo de ser funcionalmente equivalente ao ambiente de PostgreSQL de produção desejado em ambientes de teste.

Como funciona

  • Há duas abordagens para rodar o Postgres em WebAssembly: fazer um fork para oferecer suporte nativo a WASM ou emular o servidor Postgres em um emulador x86.
  • A primeira tem melhor desempenho e usa menos memória, mas não oferece suporte a modo de usuário único (sem conexões) nem a extensões.
  • Como o objetivo é evitar diferenças entre teste e produção, e desempenho não é a principal preocupação em testes, o pgmock atualmente usa a segunda abordagem.
  • No médio prazo, quando os forks nativos de Postgres para WASM amadurecerem, o plano é oferecer ambas as opções e, eventualmente, mudar por padrão para WASM nativo.
  • Exceto pela API dentro de PostgresMock.subtle, não se espera que haja muitas mudanças.
  • O pgmock simula uma pilha de rede em JavaScript que se comporta como uma rede real, permitindo simular conexões TCP mesmo em plataformas que não permitem acesso bruto a sockets, o que possibilita compatibilidade funcional completa inteiramente dentro do runtime JavaScript, sem depender de proxies de rede.

Quer contribuir?

  • Você pode conversar conosco no servidor do Discord.

Dá para rodar outras imagens Docker ou bancos de dados?

  • Em teoria, sim. Se tiver interesse, entre em contato pelo servidor do Discord.

Agradecimentos

  • Agradecimentos ao v86, o emulador x86 que torna isso possível.
  • Agradecimentos à Supabase e à Snaplet, que construíram sua própria abordagem para rodar Postgres dentro de WebAssembly.
  • Agradecimentos à Stackframe, que pagou salários durante o desenvolvimento do pgmock.

Opinião do GN⁺

  • O pgmock é uma ferramenta útil para desenvolvedores testarem interações com bancos de dados PostgreSQL. Ele permite validar a interação do código com o banco sem a complicação de configurar e manter um servidor de banco real.
  • Ferramentas assim são muito úteis em desenvolvimento orientado a testes (TDD) e em ambientes de integração contínua (CI). Os desenvolvedores podem executar testes rapidamente e verificar imediatamente o impacto de mudanças no código.
  • Como o pgmock usa WebAssembly e funciona tanto no navegador quanto no Node.js, ele oferece compatibilidade em diversos ambientes de desenvolvimento. Isso beneficia tanto desenvolvedores de frontend quanto de backend.
  • No entanto, ainda resta a dúvida se o pgmock consegue emular perfeitamente todos os recursos de um servidor PostgreSQL real, especialmente em termos de desempenho e extensões. Diferenças em relação ao ambiente real de banco podem afetar os resultados dos testes.
  • Outros projetos com funcionalidades parecidas incluem Testcontainers e H2 Database, que oferecem, respectivamente, testes de integração com contêineres Docker e banco de dados em memória para aplicações Java.

1 comentários

 
GN⁺ 2024-04-08
Comentários do Hacker News
  • Introdução ao pgmock

    • Um desenvolvedor criou, ao longo de alguns meses, uma versão em memória do Postgres.
    • Essa versão é funcionalmente equivalente ao banco de dados existente.
    • Não requer processo externo nem proxy e funciona em plataformas que conseguem executar WASM (Node.js, navegador etc.).
    • É possível criar um novo banco de dados e dados simulados de forma tão simples quanto criar um objeto JavaScript.
    • Diferentemente do pglite, o pgmock executa um emulador x86 com o Postgres original embutido. O pglite compila diretamente um fork do Postgres para WASM, sendo mais rápido e leve, mas suporta apenas o modo de usuário único e alguns recursos de extensão, então não é possível conectar-se a ele com um cliente Postgres comum.
    • Em teoria, qualquer imagem Docker poderia ser adaptada para rodar em plataformas WebAssembly.
  • Pergunta sobre executar o Postgres em um disco RAM

    • Pedido para explicar, em comparação com rodar o Postgres em um disco RAM, quais seriam as vantagens de poder executá-lo no navegador/Node e permitir que seja criado/atualizado/destruído pelos testes.
  • Relato de experiência com servidores em memória em vez de servidores reais

    • No passado, foram usados vários servidores falsos em memória (inclusive personalizados) em testes, mas hoje em dia usa-se Testcontainers para executar os serviços reais.
  • Pergunta sobre a propriedade intelectual do projeto

    • Levanta-se a dúvida se a expressão "eu fiz isso no trabalho" no título significa que a propriedade intelectual pertence ao empregador e se, caso recursos da empresa tenham sido usados, seria permitido abrir o código como open source.
  • Conselho sobre replicar o ambiente de desenvolvimento

    • Recomenda-se fazer um dump dos dados de produção, remover dados sensíveis e reduzir tabelas desnecessárias, como tabelas de log, para criar uma cópia de desenvolvimento. Ao replicá-la para desenvolvimento, QA, E2E etc., é possível garantir as extensões, triggers, funções, views, índices e dados necessários para os testes E2E.
  • Pergunta sobre o contexto de criação do pgmock e integração com CI

    • Pergunta sobre a motivação para desenvolver esse projeto e se executar o Postgres em um contêiner Docker era lento demais.
    • Pedido de explicação sobre a configuração de CI e o fluxo de testes E2E antes e depois da integração do pgmock.
    • Pergunta se a migração para essa solução foi difícil.
  • Pergunta de comparação com o banco de dados H2

    • Pergunta comparando o banco de dados H2 em modo de compatibilidade com Postgres e o pgmock.
  • Relato de experiência com pgmem

    • Compartilhamento de experiência de uso do pgmem, com finalidade parecida, ao longo dos últimos anos.
  • Pergunta sobre suporte a ORM

    • Pergunta se é possível usar ORMs como Sequelize, Prisma e Drizzle nos testes.
  • Pergunta sobre uso com o cliente Prisma

    • Pergunta sobre como isso poderia ser usado junto com o cliente Prisma.