Output the resolver code in addition to the GraphQL Schema Code

[llamaferoze]

I believe this should be tagged as an enhancement.

Due to our conversation here - #252

It seems that the code for the resolvers are generated and held in memory at the moment. It would be extremely useful if the code for the resolvers were output to a file. That way the developer can use the output graphQL schema code, and the output resolver code as a complete graphQL implementation. I believe this code the schema plus resolvers is everything you need to run the graphQL server and this would allow the developer complete control and the main use of OtG would be to create the initial code from OpenAPI schemas. OtG would not actually have to be included in the server, only to generate the graphQL code (schema + resolvers) used in the server.

This way the frontend team can use the initial generated schema as the client API. Then the backend team can change while the client API (aka graphql schema) stays the same in sync for the needs of the applications and separate from arbitrary backend changes. The graphQL client API (initially generated by OtG) can be evolved by frontend developers manually overtime in response to the actual needs of the client application, not the needs of backend team.

[wtrocki]

I'm a community member, but I will be happy to explore this option if maintainers agree to do it.
I was playing with a couple use cases for this.

The entire workflow can be used now by composing couple existing libraries:
Building an Restful client from OpenAPI and then dynamically assigning it into generated resolvers.

1. Pick generator you want. For example:
   https://openapi-generator.tech/docs/generators/typescript-axios

2. Wrap them into DataLoaders if needed

3. Generate empty resolvers using graphql-code-generator

4. Generate schema file using OtG

This is my fav workflow as benefit of the GraphQL is that you can shape schema to format you want but ability to call restful backend in best performant way is still a big deal when starting with GraphQL.

[llamaferoze]

@wtrocki awesome, and I as well. Let's see what @Alan-Cha thinks and if he has any guidance on a plan for implementation, maintenance, and testing for it.

[Alan-Cha]

@llamaferoze Thank you so much for following up on this and filing an issue!

I think this is the next big step for OtG. Currently, OtG is a good way to get started with GraphQL, to experiment and test it. However, I'm not 100% convinced it should be used long term because it is limiting in some ways (forcing you to be tied down to a REST API backend for example). If we can generate raw schemas and resolvers, I think using OtG will be the ideal starting point for providers to leverage their preexisting REST API portfolio and transition into GraphQL. From there, they can either continue to use OtG or take the reins and develop the raw GraphQL interface.

Honestly, I'm not too sure how to begin. Code generation is something completely new to me. I will need to do more research to develop a clearer sense on what to do. I'm assuming that we would like to output, at least for now, code that utilizes the basic graphql.js reference implementation and the request module, something basic that uses as few external modules as possible. If you and @wtrocki would like to take a swing at it, that would be immensely helpful! I will try my best to help as well, of course.

[wtrocki]

Honestly, I'm not too sure how to begin. Code generation is something completely new to me.

Graphback (the project I'm actively maintaing) will have some code generation capabilities and it is already integrating with OtG.

npm install -g graphback-cli
graphback init yourproject
graphback openapi yourapifile.yml
// Review your graphql model and add extra ID's that might be needed.
graphback generate
graphback db 

Documentation: https://graphback.dev/docs/openapi

This is a database migration workflow.
We are also working on RESTFULL API path - I have a raw spike for that use case that we postponing because of the reachitecture that is happening currently.
Maybe we can simply provide some reusable modules in Graphback and see if we can simply import them inside OtG without bringing some complex libraries to the core.

WDYT?

[Alan-Cha]

Actually, before I say anything, I'm so sorry. This issue has already been filed, #16. Could we move this discussion there? My apologies.

[llamaferoze]

@Alan-Cha ah nice, yes lets move the discussion to the existing thread, and since this discussion is linked to the existing thread now I will close this one.