HN publicado: convierten en código abierto un PostgreSQL en memoria construido en el trabajo para pruebas E2E

Demo de pgmock — Discord

• pgmock es un servidor simulado de PostgreSQL en memoria para pruebas unitarias y E2E.
• No tiene dependencias externas y se ejecuta por completo dentro de WebAssembly tanto en Node.js como en el navegador.

Instalación

• Se puede instalar con el comando npm install pgmock.
• Si quieres ejecutar pgmock en el navegador, consulta las instrucciones detalladas en la sección de compatibilidad con navegadores.

Primeros pasos

• Puedes iniciar el servidor en memoria de la siguiente manera:

  import { PostgresMock } from "pgmock";
  const mock = await PostgresMock.create();
  const connectionString = await mock.listen(5432);
  

• Si usas node-postgres (pg en npm), proporciona un objeto de configuración que funciona también en el navegador sin usar puertos:

  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!']));
  

• Después de usarlo, es una buena práctica destruir el servidor simulado para liberar recursos:

  mock.destroy();
  

Documentación

• Para ver la lista de todos los métodos disponibles y su documentación, revisa el archivo fuente de PostgresMock.

Compatibilidad con navegadores

• pgmock ofrece compatibilidad completa con entornos de navegador.
• Aunque las web apps no pueden escuchar puertos TCP, se puede usar PostgresMock.createSocket junto con la configuración de node-postgres.
• Si tu bundler analiza importaciones estáticas, podrían aparecer advertencias en la configuración predeterminada debido a módulos opcionales de Node.js faltantes.
• Si solo quieres ejecutar una base de datos en el navegador, puedes considerar pglite, aunque tiene funciones limitadas.
• pgmock fue diseñado con el objetivo de ser funcionalmente equivalente al entorno de PostgreSQL de producción que quieres en pruebas.

Cómo funciona

• Hay dos enfoques para ejecutar Postgres en WebAssembly: hacer un fork para que soporte WASM de forma nativa o emular el servidor Postgres dentro de un emulador x86.
• El primero ofrece mejor rendimiento y menor uso de memoria, pero no soporta el modo de usuario único (sin conexiones) ni extensiones.
• Para evitar diferencias entre pruebas y producción, y dado que el rendimiento no es la principal preocupación en pruebas, pgmock usa actualmente el segundo enfoque.
• A mediano plazo, cuando madure un fork nativo de Postgres para WASM, planean ofrecer ambas opciones y eventualmente cambiar al WASM nativo por defecto.
• No se espera que haya muchos cambios, salvo en la API dentro de PostgresMock.subtle.
• pgmock simula un stack de red en JavaScript que se comporta como una red real, lo que permite simular conexiones TCP incluso en plataformas que no permiten acceso a sockets sin procesar, brindando compatibilidad funcional completa totalmente dentro del runtime de JavaScript sin depender de proxies de red.

¿Quieres contribuir?

• Puedes hablar con nosotros en el servidor de Discord.

¿Se pueden ejecutar otras imágenes de Docker o bases de datos?

• En teoría sí. Si te interesa, ponte en contacto en el servidor de Discord.

Agradecimientos

• Gracias a v86, el emulador x86 que hace esto posible.
• Gracias a Supabase y Snaplet por haber construido su propio enfoque para ejecutar Postgres dentro de WebAssembly.
• Gracias a Stackframe por pagar el salario durante la construcción de pgmock.

Opinión de GN⁺

• pgmock es una herramienta útil para desarrolladores que prueban interacciones con bases de datos PostgreSQL. Permite validar la interacción del código con la base de datos sin la molestia de configurar y administrar un servidor de base de datos real.
• Este tipo de herramienta es muy útil en entornos de desarrollo guiado por pruebas (TDD) o integración continua (CI). Los desarrolladores pueden ejecutar pruebas rápidamente y verificar de inmediato el impacto de los cambios en el código.
• Como pgmock funciona tanto en el navegador como en Node.js usando WebAssembly, ofrece compatibilidad en diversos entornos de desarrollo. Esto beneficia tanto a desarrolladores frontend como backend.
• Sin embargo, sigue quedando la duda de si pgmock puede emular perfectamente todas las funciones de un servidor PostgreSQL real, especialmente en aspectos como rendimiento y extensiones. Las diferencias con el entorno real de base de datos podrían afectar los resultados de las pruebas.
• Otros proyectos con funciones similares incluyen Testcontainers y H2 Database, que ofrecen respectivamente pruebas de integración usando contenedores Docker y una base de datos en memoria para aplicaciones Java.

[GN⁺]

Comentarios de Hacker News

• Introducción a pgmock

  • Un desarrollador creó durante varios meses una versión en memoria de Postgres.
  • Esta versión es funcionalmente equivalente a la base de datos existente.
  • No requiere procesos externos ni proxies, y funciona en plataformas que pueden ejecutar WASM (Node.js, navegadores, etc.).
  • Se pueden crear una base de datos nueva y datos simulados con la misma facilidad con la que se crea un objeto de JavaScript.
  • A diferencia de pglite, pgmock ejecuta un emulador x86 que incluye internamente el Postgres original. pglite compila directamente a WASM un fork de Postgres, por lo que es más rápido y ligero, pero solo soporta modo de usuario único y algunas extensiones, así que no es posible conectarse con un cliente Postgres común.
  • En teoría, cualquier imagen de Docker podría modificarse para ejecutarse en una plataforma WebAssembly.

• Pregunta sobre ejecutar Postgres en un disco RAM

  • Solicitan que explique, en comparación con ejecutar Postgres en un disco RAM, la ventaja de que pueda correr en entornos de navegador/Node y de que pueda ser creado, actualizado y destruido por las pruebas.

• Experiencia usando servidores en memoria en lugar de servidores reales

  • En el pasado usó varios servidores falsos en memoria (algunos personalizados) para pruebas, pero ahora utiliza Testcontainers para ejecutar servicios reales.

• Pregunta sobre la propiedad intelectual del proyecto

  • Se plantea la duda de si la expresión "lo hice en el trabajo" en el título implica que la propiedad intelectual pertenece al empleador, y si estaría permitido publicarlo como código abierto si se usaron recursos del trabajo.

• Consejo sobre replicar el entorno de desarrollo

  • Recomiendan volcar los datos de producción, eliminar la información sensible y reducir tablas innecesarias como las de logs para crear una copia de desarrollo. Al replicarla en desarrollo, QA, E2E, etc., se pueden asegurar las extensiones, triggers, funciones, vistas, índices y datos necesarios para las pruebas E2E.

• Pregunta sobre el origen de pgmock y su integración con CI

  • Preguntan qué motivó el desarrollo de este proyecto y si ejecutar Postgres en un contenedor Docker era demasiado lento.
  • También piden una explicación de la configuración de CI y del flujo de pruebas E2E antes y después de integrar pgmock.
  • Preguntan si fue difícil migrar a esta solución.

• Pregunta de comparación con la base de datos H2

  • Preguntan cómo se compara pgmock con la base de datos H2 en modo de compatibilidad con Postgres.

• Experiencia usando pgmem

  • Comparten que han trabajado durante los últimos años con pgmem para un propósito similar.

• Pregunta sobre soporte para ORM

  • Preguntan si se puede usar en pruebas con ORM como Sequelize, Prisma y Drizzle.

• Pregunta sobre uso con Prisma Client

  • Preguntan si existe alguna forma de usarlo junto con Prisma Client.