Open Belasting Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Purpose Alignment: The OpenBelastingBundle is a Symfony Flex bundle designed to interact with the PINK Open Belastingen API (Dutch tax assessment API), handling:
  • Schema validation (for tax assessment data).
  • Mappings (between internal models and API payloads).
  • CRUD operations (reading tax assessments, writing objections).
• Laravel Compatibility: While the package is Symfony-specific, Laravel’s Symfony Bridge (symfony/http-client, symfony/serializer, etc.) allows partial integration. However, full bundle compatibility is unlikely without refactoring.
• Domain Fit: Ideal for:
  • Dutch tax/legal software (e.g., accounting, compliance tools).
  • Systems requiring structured API interactions with PINK’s Open Belastingen API.
• Anti-Patterns:
  • Tight coupling to Symfony’s DependencyInjection (DI) and EventDispatcher may complicate Laravel adoption.
  • No native Laravel service container support (e.g., bind()/singleton()).

Integration Feasibility

• API Client Layer: The bundle’s core logic (HTTP calls, serialization) can be extracted and adapted for Laravel using:
  • Guzzle HTTP (replacing Symfony’s HttpClient).
  • Laravel Serializer (for JSON/XML mapping).
• Database/ORM Layer:
  • Doctrine ORM (Symfony) → Laravel Eloquent (mappings would need manual conversion).
  • Schema validation could leverage Laravel’s validate() or API Resources.
• Event System:
  • Symfony’s EventDispatcher → Laravel Events (similar abstraction).
• Configuration:
  • Symfony’s config/packages/ → Laravel’s config/open_belasting.php (minimal refactor).

Technical Risk

Key Questions

1. Is the bundle’s API interaction logic reusable without Symfony?

   • If yes: Extract to a standalone PHP library (e.g., common-gateway/open-belasting-client).
   • If no: Rewrite API client layer in Laravel (Guzzle + Serializer).

2. Does the project require Doctrine ORM, or can Eloquent suffice?

   • If Eloquent is acceptable, mappings can be rewritten.
   • If Doctrine is mandatory, consider hybrid approach (e.g., API layer in Laravel, DB layer in Symfony microservice).

3. What’s the long-term maintenance plan?

   • Will the team support dual Symfony/Laravel versions?
   • Should this be a plugin (via Laravel Packages) or fully integrated?

4. Are there existing Laravel packages for PINK API?

   • Avoid reinventing the wheel (e.g., check Packagist for alternatives).

5. What’s the data flow complexity?

   • Simple CRUD → Easier to port.
   • Complex event-driven workflows → Higher refactor risk.

Integration Approach

Stack Fit

Migration Path

1. Phase 1: API Client Extraction (Low Risk)

   • Isolate HTTP logic (requests/responses) into a Laravel-compatible library.
   • Example:

     // Symfony (Original)
     $client = new Client();
     $response = $client->request('GET', '...');
     
     // Laravel (Adapted)
     $response = Http::get('...');
     

   • Use Guzzle or Laravel HTTP Client (Http::macro()).

2. Phase 2: Data Mapping (Medium Risk)

   • Replace Doctrine entities with Eloquent models or DTOs.
   • Example:

     // Symfony (Doctrine)
     $assessment = $entityManager->find(Assessment::class, $id);
     
     // Laravel (Eloquent)
     $assessment = Assessment::find($id);
     

   • For complex mappings, use API Resources or custom hydrators.

3. Phase 3: Event System (Low Risk)

   • Replace EventDispatcher with Laravel’s Event::dispatch().
   • Example:

     // Symfony
     $dispatcher->dispatch(new AssessmentCreatedEvent($assessment));
     
     // Laravel
     event(new AssessmentCreated($assessment));
     

4. Phase 4: Configuration (Minimal Risk)

   • Move Symfony’s config/packages/open_belasting.yaml to Laravel’s config/open_belasting.php.
   • Use Laravel’s config caching (php artisan config:cache).

5. Phase 5: Testing (Ongoing)

   • Rewrite tests using Laravel’s testing helpers ($this->get(), Http::fake()).
   • Example:

     // Symfony (PHPUnit)
     $client = static::createClient();
     $crawler = $client->request('GET', '/assessments');
     
     // Laravel (Pest)
     $response = $this->get('/assessments');
     $response->assertOk();
     

Compatibility

• Pros:
  • Core API logic is language-agnostic (PHP).
  • Symfony’s HttpClient and Serializer have Laravel equivalents.
• Cons:
  • Doctrine ORM is a major blocker for Eloquent projects.
  • Symfony’s Event system is similar but not identical (e.g., event priorities).
  • Flex bundle autoloading won’t work in Laravel (manual setup required).

Sequencing

1. Assess Reusability:
   • Start with a proof-of-concept (e.g., "Can we fetch one tax assessment?").
2. Decouple Dependencies:
   • Extract API client first, then tackle ORM/mappings.
3. Incremental Replacement:
   • Replace Symfony services with Laravel facades/containers.
4. Test Early:
   • Validate API responses before integrating with Eloquent.
5. Document Gaps:
   • Track unsupported features (e.g., Doctrine-specific queries).

Operational Impact

Maintenance

• Pros:
  • Reduced Boilerplate: API interactions centralized in one layer.
  • Consistent Validation: Schema rules enforced at the API boundary.
  • Symfony Ecosystem: If team knows Symfony, learning curve is lower.
• Cons:
  • Dual Maintenance: If keeping Symfony bundle for other projects.
  • Laravel-Specific Quirks: Eloquent vs. Doctrine differences may require patches.
• Mitigation:
  • Use feature flags to toggle between Symfony/Laravel implementations.
  • Contribute back to the original repo if Laravel support is added.

Support

• Dependencies:
  • Symfony Components: Requires Laravel’s Symfony bridge (e.g., symfony/http-client).
  • PINK API: Rate limits, authentication (OAuth2/JWT) must be handled.
• Debugging:
  • Symfony’s var_dump() → Laravel’s dd() or Log::debug().
  • Doctrine logs → Eloquent query logging (DB::enableQueryLog()).
• Community:
  • Low Stars (0): Limited community support; expect to troubleshoot independently.
  • Last Release (2024-03-15): Recent updates suggest active maintenance.

Scaling

• Performance:
  • API Calls: Guzzle/Laravel HTTP Client is performant; consider queueing for bulk operations.
  • Database: Eloquent is optimized for Laravel; Doctrine may need indexing adjustments.
• **Horizontal Sc