Should we organize GraphQL library code by function?

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

The following discussion from !55306 (merged) should be addressed:

• @digitalmoksha started a discussion: (+1 comment)

  I'm wondering about the namespacing. We've currently got loaders, extensions, query_analyzers. It seems like having a directory field_extensions, with calls_gitaly_extension.rb and present_extension.rb

  wdyt?

@alexkalderimis replied:

I think that comes down to should we have modular namespacing (gitlab/graphql/calls_gitaly with extensions and loaders and such inside) where code is organized by related module or functional namespacing (gitlab/graphql/field_extension) where code is organized by what kind of thing it is.

I think both have their place in sherpaing us through the rugged landscape we have built for ourselves, and there is clearly wide usage of functional namespaces in Rails (models/controllers/views but also graphql/{types,resolvers,mutations}).

However, since these modules were originally organised as library modules, not in functional locations, I suggest we keep them as before (which means we don't need to make new directories) and leave the discussion of whether we need a gitlab/graphql/field_extensions directory one for the @gitlab-org/graphql-experts group to have on a subsequent issue.