Relay Greenlight Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Legacy Dependency: The bundle is tightly coupled with the DCC (Digital COVID Certificate) infrastructure, which is deprecated since June 2023. This makes it non-viable for modern use cases unless the project is specifically tied to archival or compliance requirements for historical COVID-19 certificate systems.
• Niche Use Case: Only applicable for government-mandated health certificate validation (e.g., EU DCC relay servers). No broader business value in general-purpose Laravel applications.
• Monolithic Design: The bundle appears to be a self-contained solution with minimal extensibility outside its original scope, lacking modularity for reuse in other domains.

Integration Feasibility

• High Risk: Requires reverse-engineering of deprecated APIs (DCC infrastructure) and potential legal/compliance hurdles due to AGPL-3.0 licensing (mandates open-sourcing modifications).
• Database Schema: Likely includes hardcoded DCC-specific tables (e.g., greenlight_permits, dcc_signatures), which would conflict with existing Laravel applications unless isolated in a microservice.
• Frontend Dependency: Relies on a separate frontend app (greenlight-app), adding complexity to integration.

Technical Risk

• Deprecated Stack: PHP/Laravel versions may not align with current LTS releases, risking security vulnerabilities and compatibility issues.
• No Maintenance: Archived status means no bug fixes, security patches, or updates, increasing operational risk.
• Legal Risks: AGPL-3.0 may require open-sourcing proprietary modifications, which could be problematic for commercial applications.
• Performance Overhead: If used as-is, the bundle may introduce unnecessary bloat for non-COVID-related applications.

Key Questions

1. Why is this bundle being considered?
   • Is there a specific compliance or legacy requirement for DCC integration?
   • Are there alternative modern solutions (e.g., EU Digital Identity Wallet)?
2. What is the migration path if dependencies are deprecated?
   • How would the system handle API changes or shutdowns of the DCC infrastructure?
3. How will AGPL-3.0 licensing be managed?
   • Can modifications be isolated or relicensed without open-sourcing the entire application?
4. What are the long-term maintenance costs?
   • Who will handle security updates and deprecated dependency risks?
5. Is there a way to extract only the core logic (e.g., permit generation) without the DCC coupling?
   • Could a wrapper layer abstract the deprecated APIs?

Integration Approach

Stack Fit

• Laravel Compatibility:
  • The bundle is a Symfony Bundle, so it integrates natively with Laravel via Symfony’s Bridge (if using Laravel 5.5+).
  • PHP Version: Likely requires PHP 7.4–8.0 (based on DCC infrastructure’s last active period).
  • Database: Assumes Doctrine ORM (PostgreSQL/MySQL), but schema may conflict with existing migrations.
• Frontend Dependency:
  • The bundle expects a React-based frontend (greenlight-app), which would need to be rebuilt or replaced for modern SPAs (e.g., Vue, Svelte, or Laravel Livewire).

Migration Path

1. Assessment Phase:
   • Audit all DCC-dependent logic and identify critical vs. non-critical components.
   • Check if alternative APIs (e.g., EU ESSIF-Lab) can replace DCC functionality.
2. Isolation Strategy:
   • Option 1: Microservice Approach
     • Deploy the bundle as a separate Laravel microservice with a REST/gRPC API to avoid polluting the main app.
     • Use message queues (Laravel Queues) for async permit processing.
   • Option 2: Core Logic Extraction
     • Refactor permit generation logic into a standalone package (e.g., dbp/relay-permit-core) and deprecate DCC-specific code.
3. Database Strategy:
   • Schema Isolation: Use a separate database for DCC-related tables or prefix all tables to avoid conflicts.
   • Migration Wrapping: Create a custom migration runner to handle bundle-specific schema changes safely.

Compatibility

• Laravel Version:
  • Test compatibility with Laravel 10.x (latest LTS) and PHP 8.2+.
  • Expect deprecation warnings for older Symfony components.
• Dependency Conflicts:
  • Resolve conflicts with symfony/*, doctrine/*, and league/oauth2-server (if used).
  • Use Composer’s replace or conflict directives to enforce version constraints.
• Frontend Integration:
  • If keeping the frontend, containerize it (Docker) and integrate via API endpoints.
  • Alternatively, replace with a modern UI framework (e.g., Laravel Inertia + Vue).

Sequencing

1. Phase 1: Proof of Concept (PoC)
   • Spin up a clean Laravel instance and install the bundle.
   • Test basic permit generation and DCC validation in isolation.
2. Phase 2: Integration with Existing Systems
   • Mock DCC API responses (since the real API is down) to simulate behavior.
   • Implement fallback mechanisms (e.g., cached responses, manual overrides).
3. Phase 3: Deprecation Planning
   • Document all DCC dependencies and plan for sunsetting (e.g., 6–12 months).
   • Develop a replacement strategy (e.g., switch to a new health certificate API).

Operational Impact

Maintenance

• High Ongoing Costs:
  • No upstream support → All fixes must be in-house.
  • Security patches must be manually backported (if possible).
• Dependency Rot:
  • Composer dependencies (e.g., league/oauth2-server) may have unmaintained forks.
  • Database schema changes could break if the bundle evolves (unlikely, but risky).
• Documentation Gaps:
  • Incomplete docs (only README and dev docs) → steep learning curve.
  • No migration guides for Laravel version upgrades.

Support

• Limited Community:
  • 0 dependents, 1 star, archived repo → no peer support.
  • AGPL-3.0 may deter vendors from offering commercial support.
• Debugging Challenges:
  • Deprecated APIs mean no live debugging against real DCC endpoints.
  • Error logs may be unhelpful without access to the original DCC infrastructure.
• Vendor Lock-in:
  • Tight coupling with Austrian Government systems → no portability.

Scaling

• Performance Bottlenecks:
  • DCC validation is likely CPU-intensive (cryptographic operations).
  • No caching layer documented → high latency under load.
• Horizontal Scaling:
  • Stateless design? Unclear—likely session-dependent (e.g., permit generation).
  • Database connections may need connection pooling (e.g., PgBouncer).
• Cost Implications:
  • Legacy tech stack may increase cloud costs (e.g., older PHP versions require larger instances).

Failure Modes

Ramp-Up

• Onboarding Time:
  • 2–4 weeks for a senior Laravel dev to understand the bundle.
  • Additional 2–4 weeks to integrate with existing systems.
• Key Learning Curves:
  • DCC specification (EU standards for COVID certificates).
  • Symfony Bundle internals (if team is Laravel-focused).
  • Legacy OAuth2 flows (