FastGQL first version roadmap

[roneli]

Hello, fastGQL users, this is a basic roadmap to complete before releasing first version of fastgql.

• Support Full CRUD
  • select support
  • insert support support create mutations #21
  • delete support Support delete mutation #22
  • update support [WIP] support update mutations #34 feat: Multi driver support #40
• Support Aggregate functions (max, sum, min, count) - didn't support sum yet Improve aggregate support #29
• Generation tests
• SQL builder tests Add tests support schema & upgrades gqlgen #17
• Cursor Pagination support
• Better docs (how to guides, adding custom scalars, custom operators, etc')
• Define better relation directives
• Code cleanup and documentation
  • Logging for schema generation
  • Cleanup schema package
  • Move packages into internal/pkg. refactor directories #33
  • Support layout of schema based on original files support schema split #38
• Multi Driver Support feat: Multi driver support #40
  • Mongo
  • SQL

if you have any suggestions or feature requests, you can add to this thread or open feature request issues depending on complexity/importance will add it to the roadmap

[namnm]

@roneli Thanks, do you have any plan to have generator with some kind of popular orm such as https://gorm.io/?
When we use an orm, all the relation (has one, has many, belong to...) are configured already. It is quite redundant to declare them again in the graphql schema

[mpieczaba]

Thanks, do you have any plan to have generator with some kind of popular orm such as https://gorm.io/? When we use an orm, all the relation (has one, has many, belong to...) are configured already. It is quite redundant to declare them again in the graphql schema

@namnm Yeah, I agree that it would be pretty handy. GORM is a useful tool not only because of its association support but also auto migration and much more.
Unfortunately, fastGQL is currently based on the pgx, which as far as I know is incompatible with the generic sql.DB interface used in GORM. I would consider switching to it as it is supported in most orms/db oriented libs.

[roneli]

@roneli Thanks, do you have any plan to have generator with some kind of popular orm such as https://gorm.io/? When we use an orm, all the relation (has one, has many, belong to...) are configured already. It is quite redundant to declare them again in the graphql schema

In general, GORM won't work well here, as it is inefficient in the query building and can't support injecting count aggregates, relational filters etc' easily I am sure it can be done, but it will require a lot of work and some workarounds.

The core idea of the fastGQL is to be a lightweight extension of gqlgen and allowing the user to supplement his gqlgen but also do this own thing + SDL approach which allows more control than DB schema approach.

[namnm]

Thanks, guess we may need to create a fork from your repo to work with gorm.

[mpieczaba]

Thanks, guess we may need to create a fork from your repo to work with gorm.

@namnm Not really. I can work over the weekend on moving to the generic sql.DB interface and propose my solution to @roneli. Then he will decide what to do with it.
If he accepts it, you would have opportunity to add GORM to your project like so. I will also try to make filter, sort and pagination queries reusable with different query executors. This feature would make fastGQL more extendable and allow to use this excellent tool not only with GORM but all sort of db oriented libs.

[newbeelearn]

If i understand correctly i don't need dataloader with this, right?

[roneli]

If i understand correctly i don't need dataloader with this, right?

No you don't, it transforms the whole GraphQL query to an equiv SQL query. So all requested data is returned in one execution, and it just auto resolves from there. Obviously you can add more logical gqlgen stuff on top of it if you desire.