Zgw Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Symfony/Laravel Compatibility: The zgw-bundle is a Symfony bundle, not natively Laravel-compatible. However, Laravel’s Symfony Bridge (via symfony/http-foundation, symfony/routing, etc.) allows partial integration, but full bundle adoption would require Symfony’s full stack (e.g., Dependency Injection, Event Dispatcher, Console components).
• ZGW (Zakenregister API) Alignment: The bundle abstracts Dutch government ZGW APIs (e.g., case management, document handling), making it ideal for public sector projects requiring compliance with OpenZaak/OpenIndex standards.
• Domain-Driven Design (DDD) Fit: The extend pattern and data minimization align well with Laravel’s Eloquent/Query Builder for customizing API responses and business logic.

Integration Feasibility

• High-Level Abstraction: The bundle provides pre-built API endpoints (e.g., /api/zaken, /api/besluiten), reducing boilerplate for case management systems.
• OpenRegisters Dependency: Relies on OpenRegisters (a PHP library for ZGW APIs), which may introduce external dependency risks (e.g., breaking changes in OpenRegisters).
• Laravel Workarounds:
  • Use Symfony’s HttpKernel in Laravel via spatie/laravel-symfony-support for partial bundle integration.
  • Wrap bundle services in Laravel’s DI container (e.g., via Illuminate\Contracts\Container\Container).
  • Expose bundle routes via Laravel’s router (e.g., Route::prefix('zgw')->group(...)).

Technical Risk

Key Questions

1. Why Symfony? If the project is Symfony-first, adopt the bundle directly. If Laravel-only, assess whether the trade-offs (e.g., Symfony dependency) justify the benefits.
2. Customization Needs: Does the extend pattern suffice, or will deep Laravel modifications (e.g., Eloquent models) be needed?
3. Hosting Constraints: Is the team comfortable with Symfony’s ecosystem (e.g., php-app, symfony/console) in a Laravel project?
4. Long-Term Support: Who will maintain the Symfony-Laravel bridge if the bundle evolves?
5. Alternatives: Could direct OpenRegisters integration (without the bundle) achieve similar results with less overhead?

Integration Approach

Stack Fit

• Primary Fit: Symfony 6.4+ (native bundle support).
• Laravel Fit:
  • Partial Integration: Use bundle services/routes via Symfony Bridge.
  • Full Replacement: Rewrite critical components (e.g., API controllers) in Laravel, leveraging OpenRegisters directly.
• Tech Stack Compatibility:
  • PHP 8.1+ (required by OpenRegisters).
  • Doctrine ORM (if using bundle’s database layer; Laravel’s Eloquent may conflict).
  • API Platform (if extending bundle’s API endpoints).

Migration Path

1. Assessment Phase:
   • Audit current ZGW API usage (e.g., case management, documents).
   • Map bundle features to existing Laravel services (e.g., Case, Document models).
2. Hybrid Integration:
   • Install bundle in a separate Symfony micro-service (via Docker/Kubernetes).
   • Expose bundle APIs via Laravel’s API Gateway (e.g., laravel-gateways).
3. Gradual Replacement:
   • Replace one API endpoint (e.g., /zaken) with a Laravel controller using OpenRegisters.
   • Incrementally migrate business logic from bundle to Laravel services.
4. Full Adoption:
   • Refactor bundle-dependent code to use Laravel’s DI container.
   • Replace Symfony-specific components (e.g., EventDispatcher) with Laravel equivalents.

Compatibility

Sequencing

1. Phase 1 (0-2 weeks):
   • Set up Symfony-Laravel interop (e.g., spatie/laravel-symfony-support).
   • Deploy bundle as a standalone service (if hybrid approach).
2. Phase 2 (2-4 weeks):
   • Integrate core ZGW APIs (e.g., /zaken, /besluiten).
   • Implement data minimization via Laravel middleware.
3. Phase 3 (4-6 weeks):
   • Migrate business logic (e.g., case workflows) to Laravel services.
   • Replace Doctrine models with Eloquent equivalents.
4. Phase 4 (6-8 weeks):
   • Deprecate Symfony dependencies; fully adopt Laravel.
   • Optimize performance (e.g., caching, queue workers).

Operational Impact

Maintenance

• Symfony Overhead:
  • Additional tooling (e.g., Symfony CLI, Doctrine migrations).
  • Version conflicts between Symfony/Laravel dependencies (e.g., symfony/http-kernel vs. Laravel’s illuminate/http).
• Laravel-Specific:
  • Eloquent vs. Doctrine: Requires dual database strategies during migration.
  • Artisan vs. Symfony Console: May need custom wrappers for bundle commands.
• Mitigation:
  • Containerize Symfony/Laravel services separately.
  • Use Composer scripts to manage hybrid dependency resolution.

Support

• Community:
  • Limited bundle adoption (0 stars, 0 dependents) → self-support required.
  • Rely on OpenRegisters and ZGW community (e.g., VNG repositories).
• Vendor Lock-in:
  • Tight coupling to OpenRegisters may complicate future API changes.
• Training:
  • Team must learn Symfony concepts (e.g., bundles, events) for deep integration.

Scaling

• Performance:
  • OpenRegisters is optimized for high throughput (suitable for government-scale APIs).
  • Laravel’s query caching and queue workers can complement bundle performance.
• Horizontal Scaling:
  • Bundle’s stateless design (assuming OpenRegisters is stateless) allows Kubernetes/Haven scaling.
  • Laravel’s queue system (e.g., laravel-horizon) can handle async ZGW operations.
• Database Load:
  • Data minimization (filtering) reduces payload size but may increase query complexity.

Failure Modes

Ramp-Up

• Onboarding Time:
  • Symfony Novices: 2-4 weeks to understand bundles, events, and DI.
  • Laravel Teams: 1-2 weeks to learn interop patterns (e.g