Gedungbundle Laravel Package

Technical Evaluation

Architecture Fit

• Symfony 2.7 Legacy: The bundle is tightly coupled to Symfony 2.7, a deprecated framework (EOL since 2017). Modern Laravel/PHP ecosystems (Symfony 5+/Lumen/Laravel) will face major compatibility gaps, requiring significant refactoring or isolation.
• Monolithic Design: The bundle appears to bundle multiple concerns (REST API, Doctrine ORM, API docs, serialization) without clear modularity. This could lead to bloat in a Laravel project unless carefully scoped.
• Gedung-Specific Logic: The vague "Gedung" (Indonesian for "building") domain suggests this may be a niche vertical solution (e.g., property management). If the use case aligns with your product, the bundle could be a starting point, but its generic PHP/Symfony dependencies will dominate.

Integration Feasibility

• Symfony vs. Laravel: Direct integration is not feasible without a wrapper layer (e.g., a Laravel facade or microservice). Key challenges:
  • Symfony’s dependency injection (DI) and event system are incompatible with Laravel’s service container and events.
  • Doctrine ORM (v2.4.8) would require Eloquent migration or a dual-DB setup, adding complexity.
  • FOSRestBundle and NelmioApiDoc would need replacements (e.g., Laravel’s laravel/api scaffolding or OpenAPI tools like darkaonline/l5-swagger).
• PHP Version: Requires PHP 5.3.9+, but modern Laravel (8+) targets PHP 7.4+. Downgrading PHP is not recommended for security/maintenance.

Technical Risk

• High Refactoring Cost: Porting this bundle to Laravel would require:
  • Rewriting Symfony-specific components (e.g., AppKernel, Routing, EventDispatcher).
  • Adapting Doctrine models to Eloquent or a hybrid ORM (e.g., laravel-doctrine).
  • Replacing JMS Serializer with Laravel’s native serialization or spatie/array-to-object.
• Dependency Bloat: The bundle pulls in 15+ dev/prod dependencies, many of which are Symfony-centric (e.g., sensio/distribution-bundle, assetic). Only a subset would be useful in Laravel.
• Undocumented Logic: The lack of clear domain separation (e.g., "Gedung" = buildings/property?) makes it hard to assess business logic reuse. The README’s vagueness is a red flag.
• Maintainer Risk: Single maintainer (vizzlearn@gmail.com) with no activity (1 star, 0 dependents) suggests abandonware. Long-term support is uncertain.

Key Questions

1. Domain Alignment:

   • What specific "Gedung" (building/property) functionality does this bundle provide? Is it core to your product, or just a partial solution?
   • Are there existing Laravel packages (e.g., spatie/laravel-property) that solve the same problem with better support?

2. Migration Strategy:

   • Would you extract only the domain logic (e.g., models/services) and rewrite the rest, or wrap the entire bundle in a microservice?
   • How would you handle database migrations (Doctrine → Eloquent schema differences)?

3. Alternatives:

   • Could you build a minimal Laravel package from scratch using the bundle’s logic as a reference?
   • Are there Symfony 5+ bundles that offer similar functionality with better Laravel compatibility?

4. Team Capacity:

   • Does your team have Symfony/Laravel hybrid expertise to manage this integration?
   • What’s the cost of maintaining a legacy Symfony dependency in a Laravel codebase?

Integration Approach

Stack Fit

• Laravel Incompatibility: The bundle is not natively compatible with Laravel. Integration would require one of three paths:

  1. Microservice Isolation:
     • Deploy the bundle as a standalone Symfony 2.7 app (e.g., Dockerized).
     • Expose its API via REST/gRPC and consume it from Laravel.
     • Pros: Minimal Laravel changes, clear separation.
     • Cons: Added latency, operational overhead (two apps to maintain).
  2. Wrapper Layer:
     • Create a Laravel facade that translates Symfony calls (e.g., DI, events) to Laravel equivalents.
     • Example: Use illuminate/container to mock Symfony’s ContainerInterface.
     • Pros: Single codebase.
     • Cons: High complexity, fragile coupling.
  3. Selective Extraction:
     • Copy only the domain models/services (e.g., Gedung entity) into Laravel, rewriting Symfony-specific code.
     • Pros: No dependency on Symfony.
     • Cons: Manual effort, risk of missing dependencies.

• Dependency Mapping:

  Symfony Bundle/Component	Laravel Equivalent Candidate	Notes
  FOSRestBundle	laravel/api, fruitcake/laravel-cors	Replace REST controllers/routing.
  NelmioApiDocBundle	darkaonline/l5-swagger	OpenAPI documentation.
  JMSSerializerBundle	spatie/array-to-object, native JSON	Simpler serialization.
  Doctrine ORM	Eloquent, or laravel-doctrine hybrid	Schema migrations required.
  SensioFrameworkExtraBundle	Laravel’s Route::resource()	Param converters handled manually.

Migration Path

1. Assessment Phase (2–4 weeks):

   • Audit the bundle’s source code to identify reusable domain logic (e.g., Gedung entity, business rules).
   • Map Symfony dependencies to Laravel alternatives (see table above).
   • Decide on integration approach (microservice, wrapper, or extraction).

2. Proof of Concept (2–3 weeks):

   • Implement a minimal viable integration (e.g., extract one model + service).
   • Test with Laravel’s service container and Eloquent.
   • Benchmark performance vs. a native Laravel implementation.

3. Full Integration (4–8 weeks):

   • Option A (Microservice):
     • Containerize Symfony 2.7 app (Docker).
     • Set up API gateways (e.g., Laravel + Symfony communicating via HTTP).
   • Option B (Wrapper):
     • Create a GedungService facade in Laravel.
     • Use dependency injection to mock Symfony services.
   • Option C (Extraction):
     • Rewrite Symfony routes/controllers as Laravel API resources.
     • Migrate Doctrine entities to Eloquent with doctrine/dbal for complex queries.

4. Testing & Optimization:

   • Validate API contracts (e.g., request/response formats).
   • Optimize database queries (Doctrine → Eloquent may need tuning).
   • Set up monitoring for the integrated component.

Compatibility

• Critical Blockers:
  • Symfony 2.7 EOL: No security updates; requires custom patching or isolation.
  • Doctrine ORM: Eloquent and Doctrine have incompatible query builders (e.g., DQL vs. Query Builder).
  • Event System: Symfony’s EventDispatcher ≠ Laravel’s Events facade.
• Mitigation Strategies:
  • Use adapters (e.g., symfony/event-dispatcher wrapped in Laravel’s EventServiceProvider).
  • For Doctrine, consider read models (e.g., cache results in Laravel’s DB).

Sequencing

1. Phase 1: Dependency Isolation

   • Replace FOSRestBundle/NelmioApiDoc with Laravel equivalents.
   • Goal: Reduce Symfony-specific code to domain logic only.

2. Phase 2: Domain Extraction

   • Port Gedung models/services to Laravel.
   • Goal: Functional parity with minimal Symfony dependencies.

3. Phase 3: API Integration

   • Expose extracted logic via Laravel’s HTTP layer (controllers/resources).
   • Goal: Seamless API surface for consumers.

4. Phase 4: Deprecation

   • Gradually phase out Symfony bundle in favor of Laravel-native code.
   • Goal: Zero runtime dependency on Symfony 2.7.

Operational Impact

Maintenance

• Short-Term:
  • High overhead: Debugging Symfony/Laravel hybrid code will require cross-framework expertise.
  • Dependency hell: Managing composer.json conflicts (e.g., Symfony 2.7 vs. Laravel 8’s PHP 7.4+).
• Long-Term:
  • Symfony 2.7 burden: Even if