Hacker News Reader

Comment by TameAntelope | Hacker News Reader

The dream for any kind of tool like this is to only have to define your data structures once, and use the tool to "generate" related code rather than try to keep two different artifacts in sync (e.g. a GraphQL schema and this DDL).

How far along that path has this project progressed? I can't really tell from the main page.

View on HN

Starting with an expressive declarative schema and building everything around it is exactly the approach we take in EdgeDB [1]. One of the key ideas is that you should be able to define almost anything not just statically, but as a result of some computation. Think views, functions, and computed columns, but without the traditional limitations and change-rigidity of their implementation in Postgres, because schema migrations are treated as a single logical change unit [2] rather than a bunch of independent DDL statements, so dependencies between schema objects and their changes are understood. The richness of the schema coupled with thorough introspection [3] then enables GraphQL schema derivation [4] and type-safe client generation without any loss in fidelity.

(disclaimer: I work on EdgeDB)

[1] https://www.edgedb.com/ [2] https://www.edgedb.com/docs/guides/migrations/index [3] https://www.edgedb.com/docs/guides/introspection/index [4] https://www.edgedb.com/docs/graphql/graphql

You might find something like Hasura interesting.

https://hasura.io/

It is a GraphQL server that sits on top of your Postgres DB and the schema reflects the table schema. It's quite powerful right out of the box.

If you combine that on the front-end with Apollo and a Typescript types code generator, you end up with strong typing all the way from your database to the front-end.

I went with Prisma + Nexus + Pal.js + Apollo, which was probably at least two layers too complex.

I'm looking, still, for an all-in-one solution to this, though I do need more control over my queries/mutations than what Hasura would give me.

When faced with this problem, I wound up using normal SQL migrations to set the DB state, sqlc to generate the SQL boilerplate (https://sqlc.dev/), and I wrote a little tool to generate the HTTP handler boilerplate for these tables.

Not all-in-one, but this approach has been really effective in a large codebase.

(Apologies for going off-topic)

I am working on a solution to simplify this piece of the puzzle and seeking feedback for an early version of the solution.

Please DM me (email in profile) and we can set something up.

there is an open source golang project that does the same thing called GraphJin.

has GUi tooling also.

https://github.com/dosco/graphjin

You give it the Postresql script and you will see the new GraphQL schema in he GUI, ready to test. This means that is only one change point ever - the sql.

It also supports subscriptions.

for CI you can just put the script into your git tree and it will pick them up at the start of a deploy update.

Reply on news.ycombinator.com