Does it make sense to slap prisma on top of an existing g production database?
It was a definitely a design goal for us to make the existing production database use-cases as seamless as possible.
Instead of adding a new DSL on top of the database, Hasura maps much of the DML subset of SQL over to GraphQL (tables, views, functions) so that we're not re-inventing that bit and the translation is restricted to the "relation set" to "tree" transformation. json aggregation and json operations in Postgres are phenomenal! Hasura's authz RLS-like layer injects authorization in as well to make that GraphQL API actually useful.
JOOQ has probably done the most phenomenal job in mapping almost all database constructs to a native language library, but there's a solid amount of type magic there which I'm not sure is portable to every language.
It is, but I've just been too lazy so far to actually do it.
If you give it a try and have a database handy, I bet you can have it up and running in less than 10 minutes.
Regarding prisma, I see my impression was off a bit from talking with our team that used prisma in a green field project with migrations quite happily. And I somehow forgot that migrations are still marked experimental and are kind of new.
https://www.prisma.io/docs/reference/tools-and-interfaces/pr...