Kontrakdosenbundle Laravel Package

Technical Evaluation

Architecture Fit

• Legacy Symfony 2.7 Dependency: The bundle is tightly coupled to Symfony 2.7, which is end-of-life (EOL) and lacks modern PHP/Laravel ecosystem compatibility. This introduces long-term maintenance risks and security vulnerabilities.
• Monolithic Bundle Design: The bundle appears to be a self-contained API layer (RESTful endpoints via FOSRestBundle) with JMS Serializer for data transformation. While functional, this design duplicates Laravel’s built-in features (e.g., API routing, serialization) and may lead to bloat if integrated into a Laravel project.
• Doctrine ORM Dependency: Relies on Doctrine 2.x, which is not natively supported in Laravel. Migration would require Eloquent ↔ Doctrine mapping or a hybrid approach, adding complexity.
• API-First Approach: The bundle provides NelmioApiDoc for Swagger/OpenAPI docs, which aligns with Laravel’s API-first capabilities (e.g., Laravel Sanctum, API Resources). However, Laravel’s native API tools (e.g., php artisan make:resource) may offer better long-term flexibility.

Integration Feasibility

• PHP Version Compatibility: Requires PHP ≥5.3.9, but Laravel 8+ mandates PHP ≥8.0. No direct compatibility without refactoring.
• Symfony ↔ Laravel Bridging:
  • Option 1: Micro-Service Approach – Deploy as a separate Symfony 2.7 service (Dockerized) and consume via HTTP API (Laravel as client). Pros: Isolates legacy code. Cons: Adds latency, complexity.
  • Option 2: Hybrid Monorepo – Use Symfony components (e.g., HttpFoundation, DependencyInjection) via Composer in Laravel. Pros: Reuses logic. Cons: High maintenance burden, potential conflicts.
  • Option 3: Rewrite in Laravel – Port functionality to Laravel’s Eloquent, API Resources, and Sanctum. Pros: Future-proof. Cons: Significant effort, risk of feature drift.
• Database Layer: Doctrine ORM must be mapped to Eloquent or replaced with Laravel Migrations. Schema differences may require data migration scripts.

Technical Risk

Key Questions

1. Business Justification:
   • Why integrate this bundle instead of building equivalent functionality in Laravel?
   • What unique value does this bundle provide that Laravel’s ecosystem lacks?
2. Migration Strategy:
   • Should we rewrite, isolate, or deprecate this bundle?
   • What’s the minimum viable feature set needed from this bundle?
3. Team Capacity:
   • Does the team have Symfony 2.7 expertise for hybrid integration?
   • What’s the cost of maintaining a legacy stack vs. rewriting?
4. Long-Term Vision:
   • How does this fit into the roadmap for Laravel modernization?
   • Are there alternative Laravel packages (e.g., spatie/laravel-api-skeleton) that could replace this?

Integration Approach

Stack Fit

• Laravel’s Native Alternatives:
  • API Layer: Replace FOSRestBundle with Laravel API Resources + Sanctum/Passport.
  • Serialization: Replace JMS Serializer with Laravel’s built-in JSON serialization or spatie/array-to-xml.
  • Documentation: Replace NelmioApiDoc with Laravel OpenAPI (darkaonline/l5-swagger).
  • ORM: Replace Doctrine with Eloquent or Octaane ORM (if complex queries are needed).
• Compatibility Matrix:

  Feature	Laravel Native	Bundle Provides	Integration Path
  REST API	✅ (API Resources)	✅ (FOSRest)	Rewrite or proxy calls.
  Serialization	✅ (JSON)	✅ (JMS)	Replace with Laravel’s or spatie/array.
  API Docs	❌	✅ (Nelmio)	Use darkaonline/l5-swagger.
  Doctrine ORM	❌	✅	Migrate to Eloquent or hybrid approach.

Migration Path

Option 1: Full Rewrite (Recommended)

1. Audit Features:
   • Document all endpoints, models, and business logic in the bundle.
   • Identify core vs. non-core functionality (e.g., is this just CRUD for KontrakDosen or complex workflows?).
2. Laravel Equivalent Implementation:
   • Models: Convert Doctrine entities to Eloquent models.
   • API Routes: Replace routing.yml with Laravel route model binding.
   • Controllers: Rewrite as Laravel API Controllers or Resource Controllers.
   • Serialization: Use API Resources for structured responses.
   • Docs: Generate Swagger docs with l5-swagger.
3. Database Migration:
   • Export Doctrine schema → Adapt to Laravel migrations.
   • Use Laravel Schema Builder or Doctrine Migrations (if hybrid).
4. Testing:
   • Rewrite Symfony tests to PestPHP or PHPUnit for Laravel.
   • Ensure 100% feature parity before deprecation.

Option 2: Hybrid Integration (High Risk)

1. Isolate Symfony 2.7:
   • Deploy as a Dockerized microservice (e.g., symfony-kontrakdosen:2.7).
   • Expose API via HTTP (Laravel consumes it like any other service).
2. Shared Database:
   • Use a single database with Eloquent + Doctrine (risky due to ORM differences).
   • Or synchronize via events (e.g., Laravel publishes, Symfony listens).
3. API Gateway:
   • Use Laravel’s api.php routes to proxy requests to the Symfony service.
   • Example:

     Route::get('/kontrak-dosen', function () {
         return Http::asUser()->get('http://symfony-service/api/kontrak-dosen');
     });
     

4. Gradual Migration:
   • Migrate endpoints one by one to Laravel.
   • Use feature flags to toggle between old/new implementations.

Option 3: Partial Integration (Not Recommended)

• Use Composer to Load Symfony Components:
  • Load HttpFoundation, DependencyInjection, etc., into Laravel.
  • Risks: Namespace collisions, DI container conflicts, maintenance nightmare.
• Example:

  composer require symfony/http-foundation
  

  • Then manually instantiate Symfony services (e.g., Request, Response).
  • Avoid unless absolutely necessary.

Sequencing

1. Phase 1: Assessment (2 weeks)
   • Document bundle functionality.
   • Benchmark rewrite vs. hybrid costs.
2. Phase 2: Proof of Concept (3 weeks)
   • Rewrite 1 critical endpoint in Laravel.
   • Compare performance, maintainability, and feature parity.
3. Phase 3: Migration Plan (4 weeks)
   • Choose full rewrite or hybrid approach.
   • Define deprecation timeline for Symfony bundle.
4. Phase 4: Implementation (8+ weeks)
   • Rewrite: Build Laravel equivalents.
   • Hybrid: Containerize Symfony, set up API gateway.
5. Phase 5: Cutover (2 weeks)
   • Deprecate old endpoints.
   • Update client applications to use Laravel API.

Operational Impact

Maintenance