Refactoring graphql helpers and integrating fragments.

[SahilKalra98]

I wanted to pick up the issue here which talks about the use of integrating fragments to reduce the duplication of code.

I was going to start doing that but then I saw these two similar issues: refactoring graphql helpers and documenting.

They way I am thinking of approaching the problem is:

1. Documenting each of the queries/mutations first. Flacial provided an example here
2. When those files get documented, then we can refactor the resolvers so they aren't in different places.
3. The final step would be to then integrate fragments to reduce the complicity of the queries/mutations.

Questions

Some questions I had were:

1. Where would the documentation of the queries and mutations be? Would it be in the github wiki docs?
2. For refactoring the resolvers, do we move the files from helpers/controllers to the graphql folder and split the resolvers into queryResolvers and mutationResolvers?

[flacial]

I agree with your approach.

Where would the documentation of the queries and mutations be? Would it be in the github wiki docs?

Yeah, I think the data flow page is suitable for this or a new page because GraphQL resolvers play a significant part in c0d3 app.

For refactoring the resolvers, do we move the files from helpers/controllers to the graphql folder and split the resolvers into queryResolvers and mutationResolvers?

I think we can have another one called groupResolvers (perhaps a better name) along with the ones you mentioned. It's for resolvers that fall under one group or a set. Like user resolvers for deleting, adding, (mutations) and retrieving the user data (queries).

[songz]

I finally wrote it: https://github.com/garageScript/c0d3-app/wiki/A-request-journey

Here's what I noticed:

I noticed that in the resolvers file some resolvers come from /helpers/controllers/ and some resolvers come from /queryResolvers/lessons. We should be consistent.

I noticed alot of resolvers have the same repeating req.user? check like this one, which could be replaced by withUserInfo container.

[songz]

I don't think we need to document every query/mutation, alot of them are self explanatory I think

[songz]

@SahilKalra98

this issue is about either using queryResolvers folder or controllers folder.

We should vote on it in discord.

This wiki has been created, please add to it (or edit) if you need to! #1199

Documenting each of the queries/mutations first.

I think this is a good idea, especially to remove the ones that are not used. Perhaps you could add a Other Resolver Header in A request Journey to talk about the resolvers that are not covered in the requests?

When those files get documented, then we can refactor the resolvers so they aren't in different places. The final step would be to then integrate fragments to reduce the complicity of the queries/mutations.

Make sense!

Where would the documentation of the queries and mutations be? Would it be in the github wiki docs?

I would build on the request story and then add a Other Resolver header to cover the other queries/mutations that are not mentioned.

For refactoring the resolvers, do we move the files from helpers/controllers to the graphql folder and split the resolvers into queryResolvers and mutationResolvers?

I think we can move the files from helpers/controllers to resolvers. No need to split b/w queryResolvers and mutationResolvers.