We would have to be able to extend the CE GraphQL API with EE specific functionality. The GraphQL specific files should live in ee/app/graphql the parts from Gitlab::Graphql we can already deal with using what we know and love.
Things we'd need to support:
Adding fields to existing types
Add new types
Add arguments to resolvers and mutations
Looking at ee/api/entities.rb gives us a clue as to what all needs to get supported, which is quite a lot.
Here's a list of items that may need to be targeted over time, as we build out our GraphQL support. Each of these could be handled with a different issue.
So I think the bulk of the work here would be documenting that. @digitalmoksha Are there other things we need to do right now, or can we expand on that as we implement new features in GraphQL?
@reprazent OK, I think the checklist in the description makes this more intimidating! I think if we say that GraphQL is ready when we remove the feature flag, even if not every resource is exposed, that makes it easier to iterate as we go.
Sorry, I know the list is daunting. Since the issue was "Add EE specific implementations to GraphQL", there is a lot that needs to get covered, and can probably go into separate MRs.
I'm a little unclear about the reference to the design management above. In https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1099, I'm not splitting epic support into an epics directory - the files live directly in types, etc. Primarily because that was not done for CE - issues, projects, groups, labels, etc all live at the same level.
I don't have a problem breaking it out into directories, but then I think we should make app/graphql conform to the same structure.
I agree we don't need to get everything done in order to remove the feature flag. But I think it's worth noting that once we say it's ready, we need to be more careful about changing how fields work, as we have to assume that customers are using it in a real capacity. Of course we can deprecate fields, etc, I just think we'll need to start doing that. When you're in alpha, it's all considered in flux.
Ideally I would like to see more of the REST API implemented in GraphQL, as mentioned here before ripping off the alpha label. But I'm not sure that's an option.
I'm a little unclear about the reference to the design management above. In https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1099, I'm not splitting epic support into an epics directory - the files live directly in types, etc. Primarily because that was not done for CE - issues, projects, groups, labels, etc all live at the same level.
I was just pointing to it as an example of how we can add fields to existing (CE) types, in EE only. Desing management is namespaced, but that shouldn't be the standard.
I don't have a problem breaking it out into directories, but then I think we should make app/graphql conform to the same structure.
In that implementation, we're following the same kind of structure in ee/app/graphql as we do for (for example) ee/app/model:
ee/app/graphql itself could contain all types unique to EE, while ee/app/graphql/ee contains the modules that are prepended onto existing CE types.
@digitalmoksha it might be overreach, yeah. Let's discuss in the issue.
@nick.thomas@reprazent@timzallmann - do you think we can consider our GraphQL 'GA' when many resources are flat-out missing? If not, then that will push back this epic a bit
do you think we can consider our GraphQL 'GA' when many resources are flat-out missing? If not, then that will push back this epic a bit
I don't think we should strive to have all resources available, but exposing a bunch of resources, specifically ones that defer between CE/EE should make us more comfortable we know how to do it.
As @digitalmoksha mentioned in, while we're not in GA, we're free to change things until we feel like we've got it down.
I'm not sure how many resources are already exposed by now, but I see new things being added constantly, even by contributors that aren't all comfortable with GraphQL yet. So I think we could still close this for %12.0, but I'd leave that final call up to @digitalmoksha.
I'm moving this to the epic &1367 because I don't think it's needed for 'development availability'. That epic already mentions sharing out work across groups.