Service Proxy Bundle Laravel Package

Getting Started

This is a Symfony 2 bundle, not a Laravel package — the first practical step for a Laravel developer is deciding whether to install it at all or just replicate the pattern inside app/Providers.

If you do install it:

composer require openclassrooms/service-proxy-bundle

Then check composer.json for the Symfony version constraint. The bundle name and "Symfony2" description strongly suggest a ~2.3/~2.7 era package, which means PHP >=5.3 constraints that conflict with any modern Laravel (8+ requires PHP 7.3+, Laravel 10+ requires 8.1+). On a modern app, Composer will either refuse the install or you'll need --ignore-platform-reqs, which is a red flag.

Where to look first once it's in vendor/:

1. ServiceProxyBundle.php — the bundle class, usually near-empty and only registers the DI extension.
2. DependencyInjection/ — the Extension and Configuration classes tell you every config key you actually have.
3. Resources/config/services.yml — the real wiring; this is what you'll be translating into a Laravel service provider.
4. Any Proxy / ServiceProxy class — the actual reusable logic lives here.

The first use case is almost always: wrap a third-party or legacy HTTP client behind a stable interface so the rest of your app codes against your own contract rather than a vendor SDK. In Laravel terms, that's a ServiceProxy abstract that forwards to a concrete client, bound in a ServiceProvider.

A minimal first pass in Laravel looks like:

// config/services.php entry or a dedicated config file
'payment' => [
    'base_uri' => env('PAYMENT_API_URL'),
    'key'      => env('PAYMENT_API_KEY'),
],

$this->app->bind(PaymentProxy::class, function ($app) {
    return new PaymentProxy(new VendorPaymentClient(config('services.payment')));
});

If the bundle's proxy class is simple and decoupled (no Symfony container access inside it), you can use it directly from Laravel and skip the bundle entirely.

Implementation Patterns

Decorator around an existing service. The most common pattern a service proxy enables: keep your internal InvoiceService, wrap it in a LoggingInvoiceProxy that logs every call, and bind the proxy as the interface implementation. Laravel gives you this natively via $this->app->extend():

$this->app->extend(InvoiceServiceInterface::class, function ($service, $app) {
    return new LoggingInvoiceProxy($service, $app['log']);
});

This is the pattern the bundle was almost certainly built for, so it's worth replicating even if you don't install the package.

Lazy / deferred proxies. Symfony2-era proxies were often used to defer construction of an expensive client (e.g. a SOAP or gRPC client) until first method call. In Laravel, use a closure binding or singleton() scoped to the request, and don't over-engineer it — Laravel resolves from the container lazily anyway.

Interface-first config. Define a ServiceProxyInterface with your domain methods, then wire one or more concrete implementations via config/services.php. This keeps the vendor-swap cost to a single bind() change.

Integration tip — config translation. The bundle's Configuration class (in DependencyInjection/Configuration.php) defines a nested tree. Rebuild that tree as a flat Laravel config array, then pass the relevant slice to the proxy constructor. Don't try to pull Symfony's ContainerInterface into Laravel — it's a different container and will blow up on getParameter() calls.

Workflow for a hybrid Symfony/Laravel monorepo. If you genuinely need the bundle on a Symfony side while Laravel consumes the same logic, extract the proxy class into a separate small library (packages/service-proxy) with zero framework dependencies, then register it in both. The bundle then becomes just Symfony-specific wiring; Laravel binds the same class through a ServiceProvider. This is usually the only sane way to reuse it across both stacks.

Gotchas and Tips

• This package is effectively abandoned. Zero stars, zero dependents, Symfony2-only, and Symfony 2 is EOL since January 2019. Treat it as reference source code, not a dependency. Read it, copy the proxy class, delete the vendor entry.

• Bundle vs. package mismatch. A Symfony bundle is registered in AppKernel::registerBundles(), which does not exist in Laravel. There is no auto-discovery that will make this work. Any tutorial or README you find will assume Symfony and will silently not apply to your Laravel app.

• PHP version conflicts. Symfony2 bundles routinely pin php: >=5.3.3,<7 or similar. On PHP 8.x Composer will fail resolution. Check the require block before spending time on anything else.

• Config quirks. Symfony config trees use camelCase node names (base_uri vs baseUri are inconsistent across bundles). Always read Configuration.php to confirm the exact key names — the README is often stale or missing. If a config key is silently ignored, this is why.

• Debugging. In Symfony you'd use debug:container to see the resolved proxy service. In Laravel, use php artisan tinker and app(PaymentProxy::class) to confirm the binding resolves and which class is actually instantiated. If the wrong implementation is returned, check for a later bind() override or a package service provider loading after yours.

• Proxy method signatures drift. Proxies are thin forwarders; if the underlying client changes a method signature, the proxy still compiles and fails at runtime. Write a contract test per proxied method so a vendor SDK bump fails loudly in CI, not in production.

• Extension points. Look for any CompilerPass in the bundle — that's the Symfony mechanism for decorating services at container-build time, and it's the piece with no Laravel equivalent. If the bundle relies on a compiler pass to inject the proxy, you'll need to reproduce that logic manually in a service provider's register() method.

• Do not rely on the package for security-critical proxying. A proxy that forwards credentials or mutates request payloads, from an unmaintained dependency, is a supply-chain risk. Reimplement the forwarding logic in-house with an explicit allowlist of methods and arguments.