Customer Laravel Package

Technical Evaluation

Architecture Fit

• Modularity: The sylius/customer package is a decoupled component from the Sylius eCommerce suite, designed for modular integration. It aligns well with domain-driven design (DDD) and microservices architectures, where customer management is a standalone concern.
• Symfony/Ecosystem Compatibility: Built on Symfony components (e.g., Doctrine ORM, Validator, Security), it integrates seamlessly with Laravel (via Symfony bridges like symfony/console, symfony/validator, or spatie/laravel-symfony-support).
• Use Case Fit: Ideal for:
  • B2C/B2B platforms requiring granular customer profiles (addresses, billing/shipping, roles, etc.).
  • API-first applications (Sylius emphasizes REST/GraphQL APIs).
  • Legacy system modernization where customer data is siloed.

Integration Feasibility

• Laravel Compatibility:
  • Pros:
    • Laravel’s Service Container can host Sylius entities/repositories with minimal overhead (e.g., using spatie/laravel-symfony-support for Symfony components).
    • Doctrine ORM (used by Sylius) can coexist with Laravel’s Eloquent via laravel-doctrine/orm or spatie/laravel-doctrine.
    • Validation and Security layers (e.g., symfony/security-bundle) can be adapted via Laravel packages like laravel/sanctum or spatie/laravel-permission.
  • Cons:
    • No native Laravel packages for Sylius components → manual integration required.
    • Potential namespace collisions (Sylius uses Sylius\Component\Customer\*, Laravel uses App\*).
• Database Schema:
  • Sylius assumes a relational database (Doctrine). Laravel’s Eloquent can map to Sylius tables, but migrations must be manually synced.
  • Example tables: sylius_customer, sylius_customer_address, sylius_customer_group.

Technical Risk

Key Questions

1. Why Sylius over Laravel’s built-in Auth?
   • Does the project need advanced customer attributes (e.g., multiple addresses, groups, or billing plans) beyond Laravel’s users table?
   • Is eCommerce integration a future requirement (Sylius is part of a larger suite)?
2. ORM Strategy:
   • Will the team use Doctrine exclusively for Sylius tables, or hybrid Eloquent/Doctrine?
3. Authentication Flow:
   • How will Sylius’ security system interact with Laravel’s Auth (e.g., sessions, API tokens)?
4. Performance:
   • Will Sylius’ event-driven architecture (e.g., CustomerEvents) introduce latency?
5. Long-Term Maintenance:
   • Is the team comfortable with Symfony’s conventions (e.g., YAML/XML configs, bundles) in a Laravel codebase?

Integration Approach

Stack Fit

Migration Path

1. Phase 1: Proof of Concept (PoC)

   • Install sylius/customer via Composer in a new Laravel project.
   • Configure Doctrine ORM (config/packages/doctrine.yaml) alongside Laravel’s database.
   • Test basic CRUD operations for Customer and CustomerAddress entities.
   • Tools: spatie/laravel-symfony-support, laravel-doctrine/orm.

2. Phase 2: Hybrid Architecture

   • Option A (Recommended): Isolate Sylius to a microservice (e.g., Lumen or Symfony) and communicate via API.
   • Option B: Integrate Sylius into Laravel:
     • Replace Laravel’s users table with Sylius’ sylius_customer.
     • Migrate existing users via a custom script.
     • Extend Sylius entities with Laravel-specific logic (e.g., traits for API responses).

3. Phase 3: Full Adoption

   • Replace Laravel’s Auth with Sylius’ security system (if needed).
   • Build API endpoints using Sylius’ API Platform or Laravel’s Sanctum.
   • Implement event listeners for Sylius’ CustomerEvents (e.g., CustomerRegistered).

Compatibility

• Laravel Versions: Tested with Laravel 8+ (Symfony 5+ compatibility).
• PHP Version: Requires PHP 8.0+ (Sylius drops PHP 7.4 support).
• Database: Supports MySQL, PostgreSQL, SQLite (via Doctrine).
• Caveats:
  • Sylius uses YAML/XML configs (e.g., config/packages/sylius_customer.yaml).
  • No Laravel-specific documentation → rely on Sylius’ docs + trial/error.

Sequencing

1. Prerequisites:
   • Set up Doctrine in Laravel (laravel-doctrine/orm).
   • Install spatie/laravel-symfony-support for Symfony interop.
2. Core Integration:
   • Publish Sylius migrations (php bin/console doctrine:migrations:diff).
   • Configure Sylius bundles (e.g., SyliusCustomerBundle).
3. Authentication:
   • Bridge Sylius’ security with Laravel Sanctum.
4. API/Events:
   • Expose Sylius entities via Laravel API Resources.
   • Subscribe to CustomerEvents for business logic.
5. Testing:
   • Write Testbench-compatible tests for Sylius components.

Operational Impact

Maintenance

• Pros:
  • MIT License: No vendor lock-in.
  • Active Community: Sylius has a dedicated team (Sylius.com) and GitHub issues.
  • Modular: Easy to update individual components (e.g., sylius/customer without touching Sylius core).
• Cons:
  • Symfony Dependency Overhead: May require maintaining Symfony packages (e.g., symfony/validator).
  • Documentation Gap: Sylius docs assume Symfony; Laravel-specific guides are lacking.
  • Migration Burden: Switching from Laravel’s users table to Sylius schema is non-trivial.

Support

• Channels:
  • Sylius Slack/Discord: Community support.
  • GitHub Issues: Official bug tracking.
  • Sylius Professional Support: Paid option for enterprise users.
• Laravel-Specific Issues:
  • Limited Laravel-focused support → may need to engage with Sylius core team for hybrid setups.
  • Stack Overflow: Mixed results (Sylius tags are niche).

Scaling

• Performance:
  • Doctrine ORM: Optimized for complex queries (e.g., customer address hierarchies).
  • Caching: Sylius supports API Platform’s caching and Symfony’s cache layer (can integrate with Laravel’s cache).
  • Database: Scales vertically/horizontally like any Doctrine app (