gradle-docker-compose-plugin VS pglite

Something that improved developer experience by far and also sped up our builds is starting the container dependencies via docker-compose and connect to it for integration testing. This allows reuse of containers, you can connect to it after/during an integration test to debug without having to keep searching for ports constantly.

With TestContainers - I've perceived that running integration tests / a single test repeatedly locally is extremely slow as the containers are shut down when the java process is killed. This approach allows for this while also allowing to keep it consistent - example, just mount the migrations folder in the start volume of your DB container and you have a like-for-like schema of your prod DB ready for integration tests.

I've found the https://github.com/avast/gradle-docker-compose-plugin/ very useful for this.

Hey HN! For a few months, I've been building pgmock at work for our E2E and unit test suite. It emulates Postgres in WebAssembly and has full feature parity with production databases.

The cool thing about it is that you don't need any external processes or proxies. If your platform can run WASM (Node.js, browser, etc.), it can probably run pgmock. Creating a new database with mock data is as simple as creating a JavaScript object.

It's a bit different from the amazing pglite [1] (which inspired me to open-source pgmock in the first place). While pgmock runs an x86 emulator, pglite compiles a Postgres fork to native WASM directly and is hence much faster and more lightweight. However, it only supports single-user mode and a select few extensions, so you can't connect to it with normal Postgres clients (which is quite crucial for E2E testing).

Theoretically, it could be modified to run any Docker image on WebAssembly platforms. Anything specific you'd like to see?

Happy hacking!

[1] https://github.com/electric-sql/pglite

I've found postgres via docker to be fine for dev and testing, but there are various epheremal postgres scripts, plus this could be promising for node stuff https://github.com/electric-sql/pglite if it works out. I'd imagine if this does work out we'll see the same kind of builds for other runtimes as well (like python)

> Use SQLite for everything, or Postgres if you outgrow it.

Or both! ElectricSQL syncs front end SQLlite back to server side postgres. And they just rebuilt postgres on pure WASM (https://github.com/electric-sql/pglite). All ties together with a CRDT.

I'm not affiliated, but just think it's just cool to imagine calls to front end sqllite as the be-all-end-all.