Database handling in graphback

Background

Currently graphback-cli is pretty much strict about postgres as the only database. Database creation in graphback is done using knex which supports a bunch of relational databases.

graphback-cli has currently 3 main commands in it’s workflow with other proposed commands yet to be finalized.

• Init creates the project with model and config
• generate generates schema and resolvers
• db creates and manages database resources

Discussion

Currently the moving parts which are dependent on database are the templates, resolver generation and database creation.

The user chooses from templates in the init command which are currently db specific(postgres).

• we can separate templates into different database specific ones, like apollo-typescript-starter to apollo-typescript-pg/apollo-typescript-mongo
• we can modify init command to inject db configs and docker-composes into templates with one skeleton.

The generate command generates schema and resolvers. The resolvers are currently implemented by a Knex resolver instance which generates resolvers which use knex. This is pluggable, so for it to support a no-SQL database like mongoDB would not be difficult.

#47 The db command will create db resources in local development server. Key point is to separate concerns regarding development and production. Database to be created can be selected as we start to support different databases. But the concern of db command is to create local database.

• we can create a config file during init which store db config and accordingly create a docker-compose. But this will also have template as another moving piece which will be needed to configure.
• we should support addition of new tables, new columns(the current implemetaion of graphback needs to be a modified a bit) but dropping columns is to be debated.

Finally, we should create a graphback migrate command that will generate database definitions.

Points to note

• This is a development workflow. Dealing with production using graphback is to be ideated.

[wtrocki]

Really good discussion here. We need to get back to the updated idea of how database changes can be handled. Without bringing the tooling that can be used I think we need to think if we can build state aware generation process.

Our project would have this state from previous generation, this will allow us to calculate diff and then see diff on the database to deliver sql statements. If we do that separately we can benefit from large set of the open source libraries that do database management right.

So TL:DR idea is to detach database management problem from graphql problem by collecting schema changes and feeding them back to SQL Diff engine that can both apply changes directly or make migration scripts

[wtrocki]

Content here outdated and we have couple separate issues. Closing this one