Restfony Bundle Laravel Package

Getting Started

The first thing to internalize: pgs-soft/restfony-bundle is a Symfony 3 bundle, not a Laravel package. There is no ServiceProvider, no facade, no config/restfony.php. A Laravel developer's realistic paths are (a) treat it as a reference implementation for a CRUD API layer, or (b) run it in a small Symfony sidecar service and consume it over HTTP.

Minimal steps if you actually need to run it:

1. Create a Symfony 3.4 app (composer create-project symfony/framework-standard-edition) on a PHP version matching its constraints (expect PHP 5.5–7.x territory).
2. composer require pgs-soft/restfony-bundle.
3. Register the bundle in app/AppKernel.php inside registerBundles().
4. Look first at these files on GitHub: Controller/ (the base CRUD controller), DependencyInjection/Configuration.php (the config tree / bundle alias), and Resources/config/ (service wiring and routing).
5. Define a Doctrine entity, point the bundle's CRUD controller at it, and expose the routes.

First use case: stand up a single-resource CRUD endpoint (GET /items, POST /items, GET/PUT/DELETE /items/{id}) in the sidecar, then call it from Laravel with Http::baseUrl(...). If you only want the pattern, read the controller and reimplement it with Route::apiResource + Form Requests + API Resources — that is where most of the day-to-day value is.

Do not add it to a Laravel composer.json expecting it to boot; Composer will autoload the namespace, but nothing will register.

Implementation Patterns

Sidecar service (recommended if you must use it). Run a Symfony 3 app containing the bundle as a dedicated API process. Laravel owns auth/session/queues; Symfony owns the CRUD resource. Wire it with a scoped HTTP client:

// config/services.php
'restfony' => [
    'base_uri' => env('RESTFONY_URL'),
    'token'    => env('RESTFONY_TOKEN'),
],

Wrap calls in a small repository class with Http::retry(...) and map responses into Eloquent-shaped DTOs so the rest of the Laravel app doesn't know a second framework exists.

Porting pattern (recommended if you just want the behavior). Translate the bundle's conventions 1:1 into Laravel idioms:

• Bundle CRUD controller action → Route::apiResource('items', ItemController::class)
• Bundle entity + validation → Eloquent model + FormRequest
• Bundle serialization config → JsonResource
• Bundle pagination/filtering → query scopes + LengthAwarePaginator
• Bundle error responses → Handler / responsable exceptions

Keep a side-by-side mapping table in your repo; it makes future parity checks cheap.

Contract-first integration. Whether sidecar or port, publish an OpenAPI spec for the CRUD resource and generate/validate both sides against it. This is the only reliable way to keep a Symfony 3 app and a modern Laravel app in sync.

Shared-database pattern. If the sidecar and Laravel share a DB, let exactly one service own writes per table. Symfony/Doctrine and Eloquent migrations drift fast; assign migration ownership to Laravel and have Doctrine map to existing tables.

Auth bridging. Issue a short-lived signed token from Laravel, verify it in the Symfony app (shared secret or JWKS). Don't try to share Laravel's session cookie.

Gotchas and Tips

• Symfony 3 is end-of-life. Security fixes stopped years ago, and its dependency constraints will fight PHP 8+. Pin PHP and audit the transitive tree before exposing it to the internet.
• License is NOASSERTION. Composer could not classify it. Read the actual LICENSE file in the repo and get sign-off before commercial use — do not assume MIT.
• Adoption signals are weak: 6 stars, 0 dependents. Treat it as unmaintained; vendor or fork it if you depend on it, and expect to own bug fixes.
• No Laravel integration exists. There is no service provider, facade, publishable config, or Artisan command. Mixing Symfony DI and the Laravel container in one process is not supported — keep them in separate apps.
• Config key confusion. The bundle alias in Configuration.php may differ from the package name; check it before writing YAML. Wrong alias silently ignores your config.
• Doctrine vs Eloquent. Entity mappings, lifecycle callbacks, and lazy loading do not map cleanly onto Eloquent. Don't try to reuse one model layer for both.
• Route and serializer quirks. CRUD route generation and serialization groups are the two places most behavior is customized; override services in services.yml rather than editing vendor code, and prefer compiler-pass-free overrides.
• Debugging. In the sidecar, use the Symfony profiler and var/log/dev.log; from Laravel, log full request/response bodies behind a feature flag and use Http::fake() in tests. Cross-framework bugs are almost always serialization or status-code mismatches, not logic.
• Extension points that actually work: extend the base controller, override service definitions, and add Doctrine event subscribers. Avoid monkey-patching the bundle's routing loader.
• Migration escape hatch. If the sidecar becomes a burden, the port to Laravel resource controllers is mechanical — budget it early rather than after the Symfony app accumulates business logic.