Registry Laravel Package

Product Decisions This Supports

• Modular Architecture: Enables a plugin-based system where third-party modules (e.g., payment gateways, shipping calculators) register services dynamically without core code changes. Aligns with Laravel’s Service Provider pattern but adds runtime flexibility.
• Dynamic Feature Flags: Supports runtime service swapping (e.g., A/B testing tools, experimental features) by replacing implementations via the registry.
• Build vs. Buy: Justifies adopting this MIT-licensed, dependency-free package over building a custom registry, especially for teams prioritizing developer velocity over reinventing the wheel.
• Legacy System Integration: Bridges monolithic Laravel apps with modular components (e.g., microservices, external APIs) by providing a lightweight service discovery layer.
• Use Cases:
  • E-commerce Platforms: Register payment/shipping methods dynamically (e.g., Sylius use case).
  • SaaS Multi-tenancy: Tenant-specific services (e.g., analytics tools, CRM integrations).
  • Event-Driven Systems: Dynamically attach/detach event listeners or command handlers.
  • Localization/I18n: Swap translation providers or date-time handlers per locale.

When to Consider This Package

• Adopt If:
  • You need runtime service discovery (e.g., loading plugins from disk, databases, or APIs).
  • Your architecture requires decoupling services via interfaces (e.g., PaymentGatewayInterface) without tight coupling.
  • You’re building a modular Laravel app (e.g., SaaS, CMS, or marketplace) where third-party modules must register services.
  • You want to avoid Laravel’s Service Container for dynamic cases (e.g., services not known at bootstrap).
  • Your team prioritizes simplicity over enterprise-grade features (e.g., no need for tagged services or contextual binding).
• Avoid If:
  • Your use case fits Laravel’s native container (e.g., static bindings, singletons, or tagged services).
  • You require automatic service discovery (e.g., scanning classes in a namespace; use League\Container or Laravel’s app()->tag() instead).
  • Performance is critical: The package adds minimal overhead but isn’t optimized for high-frequency lookups (e.g., >10,000 services).
  • You need advanced lifecycle management (e.g., service warm-up, caching layers).
  • Your project cannot tolerate a 3-year-old package with no maintenance (risk of PHP 8.2+ compatibility issues).
• Look Elsewhere For:
  • Enterprise Laravel: Use Laravel’s Service Container with app()->bindWhen(), app()->tag(), or Pimple for more features.
  • Microservices: Consider service mesh tools (e.g., Consul, Eureka) or DDD aggregates for distributed systems.
  • Plugin Systems: Evaluate Laravel Packages (e.g., spatie/laravel-package-tools) for standardized plugin architectures.

How to Pitch It (Stakeholders)

For Executives: "This package lets us plug in services like Lego blocks—think payment processors, analytics tools, or even experimental features—without rewriting core systems. It’s used by Sylius (a leader in e-commerce) and is MIT-licensed, so no legal risks. For example, we could let third-party vendors add their own shipping methods to our platform without touching our codebase. It’s a low-risk, high-reward way to make our system more flexible and future-proof."

For Engineering: *"The ServiceRegistry gives us a simple, interface-driven way to manage services at runtime. Here’s why it’s useful:

• Decoupling: Services register via interfaces (e.g., PaymentGatewayInterface), so we avoid circular dependencies or tight coupling.
• Extensibility: Third-party modules (e.g., from marketplaces) can drop in services without core changes. Example: A plugin could register a new NotificationChannel without us knowing about it upfront.
• Zero Boilerplate: Just register(), get(), and has()—no DI container needed unless you want to integrate it.
• Laravel-Friendly: We can wrap it in a Service Provider to bind it to Laravel’s container, enabling dependency injection where needed.

Tradeoffs:

• Not for high-performance systems (minimal overhead but not optimized for scale).
• No active maintenance (last release: 2021), so we’d need to fork it if we hit compatibility issues (e.g., PHP 8.2+).
• No advanced features like tagged services or contextual binding (use Laravel’s container for those).

Perfect for: Plugin systems, dynamic feature flags, or any case where services need to be swapped at runtime."*