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, Doctrine ORM assumptions). Laravel compatibility is non-existent without significant refactoring (e.g., replacing Symfony’s EventDispatcher, DependencyInjection, and Twig components).
• Monolithic vs. Modular: Designed as a feature-rich bundle (search, GraphQL, content indexing) rather than a lightweight microservice. Not ideal for decoupled architectures (e.g., Laravel’s service container or API-first designs).
• Domain Alignment: Perfect fit for public sector digital platforms (municipalities, employee portals) with pre-built compliance patterns (e.g., German/Swiss administrative workflows). Misaligned for commercial or non-government use cases.
• Data Layer Assumptions:
  • Relies on Solr/Elasticsearch for search (via atoolo/search-bundle).
  • Uses Doctrine ORM for entity management (e.g., Person, OnlineService).
  • No native Laravel Eloquent support—would require custom adapters.

Integration Feasibility

• Symfony Bridge Required:
  • Option 1: Run Symfony as a microservice alongside Laravel (e.g., via Laravel’s HTTP client or API gateway like Kong).
  • Option 2: Rewrite critical components (e.g., search logic, GraphQL resolvers) in Laravel using:
    • Scout (for search) instead of Solr.
    • Lighthouse (for GraphQL) instead of Symfony’s GraphQL bundle.
    • Custom Doctrine-to-Eloquent mappers for entities.
• Dependency Conflicts:
  • PHP 8.1–8.4: Laravel’s minimum PHP version (8.1+) aligns, but Symfony-specific packages (e.g., symfony/dependency-injection) would conflict.
  • Composer Autoloading: Symfony’s autoload-dev and autoload may clash with Laravel’s PSR-4 setup.
• Database Schema:
  • Bundle assumes Doctrine schemas (e.g., sp_meta_string_leikanumber). Migration tools (e.g., Laravel Schema Builder) would need to replicate these tables.
  • No built-in Laravel migrations—would require manual SQL or a custom migration generator.

Technical Risk

Key Questions for the TPM

1. Architecture Trade-offs:
   • Is the team willing to maintain a parallel Symfony service or refactor the bundle for Laravel?
   • Can the project tolerate Symfony-specific dependencies (e.g., for search or GraphQL)?
2. Feature Prioritization:
   • Which bundle features are critical (e.g., search vs. GraphQL vs. content indexing)?
   • Are there Laravel alternatives for any subset of features (e.g., Scout for search)?
3. Compliance Requirements:
   • Does the project need German/Swiss public sector compliance (e.g., sp_meta_string_leikanumber)?
   • Are there legal constraints on using open-source Symfony bundles in production?
4. Team Skills:
   • Does the team have Symfony expertise to debug integration issues?
   • Is there bandwidth to write adapters (e.g., Doctrine → Eloquent)?
5. Long-Term Viability:
   • Is Sitepark actively maintaining the bundle (last release: 2026-06-03)?
   • What’s the upgrade path if the bundle evolves (e.g., Symfony 7.x requirements)?

Integration Approach

Stack Fit

• Laravel Compatibility: Low to Medium (depends on isolation strategy).
  • Direct Integration: Not feasible due to Symfony’s core dependencies.
  • Indirect Integration:
    • Option A: Symfony Microservice (recommended for critical features).
      • Deploy bundle in a separate Symfony app (e.g., Docker container).
      • Expose via REST/GraphQL API (consumed by Laravel).
      • Pros: Minimal Laravel changes, leverages bundle’s maturity.
      • Cons: Added latency, operational complexity.
    • Option B: Feature-by-Feature Porting.
      • Rewrite search (Scout + Algolia), GraphQL (Lighthouse), and content indexing (custom Laravel jobs).
      • Pros: Full Laravel control, no Symfony dependency.
      • Cons: High effort, reinvents wheel for public sector use cases.
• Recommended Stack:

  Component	Laravel Alternative	Symfony Bundle Usage
  Search	Scout + Algolia/Meilisearch	Use only if Solr is a hard requirement.
  GraphQL	Lighthouse	Avoid; rewrite resolvers in Laravel.
  Content Indexing	Laravel Queues + Custom Jobs	Port logic to Laravel’s task scheduler.
  Person/Service Entities	Eloquent Models	Map Doctrine entities to Eloquent.
  Solr Integration	Replace with Elasticsearch (via Scout)	Only if Solr is mandatory.

Migration Path

1. Assessment Phase (2–4 weeks):
   • Audit critical features (e.g., search, GraphQL, personnel directory).
   • Benchmark Symfony vs. Laravel performance for key workflows (e.g., search latency).
   • Identify non-negotiable Symfony dependencies (e.g., atoolo/search-bundle).
2. Isolation Strategy (4–8 weeks):
   • Option A: Deploy Symfony bundle as a microservice (Docker + API gateway).
     • Steps:
       1. Containerize Symfony app with the bundle.
       2. Expose endpoints via Laravel’s HTTP client or GraphQL proxy.
       3. Sync databases (e.g., shared PostgreSQL or event-driven updates).
   • Option B: Partial Porting (prioritize high-value features).
     • Steps:
       1. Rewrite search using Scout.
       2. Replace GraphQL with Lighthouse.
       3. Adapt entities to Eloquent.
3. Integration Phase (6–12 weeks):
   • API Contracts: Define JSON:API or GraphQL schemas for cross-app communication.
   • Authentication: Use Laravel Sanctum or Passport for microservice auth.
   • Data Sync: Implement database migrations or real-time updates (e.g., Laravel Echo + Pusher).
4. Testing & Validation:
   • End-to-End Tests: Validate workflows (e.g., employee search, service directory).
   • Performance Testing: Compare Symfony vs. Laravel implementations.
   • Compliance Checks: Ensure adapted features meet public sector standards.

Compatibility

• PHP Version: Bundle supports 8.1–8.4 (aligned with Laravel’s minimum).
• Symfony Version: Requires Symfony 6.3/7.0 (check Laravel’s Symfony bridge compatibility).
• Database: Assumes Doctrine ORM (PostgreSQL/MySQL). Laravel’s Eloquent can map to the same schemas.
• Dependencies:
  • Critical Conflicts:
    • symfony/dependency-injection, symfony/http-kernel → Isolate in microservice.
    • atoolo/search-bundle → Replace with Scout.
  • Low-Risk:
    • PHP 8.1+ features (e.g., typed properties) are compatible.

Sequencing

1. Phase 1: Proof of Concept (2 weeks)
   • Deploy bundle in a Symfony Docker container.
   • Test basic search and GraphQL queries via Laravel’s HTTP client