Skip to content

Refactor Gitlab::SubscriptionPortal::Client class

Vijay Hawoldar requested to merge vij-refactor-subscription-portal-clients into master

What does this MR do?

The subscriptions portal (CustomersDot) has both the old REST API and the newer GraphQL one.

Currently, there are only a few integrations with those APIs, but both are mixed into the same class.

As we begin to use CustomersDot more as an API only, and with it's expansion of GraphQL support (much like GitLab), this class structure may become unsustainable / messy and confusing.

As part of https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2624, we'll need another GraphQL query, so I'd prefer to address this sooner rather than later. I've created this MR to refactor the existing class into two new concerns.

Other notes

Given the "subscription portal" went through a rename to CustomersDot, we should also rename it in GitLab, but because of the potential impact (number of files changed etc) I think that'd be best to address in a follow up issue/MR rather than in this one

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • Label as security and @ mention @gitlab-com/gl-security/appsec
  • The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
  • Security reports checked/validated by a reviewer from the AppSec team

Refs https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2624

Edited by Vijay Hawoldar

Merge request reports