highsidelabs / laravel-spapi Goto Github PK

First of all, thank you for this great package!

However, I'm struggling with mocking the API calls in my tests. I managed to create mocks for the different API classes like OrderV0Api. This is the basic code to create the mocks of the API classes.

    protected function credentials(): Credentials
    {
        return new Credentials($this->credentialsArray());
    }
    
    public function credentialsArray(): array
    {
        return [
            'client_id' => config('spapi.single.lwa.client_id'),
            'client_secret' => config('spapi.single.lwa.client_secret'),
            'refresh_token' => config('spapi.single.lwa.refresh_token'),
            'role_arn' => config('spapi.aws.role_arn'),
            'region' => config('spapi.single.endpoint'),
        ];
    }

    private const EMPTY_CONFIG = [
        'lwaClientId' => '',
        'lwaClientSecret' => '',
        'lwaRefreshToken' => '',
        'awsAccessKeyId' => '',
        'awsSecretAccessKey' => '',
        'endpoint' => Endpoint::EU_SANDBOX,
    ];

    public function mockSpapi(string $apiClass, array $responses, $mockTokensApi = true)
    {
        if ($mockTokensApi) {
            $this->mockTokensApi();
        }

        $mock = new MockHandler($responses);

        $handlerStack = HandlerStack::create($mock);
        $client = new Client(['handler' => $handlerStack]);

        $creds = $this->credentials();

        $config = $creds->toSpApiConfiguration();

        $config->setEndpoint(Endpoint::EU_SANDBOX);
        //$this->mockAuthentication($config);

        $this->app->singleton($apiClass, fn () => new $apiClass($config, $client));
    }

But I realized later that this does not mock the Token requests etc. which are made in the background before calling these API endpoints, because the classes create their own instances of API classes which then create the unmocked requests.
So I tinkered a bit with it and tried to mock the authentication part as well.
But I am very confused about the different classes like AuthorizationSigner, RequestSigner, Authentication, Credentials, Configuration and what not. You can see that in the code I've come up with so far:

     public function mockAuthentication(Configuration $configuration)
    {
        $accessToken = "the-access-token";

        $authSigner = $this->createMock(AuthorizationSignerContract::class);
        $authSigner->expects($this->any())
            ->method('sign')
            ->will(
                $this->returnCallback(function ($request) {
                    return $request;
                })
            );

        $client = new Client([
            'handler' => new MockHandler([
                new Response(200, [], "{\"access_token\": \"{$accessToken}\", \"expires_in\": 60}")
            ]),
        ]);

        $auth = new Authentication(
            self::EMPTY_CONFIG + [
                'authorizationSigner' => $authSigner,
                'authenticationClient' => $client,
            ]
        );

        $configuration->setRequestSigner($auth);
    }

    public function mockTokensApi(array $responses = null)
    {
        $accessToken = "the-access-token";

        $responses = !$responses
            ? [
                new Response(200, [], "{\"access_token\": \"{$accessToken}\", \"expires_in\": 3660}"),
            ]
            : $responses;

        $this->mockSpapi(TokensV20210301Api::class, $responses, false);
    }

You see its quite chaotic because I don't understand 100% what I'm actually doing.

I found that setting the Endpoint to EU_SANDBOX should avoid requesting restrictedDataTokens, but this can not be set from .env vars, because the function SellingPartnerApi::regionToEndpoint throws an exception when SPAPI_ENDPOINT_REGION=EU_SANDBOX.

I just want a setup that ensures that there are no outgoing requests made. I would appreciate help on how to set this up in a simple but robust way.

Problem description:

Hi. I've been using this library for a while. Thanks for your great efforts.
Currently I'm able to use methods like getItemOffers, getItemOffersBatch etc, so my setup seems OK. But when I try to call getFeaturedOfferExpectedPriceBatch, I get the error below.
When I try to debug, seems the error rises before my code below.
I'm using Laravel 10.45.1 and Php 8.1.10

Error:

Illuminate \ Contracts \ Container \ BindingResolutionException
Unresolvable dependency resolving [Parameter #0 [ <required> array $configurationOptions ]] in class SellingPartnerApi\Configuration

Code

$skus = [
    'my-sku-1',
    'my-sku-2',
];
$marketplaceId = 'ATVPDKIKX0DER';

$requests = array_map(function ($sku) use ($marketplaceId) {
    return new \SellingPartnerApi\Model\ProductPricingV20220501\FeaturedOfferExpectedPriceRequest([
        'uri' => "/products/pricing/2022-05-01/offer/featuredOfferExpectedPrice",
        'method' => 'GET',
        'marketplace_id' => $marketplaceId,
        'sku' => $sku,
    ]);
}, $skus);

$body = new \SellingPartnerApi\Model\ProductPricingV20220501\GetFeaturedOfferExpectedPriceBatchRequest(['requests' => $requests]);

try {
    $result = $api->getFeaturedOfferExpectedPriceBatch($body);
    return response()->json($result);
} catch (ApiException $e) {
    $jsonBody = json_decode($e->getResponseBody());
    return response()->json($jsonBody, $e->getCode());
}

Seller Central SP API config page screenshot

Can you please update the package to support Laravel 11?

Thank you Jesse

$this->apiClasses = SellingPartnerApi::getSpApiClasses();

The code above to find all the api classes runs very slowly. It takes about 0.5 seconds on my machine each time it is run. Since the service provider is created at every framework boot, this has a huge performance impact. In fact we noticed that our test suite was slowed down drastically - it took basically 5 times longer only because the above piece of code. Not to mention that the service provider also tries to obtain auth tokens every time it runs like discussed in another issue (#2 ). This impact is not even factored it.

I can think of some quick fixes to improve the performance of this service provider related to class loading by also preparing the setup to be a bit more flexible for later improvements:

• Make the class registration optional (e.g. by config/env var), so it can be deactivated during tests. The user can then either create mock classes manually or just leave it activated as before. Mocking is another topic on its own and it would be great if this would also be baked into the package, but this is not subject of this issue.
• Move the class finding (snippet above) to a place where it is only executed when the classes are actually needed (class registration enabled). Currently the api class finding is done immediately in the class constructor. It should be moved to the register function instead.

The above changes would only speed up the tests by deactivating the class registration completely. In production, we can not use a steamroller approach like this, because the binding is actually needed, so that the app knows how to resolve these classes with their correct configuration.

To reduce the performance impact in production we could:

• either move the class finding code to the config file. This way the classes can be cached together with the rest of config, if config caching is enabled. In the service provider's register we could use the config helper to get these classes, it should be way faster when the config is cached.
• or remove the class finding and list all the classes explicitly
• change the singleton binding to a normal binding.
  I am not exactly sure why singleton was chosen for this matter, but in fact when binding something as a singleton, the app will immediately call the resolve callback to make sure the instance exists. I guess using normal binding should work just as well and maybe behave more like the user would expect. It would be more a on-demand creation than creating all the objects even if they are not used at all. Of course each call would resolve it's own instance which could potentially lead to issues, but I don't think it actually will.

If my suggestions feel valid to you, I could prepare a pull request. I'm looking forward to hear your thoughts on my ideas.