4 Punkte von GN⁺ 2024-04-08 | 1 Kommentare | Auf WhatsApp teilen

pgmock-Demo — Discord

  • pgmock ist ein In-Memory-Mock-Server für PostgreSQL für Unit- und E2E-Tests.
  • Es hat keine externen Abhängigkeiten und läuft vollständig innerhalb von WebAssembly sowohl in Node.js als auch im Browser.

Installation

  • Die Installation ist mit dem Befehl npm install pgmock möglich.
  • Wenn du pgmock im Browser ausführen möchtest, siehe die detaillierten Anweisungen im Abschnitt zur Browser-Unterstützung.

Erste Schritte

  • Der In-Memory-Server kann wie folgt gestartet werden:
    import { PostgresMock } from "pgmock";
    const mock = await PostgresMock.create();
    const connectionString = await mock.listen(5432);
    
  • Wenn du node-postgres (pg auf npm) verwendest, wird ein Konfigurationsobjekt bereitgestellt, das ohne Port funktioniert und auch im Browser läuft:
    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!']));
    
  • Nach der Nutzung ist es eine gute Praxis, den Mock-Server zu zerstören, um Ressourcen freizugeben:
    mock.destroy();
    

Dokumentation

  • Eine Liste aller verfügbaren Methoden und ihrer Dokumentation findest du in der PostgresMock-Quelldatei.

Browser-Unterstützung

  • pgmock unterstützt Browser-Umgebungen vollständig.
  • Web-Apps können keine TCP-Ports abhören, aber PostgresMock.createSocket und die node-postgres-Konfiguration können verwendet werden.
  • Wenn der Bundler statische Importe analysiert, können in der Standardkonfiguration Warnungen wegen fehlender (optionaler) Node.js-Module erscheinen.
  • Wenn du im Browser nur eine Datenbank ausführen möchtest, kannst du pglite in Betracht ziehen, allerdings mit eingeschränktem Funktionsumfang.
  • pgmock wurde mit dem Ziel entwickelt, in Testumgebungen funktional gleichwertig zur gewünschten produktiven PostgreSQL-Umgebung zu sein.

Funktionsweise

  • Es gibt zwei Ansätze, um Postgres in WebAssembly auszuführen: entweder einen Fork, der nativ WASM unterstützt, oder die Emulation eines Postgres-Servers in einem x86-Emulator.
  • Ersteres ist schneller und benötigt weniger Speicher, unterstützt aber keinen Single-User-Modus (keine Verbindungen) und keine Erweiterungen.
  • Um Unterschiede zwischen Test und Produktion zu vermeiden und da Performance in Tests nicht das Hauptanliegen ist, verwendet pgmock derzeit den zweiten Ansatz.
  • Mittelfristig ist geplant, beide Optionen anzubieten, sobald ein nativer Postgres-WASM-Fork ausgereift ist, und schließlich standardmäßig auf natives WASM umzuschalten.
  • Mit Ausnahme der API innerhalb von PostgresMock.subtle werden nicht viele Änderungen erwartet.
  • pgmock simuliert einen Netzwerk-Stack in JavaScript, der sich wie ein echtes Netzwerk verhält, sodass TCP-Verbindungen auch auf Plattformen simuliert werden können, die keinen Zugriff auf rohe Sockets erlauben. Dadurch wird vollständige funktionale Kompatibilität komplett innerhalb der JavaScript-Runtime ermöglicht, ohne auf Netzwerk-Proxys angewiesen zu sein.

Möchtest du beitragen?

  • Du kannst auf dem Discord-Server mit uns sprechen.

Kann man andere Docker-Images oder Datenbanken ausführen?

  • Theoretisch ja. Wenn du Interesse hast, melde dich auf dem Discord-Server.

Danksagung

  • Dank an v86, den x86-Emulator, der dies ermöglicht.
  • Dank an Supabase & Snaplet, die ihren eigenen Ansatz entwickelt haben, um Postgres innerhalb von WebAssembly auszuführen.
  • Dank an Stackframe, das während der Entwicklung von pgmock Gehälter gezahlt hat.

GN⁺-Meinung

  • pgmock ist ein nützliches Werkzeug für Entwickler, die Interaktionen mit PostgreSQL-Datenbanken testen möchten. Ohne den Aufwand, einen echten Datenbankserver einzurichten und zu verwalten, lässt sich die Datenbank-Interaktion des Codes prüfen.
  • Solche Werkzeuge sind besonders nützlich in Umgebungen mit testgetriebener Entwicklung (TDD) oder kontinuierlicher Integration (CI). Entwickler können Tests schnell ausführen und die Auswirkungen von Codeänderungen sofort überprüfen.
  • Da pgmock WebAssembly verwendet und sowohl im Browser als auch in Node.js funktioniert, bietet es Kompatibilität über verschiedene Entwicklungsumgebungen hinweg. Das ist sowohl für Frontend- als auch Backend-Entwickler vorteilhaft.
  • Es bleibt jedoch die Frage, ob pgmock wirklich alle Funktionen eines echten PostgreSQL-Servers perfekt emulieren kann, insbesondere in Bezug auf Performance und Erweiterungen. Unterschiede zur realen Datenbankumgebung könnten die Testergebnisse beeinflussen.
  • Andere Projekte mit ähnlicher Funktionalität sind unter anderem Testcontainers und H2 Database; sie bieten jeweils Integrationstests mit Docker-Containern und In-Memory-Datenbanken für Java-Anwendungen.

1 Kommentare

 
GN⁺ 2024-04-08
Hacker-News-Kommentare
  • Vorstellung von pgmock

    • Ein Entwickler hat über mehrere Monate eine In-Memory-Version von Postgres entwickelt.
    • Diese Version ist funktional äquivalent zur bestehenden Datenbank.
    • Es sind weder externe Prozesse noch Proxys erforderlich, und sie läuft auf Plattformen, die WASM ausführen können (Node.js, Browser usw.).
    • Neue Datenbanken und Mock-Daten lassen sich so einfach erzeugen wie das Erstellen eines JavaScript-Objekts.
    • Anders als pglite führt pgmock einen x86-Emulator aus, der das originale Postgres intern enthält. pglite kompiliert dagegen einen Postgres-Fork direkt nach WASM und ist dadurch schneller und schlanker, unterstützt aber nur den Single-User-Modus und einige Erweiterungen, sodass keine Verbindung mit normalen Postgres-Clients möglich ist.
    • Theoretisch könnte jedes Docker-Image so angepasst werden, dass es auf WebAssembly-Plattformen lauffähig ist.
  • Frage zum Ausführen von Postgres auf einer RAM-Disk

    • Es wird um eine Erklärung gebeten, welche Vorteile es im Vergleich dazu hat, Postgres auf einer RAM-Disk zu betreiben, insbesondere dass es in Browser-/Node-Umgebungen läuft und von Tests erzeugt, aktualisiert und zerstört werden kann.
  • Erfahrungsbericht zur Nutzung von In-Memory-Servern statt echter Server

    • Früher wurden in Tests verschiedene (maßgeschneiderte) Fake-In-Memory-Server verwendet, inzwischen werden mit Testcontainers die echten Services ausgeführt.
  • Frage zum geistigen Eigentum des Projekts

    • Es wird gefragt, ob die Formulierung „ich habe das bei der Arbeit gebaut“ im Titel bedeutet, dass die Rechte am geistigen Eigentum beim Arbeitgeber liegen, und ob eine Open-Source-Veröffentlichung erlaubt ist, wenn dabei Ressourcen des Arbeitgebers genutzt wurden.
  • Ratschlag zum Klonen der Entwicklungsumgebung

    • Empfohlen wird, Produktionsdaten zu dumpen, sensible Daten zu entfernen und unnötige Tabellen wie Log-Tabellen zu reduzieren, um eine Entwicklungskopie zu erstellen. Durch das Klonen für Entwicklung, QA, E2E usw. stehen dann die für E2E-Tests nötigen Erweiterungen, Trigger, Funktionen, Views, Indizes und Daten zur Verfügung.
  • Fragen zum Hintergrund der Entwicklung von pgmock und zur CI-Integration

    • Es wird gefragt, was die Motivation für dieses Projekt war und ob das Ausführen von Postgres in Docker-Containern zu langsam war.
    • Außerdem wird um eine Beschreibung der CI-Konfiguration und des E2E-Testablaufs vor und nach der Integration von pgmock gebeten.
    • Auch wird gefragt, ob die Umstellung auf diese Lösung schwierig war.
  • Frage zum Vergleich mit der H2-Datenbank

    • Es wird nach einem Vergleich zwischen der H2-Datenbank im Postgres-Kompatibilitätsmodus und pgmock gefragt.
  • Erfahrungsbericht zur Nutzung von pgmem

    • Jemand berichtet, in den vergangenen Jahren für einen ähnlichen Zweck mit pgmem gearbeitet zu haben.
  • Frage zur ORM-Unterstützung

    • Es wird gefragt, ob ORMs wie Sequelize, Prisma und Drizzle in Tests verwendet werden können.
  • Frage zur Nutzbarkeit mit dem Prisma-Client

    • Es wird gefragt, wie sich das zusammen mit dem Prisma-Client verwenden lässt.