HN user

thenonameguy

45 karma

Founder/CEO of Schemamap.io (https://schemamap.io), ex-Ekata

Sync data from any Postgres DB to another.

krisz [at] schemamap.io

Posts1
Comments18
View on HN

One of the things that puts metaprogramming on wheels is being able to pull in grammars, schemas and such for external systems.

That's what I've been trying to do with: https://github.com/schemamap/schemamap

For a well-constrained Postgres schema, a deterministic SQL compiler can be built (with plenty of logic programming/constraint-solving/hypergraph-analysis) that can integrate arbitrary external systems data.

While this is NP-hard, with some clever use of embeddings and ontologies, and use of every single constraint AST within the DB to reduce the search space, this becomes a feasible problem.

For any Clojurists interested, I've packaged `pg_query`, so you can use it in your applications: https://github.com/schemamap/pg-query-clj

At the moment I'm saving up for the next development cycle, so not only PG->PG schema mappings can be solved for (JSON schema is next!). Hope this sounds interesting :)

Yup, it's still the best tool for me. Especially for complex domains, as it does not allow you to over-abstract data structures.

Schemamap.io has a declarative SQL compiler and backend implemented in it, solving Postgres database syncing.

I've been using https://github.com/F1bonacc1/process-compose with great success.

It's a userspace process orchestrator/scheduler that works across all relevant platforms, supporting daemon processes and k8s style readiness/health checks.

In combination with nix flakes, it quickly reduced my projects docker-compose usage for easy-to-configure services.

This gave huge performance benefits for the M1 Mac folks on my team especially for CPU intensive processes thanks to native binaries.

For maximal ease of use, the remaining docker-compose containers are started/stopped as a process-compose task. Quite meta :)

Thankfully we have solved this issue by adopting nix for setting up developer machines/project setup on top of your OS's package manager of choice (OSX/Linux).

Additionally, you automatically get shell completion too! https://github.com/NixOS/nixpkgs/blob/3bb54189b0c8132752fff3...

As described in the README, avoiding the 'build' part from Makefiles cut unnecessary complexity like .PHONY targets, which improves clarity. In smaller teams/companies it makes sense IMO.