Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Yprox Api Client Bundle Laravel Package

yproximite/yprox-api-client-bundle

A Symfony bundle that integrates the Yprox API client into your application, handling service wiring and configuration so you can connect to the Yprox API with minimal setup. Install via Composer, configure your credentials, and inject the client where needed.

View on GitHub
Deep Wiki
Context7

Getting Started

Verdict up front: this bundle is archived (last release 2020‑11‑03), has zero stars, zero known dependents, and wraps a proprietary‑ish API client for the yProx platform. Treat it as a legacy integration you maintain yourself, not a package you adopt for a new build.

Minimal steps:

  1. composer require yproximite/yprox-api-client-bundle — expect constraint conflicts on modern Symfony. The 2020 release line targets Symfony 4.x/5.0‑era APIs, so on Symfony 5.4+/6+/7 you will likely need --ignore-platform-reqs and a conflict/replace block, or a fork. Check composer why-not before fighting it.
  2. Register the bundle in config/bundles.php (or app/AppKernel.php on older skeletons).
  3. Configure credentials in config/packages/yprox_api_client.yaml (name may differ slightly — confirm against DependencyInjection/Configuration.php in vendor/).
  4. Look first at vendor/yproximite/yprox-api-client-bundle/src/DependencyInjection/ — the Configuration class is the only reliable documentation for the config tree, and services.yaml/*.xml tells you the service IDs and whether an autowiring alias exists.
  5. Confirm what you can inject: bin/console debug:container yprox --show-private and debug:autowiring yprox.

First use case: a one‑shot smoke test. Inject the client into a tiny console command, call the cheapest read endpoint (a ping/category/product list), dump() the response, and verify auth + base URI before wiring anything into domain code.

// src/Command/YproxSmokeTestCommand.php
$client = $this->getContainer()->get('yprox_api_client'); // confirm real ID first
$response = $client->someReadCall();
dump($response);

If the smoke test fails, the problem is almost always base URI, auth header, or an SSL/proxy setting — not the bundle.

Implementation Patterns

Don't inject the raw client everywhere. Wrap it once:

final class YproxGateway
{
    public function __construct(private object $client) {}

    /** @return ProductDto[] */
    public function fetchProducts(array $filters = []): array
    {
        // translate your domain filters -> client call -> map to DTOs
    }
}

This is the single highest‑value pattern here: it isolates the archived dependency to one file, makes mocking in tests trivial, and lets you swap to hitting the API directly with symfony/http-client later without touching call sites.

Sync/import jobs. The typical real usage is pulling yProx catalogue data into your own DB. Structure it as:

  • a console command that only parses options and dispatches messages,
  • a Messenger handler doing per‑batch work (offset/limit paging),
  • idempotent upserts keyed on the remote ID,
  • a cursor/updated_since value stored in a small state table so re‑runs are incremental.

Caching. Wrap read calls in symfony/cache with a short TTL. yProx data changes on a schedule you control; hammering the API on every request is the classic failure mode.

Feature isolation via config. Put base URI, token, and timeout in env vars (YPROX_API_BASE_URI, YPROX_API_TOKEN) and reference them from the bundle config. This is what makes local/staging/prod sane and lets you point tests at a stub server.

Testing.

  • Unit: mock your YproxGateway, never the vendor client.
  • Integration: point the base URI at a small fixture server (symfony/http-client MockHttpClient, or a WireMock container) and assert request shape.
  • If the client is PSR‑18 based, nyholm/psr7 + Http\Mock\Client gives you clean request assertions.

Async. Any write or bulk operation goes through Messenger with retries and a dead‑letter transport. The API client has no built‑in retry semantics you should trust from a 2020 package.

Gotchas and Tips

  • Archived = no fixes. No PHP 8.1+ deprecation fixes, no Symfony 6/7 support, no security patches. Budget a fork (rename it, drop it into src/ or a private repo) if you must keep it. If the underlying yprox-api-client library can be used standalone, prefer composer require that directly and skip the bundle entirely — a thin service definition in services.yaml replaces most of what a bundle like this does.
  • Autowiring may not work. Many small bundles of this era expose a concrete service ID but no interface alias. If debug:autowiring shows nothing, add your own alias in config/services.yaml rather than guessing class names in constructors.
  • Config tree is the docs. With no maintained README, DependencyInjection/Configuration.php and the bundle's DependencyInjection/*Extension.php are your source of truth. Config key names in blog posts and older snippets are frequently wrong for the final 2020 release.
  • After config changes: bin/console cache:clear — the compiled container caches the client's constructor arguments, so a changed token silently keeps the old value until you clear.
  • Debugging HTTP: enable framework.http_client.default_options logging or attach a PSR‑3 logger to the underlying client. If the bundle builds its own client, decorate it: define a decorates: <client_service_id> wrapper that logs request/response pairs. That's your extension point for retries, metrics, and tracing without forking.
  • Extending: the cleanest hooks are (a) decorate the client service, (b) override the bundle's service definition in your own services.yaml with a higher‑priority definition, or (c) a CompilerPass if you need to swap it conditionally per environment. Avoid editing vendor/.
  • Watch the API surface for leaks. These clients often return arrays or raw JSON rather than typed DTOs, and frequently throw generic \Exception. Normalise errors at the gateway boundary into your own exception types or you'll end up with vendor exceptions in controllers.
  • Rate limits and pagination are undocumented — discover them empirically with a logging decorator during initial integration, and bake limit/sleep into the import command from day one.
  • Pin the exact version (0.x.y, not ^0.x) and commit composer.lock. With no maintainer, a stray composer update on an unrelated package can pull a transitive version that breaks this one permanently.
  • Migration path: because the gateway pattern isolates it, plan for eventual replacement with plain symfony/http-client calls against the same endpoints. Keep request/response fixtures from the gateway tests — they become the contract for the rewrite.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
payerurl/telegrambot-crypto-payment-instant-payout
dskripchenko/laravel-hybrid-search
riorizkyrainey/lara-ced
mehedimi/static-vel
zharp/zharp
nonsapiens/bigquery-model-sync
lgu-bayambang-ict-office/lgu-laravel-development-standards
andydefer/laravel-support
se7enxweb/flysystem
lampwick/laravel
jeslage/statamic-emojis
micahdshackelford/rmap-laravel
draftsmaninc/draftsman
square-bit/laravel-volition
himito/laravel-mailman
htinlynn/genius-helper
maco-studios/hephaestus
elmogy/larafast
xeviant/laravel-paystack
gorilladash/laravel-website-sdk