baks-dev/yandex-market
BaksDev YandexMarket is a PHP 8.4+ module for integrating the Yandex Market API, featuring per-token messenger queue transports, installable configuration and assets, and a dedicated test group for validating Yandex Market workflows.
This package is a Symfony bundle that wraps the Yandex Market API, not a Laravel-native package — the README's bin/console, Messenger transports, and retry strategy options are all Symfony idioms. Treat your Laravel app as a host that is borrowing a Symfony-shaped adapter. Plan your first hour accordingly.
Minimal steps:
Confirm the runtime floor. Requires PHP 8.4+, which in practice means Laravel 11+. If you're behind that, stop here.
Install and inspect the dependency graph before booting.
composer require baks-dev/yandex-market
composer show baks-dev/yandex-market --tree
The baks:assets:install command implies a baks-dev core bundle underneath it. Verify whether composer require pulled in symfony/framework-bundle, Doctrine, or a sibling baks-dev/* package. If it pulled a Symfony kernel into a Laravel app, that's the decision point, not a detail.
Publish config and assets using the documented command. In a Laravel context this is likely calling a Symfony console application or a bin/console shim in the package. Inspect what it writes:
php bin/console baks:assets:install
Then read every file it dropped in config/ and vendor/baks-dev/yandex-market/. This is your actual documentation — the README isn't it.
Find the token/profile model. The README says "every token gets its own queue transport with a profile name." That means tokens are a first-class concept in the package. Locate where tokens are stored (config file, entity, or database table) before you write a line of integration code.
Wire a messenger transport as the README shows:
$messenger
->transport('<UUID>')
->dsn('%env(MESSENGER_TRANSPORT_DSN)%')
->options(['queue_name' => 'profile_name'])
->retryStrategy()
->maxRetries(3)
->delay(1000)
->maxDelay(0)
->multiplier(2)
->service(null);
Your first real use case should be a single read-only call — a catalog or product-listing fetch against one token — dispatched through one transport and processed by one consumer. That validates: (a) the package boots in Laravel, (b) auth works with a real token, (c) the queue round-trip completes. Only after that green light should you touch bulk catalog upload.
Put the package behind an application-owned interface on day one. Given zero stars, zero dependents, and release notes that are literally the version number, you must assume you will fork or replace this. Define the boundary in your domain, not in the package's namespace:
namespace App\Marketplace\Contracts;
interface MarketplaceClient
{
public function fetchCatalog(string $tokenId): iterable;
public function syncPrices(string $tokenId, array $updates): string;
}
Implement it by delegating to the package. Controllers and jobs only ever see MarketplaceClient.
Mirror the transport-per-token model onto Horizon. The package's strongest idea is credential isolation: one seller's 429s or 401s do not stall another seller's catalog sync. In Laravel terms, this is a queue-name suffix per token UUID:
// config/horizon.php
'supervisor-catalog-token-a' => [
'connection' => 'redis',
'queue' => ['yandex-profile-a'],
'balance' => 'simple',
'processes' => 2,
'tries' => 3,
'backoff' => [1, 5, 10],
],
Keep queue names aligned with the package's profile_name values so your runbooks and logs stay coherent across both runtimes.
Two viable queue bridges — pick one and commit:
Job and dispatch to Horizon. Cleaner operationally, requires wrapping every call site. This is the correct choice for anything past a pilot.Design for eventual consistency, not real-time. The package is async-only and has no webhook handling. Order-status and price-index events must arrive through Yandex's native webhooks into your own controller — this is a second integration surface the package does not reduce. Order the roadmap accordingly: bulk catalog upload and scheduled price sync are the right first workloads; real-time order state is not.
// Bulk catalog sync — the natural first workflow
dispatch(new SyncYandexCatalogJob($tokenId, $batch))
->onQueue("yandex-{$profileName}");
Store credentials yourself. Tokens go in Laravel's encrypted config or a secrets manager. Do not adopt the package's token storage until you've verified its schema and rotation model — a zero-star dependency should be a stateless consumer of credentials, not their owner.
Enforce idempotency at the adapter. The README configures retries (max 3, delay 1000ms, multiplier 2) but says nothing about idempotency semantics. Cap retries at 3 with a dead-letter destination, and generate idempotency keys in your adapter layer for any write operation. Retry safety must not be assumed to be the package's responsibility.
Write contract tests against the Yandex sandbox. There is no documented endpoint coverage matrix. Enumerate what the package actually wraps with a spy/stub client before you build features on top of a method you assume exists.
bin/console, Messenger transports, retry strategies — is Symfony. Verify a service provider actually boots under Laravel before planning around it. If it doesn't, you're writing a bootstrapper, and that should be scoped explicitly.baks:assets:install implies a transitive baks-dev core. If the core is required, you are adopting a framework, not an API client. Resolve this in a one-week dependency spike with a hard go/no-go gate before any roadmap commitment.queue_name matching the consumer's --queue= argument, then the retry/DLQ state. Log the token UUID and queue name on every dispatch — you will otherwise be correlating blind.delay(1000) and maxDelay(0) are Messenger semantics, not Laravel's backoff. Don't assume the values map 1:1 when you bridge to Horizon.php bin/phpunit --group=yandex-market. Determine whether that suite runs in CI and whether it hits a mock or the live sandbox before you trust it as a safety net.yandex/baks names in practice.How can I help you explore Laravel packages today?