Remove Context Superclass – Improve Modularity and Testability

[m1roff]

Overview/summary

The Context class in the Shopify PHP API library introduces global state, making the codebase harder to test, maintain, and extend. It violates multiple SOLID principles, specifically Single Responsibility Principle (SRP) and Dependency Inversion Principle (DIP). This issue proposes refactoring to remove Context and replace it with dependency injection.

Motivation

Currently, many classes depend on Context for critical API information like:
• API keys ($API_KEY, $API_SECRET_KEY)
• Session storage ($SESSION_STORAGE)
• HTTP Client Factory ($HTTP_CLIENT_FACTORY)
• API version ($API_VERSION)
• Retry logic ($RETRY_TIME_IN_SECONDS)

This leads to tightly coupled code, where:
1. Global state makes debugging difficult – Modifying Context affects all instances, leading to unpredictable behavior.
2. Unit testing is complicated – Tests must mock the static Context state rather than injecting dependencies.
3. Extensibility is restricted – Developers cannot easily replace components like HTTP clients or storage mechanisms.

Area

The Context dependency is spread across multiple classes. Some key examples:

1. Graphql Client

Problem: Uses Context::$IS_PRIVATE_APP and Context::$API_VERSION, making it impossible to instantiate Graphql client without relying on Context.

if (!Context::$IS_PRIVATE_APP && empty($token)) {
    throw new MissingArgumentException('Missing access token when creating GraphQL client');
}

Proposed Fix: Inject Configuration object instead of relying on Context:

class Graphql {
    public function __construct(
        private readonly Configuration $config,
        private readonly HttpClient $httpClient,
        private readonly ?string $token = null
    ) { }
}

2. Http Client

Problem: Uses Context::$HTTP_CLIENT_FACTORY and Context::$USER_AGENT_PREFIX to generate requests.

$client = Context::$HTTP_CLIENT_FACTORY->client();

Proposed Fix: Pass HttpClientFactory and UserAgentProvider via constructor:

class Http {
    public function __construct(
        private readonly HttpClientFactory $clientFactory,
        private readonly UserAgentProvider $userAgentProvider
    ) { }
}

Checklist

• Refactor Context into a Configuration object that can be injected.
• Update Graphql, Http, and other dependent classes to use dependency injection.
• Ensure backward compatibility where possible.
• Improve testability by allowing mock injection.

[m1roff]

I started making changes in my Fork https://github.com/m1roff/shopify-api-php/pull/1/files, if it is interesting for someone

[younkim]

@m1roff are you still working on your forked PR? I'm starting to migrate a backend (machine to machine) rest API integration to GraphQL, and noticed this package requires Authorization Code Flow (requires human input/callback), and I was wondering if you're doing a machine-to-machine integration as well? Looks like I gotta either fork this, or just write my own implementation.

[m1roff]

Hi @younkim
Yeah, I'm working on it.
I'm not quite sure what you mean by “machine-to-machine” integration, since this library implies that you just set your authorization credentials and that's it. I.e. no human intervention is required.
My main goal is to do the review of this library so that it complies with all the basic principles of OOP, in particular SRP. And the most important thing is that there should not be one big state for the whole application.

[m1roff]

Also you can take a look to https://github.com/m1roff/shopify-api-php/pull/2/files, started fixing tests. A lot of work needed.

[younkim]

@m1roff My bad, I had a chance to actually go through the code and seeing that what I saw from the usage doc (Shopify\Utils::loadCurrentSession()) is just a helper method for regular Oauth users.

My private app is entirely backend, so it seems like I can use Context::initialize to get things started.. But not a huge fan of how it's implemented, either, and it seems risky to manage globals for multiple stores, so I just decided to write my own.