I want something that I can share with a development team that's just focused on features and doesn't want to think about the tools at hand very much (but can deeply fine-tune where needed).
Postgraphile seems like an amazing place to start for this.
Here's what I might want to build on top of it (though ideally it'd be baked-in):
Each "table" (think pg_class) should have a single file where ~all logic around that table is contained in as declarative a format as possible.
Smart tags should live in the same, easy-to-see and easy-to-edit place.
Wrapping resolvers and adding new ones should be easy and encouraged, as should other common table-centric operations.
I also think it'd be nice to expose sql
from the resolveInfo
param
since you have to pull off graphile
anyway.
Directly exposing a queryBuilder to allow run()
to do most of
the magic of selectGraphQLResultFromTable
(this would require some setup work in graphile.queryBuilder()
.
A sql declaration section should allow the framework to check at boot time
that the running database has a matching schema, and to suggest
migrations to run if not. CI should fail if running the migrations
does not result in the schema specified in the collective sqlDefinitions
.
A similar construct to this table-oriented approach would also be great for procedures, triggers, functions, etc – especially if it can encourage colocation of sql generated columns and gql extended resolvers (ideally one would be able to easily and transparently move between one and the other). I haven't thought this part through very much.