Citygov Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Symfony-Centric: The bundle is tightly coupled with Symfony (e.g., dependency on atoolo/search-bundle, GraphQL integration, Solr/Elasticsearch indexing). Not compatible with Laravel unless wrapped in a Symfony microkernel or via API layer.
  • Risk: Laravel’s service container, routing, and event system differ significantly from Symfony’s. Bridging this gap would require:
    • A Symfony microkernel embedded in Laravel (e.g., via symfony/ux-live-component or custom bridge).
    • API-first adoption: Treat the bundle as a headless service (GraphQL/REST) consumed by Laravel.
• Domain-Specific Abstractions:
  • CityGov-specific models (e.g., OnlineServiceFeature, PersonSearch) assume municipal workflows (e.g., employee directories, public services). Not plug-and-play for generic use cases.
  • Solr/Elasticsearch dependency: Requires search backend setup, adding operational complexity.
• GraphQL Focus:
  • Heavy use of GraphQL (e.g., OnlineService queries) may conflict with Laravel’s Eloquent/GraphQL-PHP unless abstracted via API layer.

Integration Feasibility

• Laravel-Symfony Bridge Options:
  1. Symfony Microkernel in Laravel:
     • Use symfony/ux-live-component or a custom Symfony kernel loaded via Laravel’s service provider.
     • Pros: Full feature access.
     • Cons: High coupling, performance overhead, maintenance complexity.
  2. API Layer:
     • Deploy the bundle as a separate Symfony service (e.g., Docker container) and consume via GraphQL/REST.
     • Pros: Decoupled, scalable, Laravel-native.
     • Cons: Latency, additional infrastructure, authentication complexity.
  3. Feature Extraction:
     • Cherry-pick search logic, GraphQL resolvers, or content indexing into Laravel-compatible packages.
     • Pros: Modular, lower risk.
     • Cons: Reimplementation effort, loss of bundle cohesion.
• Database Schema:
  • Assumes Doctrine ORM (Symfony). Migrations would need adaptation for Laravel’s Eloquent or raw SQL.
  • Solr/Elasticsearch indexing: Requires custom Laravel listeners or queue jobs to sync with the search backend.

Technical Risk

Key Questions

1. Is the bundle’s municipal domain a hard requirement, or can we abstract its features?
   • If yes: Focus on search/GraphQL extraction.
   • If no: Evaluate alternative Symfony/Laravel bundles (e.g., spatie/laravel-search, nuwave/lighthouse).
2. Can we deploy the bundle as a microservice (API-first) instead of embedding it?
   • Pros: Cleaner Laravel integration.
   • Cons: Added operational complexity.
3. What’s the priority: Speed of integration vs. long-term maintainability?
   • Short-term: Symfony microkernel.
   • Long-term: API layer or feature extraction.
4. Is Solr/Elasticsearch a must, or can we use Laravel’s scout or meilisearch?
   • If flexible: Reduce dependency risk.
5. Do we have Symfony expertise in-house, or will we outsource the bridge?
   • Critical for microkernel approach.

Integration Approach

Stack Fit

• Laravel Compatibility:
  • Low for direct integration (Symfony-specific components).
  • Medium-High via API layer or feature extraction.
• Recommended Stack Additions:

  Component	Laravel Alternative	Notes
  Symfony Kernel	symfony/ux-live-component or custom bridge	High maintenance cost.
  Doctrine ORM	Eloquent or raw SQL	Schema migrations required.
  Solr/Elasticsearch	laravel/scout (Meilisearch/Algolia)	Simplify search backend.
  GraphQL	nuwave/lighthouse	Map Symfony GraphQL types to Laravel.
  Symfony Event Dispatcher	Laravel Events	Replace event listeners.
  Twig	Blade or Livewire	Avoid templating conflicts.

Migration Path

Option 1: API-First Integration (Recommended)

1. Deploy Symfony Bundle as a Microservice:
   • Containerize the bundle (Docker) with Symfony CLI.
   • Expose GraphQL (/graphql) and REST endpoints (e.g., /api/search).
2. Laravel Consumption:
   • Use Guzzle or Symfony HTTP Client for API calls.
   • Cache responses with laravel/cache.
3. Authentication:
   • Implement OAuth2 or API tokens for secure cross-service calls.
4. Data Sync:
   • Use Laravel queues to sync municipal data (e.g., employees, services) between systems.

Option 2: Symfony Microkernel in Laravel

1. Embed Symfony Kernel:
   • Create a Laravel service provider to load the Symfony kernel.
   • Example:

     // app/Providers/SymfonyBridgeProvider.php
     public function register()
     {
         $kernel = new \Atoolo\CityGovBundle\Kernel();
         $this->app->singleton('symfony.kernel', fn() => $kernel);
     }
     

2. Route Integration:
   • Merge Symfony routes into Laravel’s router.
   • Risk: Route conflicts, middleware mismatches.
3. Service Binding:
   • Bind Symfony services to Laravel’s container (e.g., PersonSearch).
   • Example:

     $this->app->bind(\Atoolo\CityGovBundle\Service\PersonSearch::class,
         fn($app) => $app['symfony.kernel']->getContainer()->get('atoolo_citygov.person_search'));
     

Option 3: Feature Extraction

1. Isolate Core Features:
   • Extract search logic, GraphQL resolvers, and content indexing into standalone packages.
   • Example:
     • laravel-citygov-search (wraps Solr logic).
     • laravel-citygov-graphql (adapts Symfony GraphQL types).
2. Laravel Implementation:
   • Replace Symfony dependencies with Laravel equivalents (e.g., scout for search).
3. Gradual Adoption:
   • Start with search functionality, then add GraphQL.

Compatibility

Sequencing

1. Phase 1: API Layer Proof of Concept (2–4 weeks)
   • Deploy bundle as a microservice.
   • Test GraphQL/REST endpoints from Laravel.
   • Deliverable: Functional API integration for 1–2 core features (e.g., person search).
2. **Phase 2