Lenats Laravel Package

Product Decisions This Supports

• Architecture direction: event-based / streaming backbone. The package is a concrete artifact of the "should we move to event-driven architecture?" conversation. Because it wires PHP into NATS Streaming (STAN), it lets you prototype pub/sub, at-least-once delivery, and durable subscriptions without writing a transport layer from scratch — useful for validating whether asynchronous events actually simplify a roadmap item (e.g., decoupling billing from fulfillment) before committing to a platform choice.
• Build vs. buy vs. borrow. Treat this repo as borrow the design, not the code. It is a compact reference implementation of the NATS Streaming client surface in PHP: connection lifecycle, channel/subject naming, subscription handlers, message acknowledgment semantics. That is enough to scope a spike or write an ADR, and to estimate the real cost of a first-party implementation.
• Framework-fit decision (Laravel vs. Symfony). The package is a Symfony bundle — service providers, DI config, bundle registration. Adopting it inside a Laravel app means fighting two ecosystems and owning the glue yourself. That is a direct input to the "standardize on one framework for eventing" decision, and to whether an internal abstraction layer is worth funding.
• Vendor/dependency risk policy. Stars (2), dependents (0), archived status, and a DEPRECATED banner are exactly the signals a PM uses to justify a "no unmaintained dependencies in the critical path" policy. Use it as the worked example when proposing a dependency review gate.
• Licensing posture for a commercial product. GPL-3.0 in a distributed PHP application is a legal-review trigger. This supports the decision to prefer MIT/Apache-licensed eventing components, or to keep any GPL component strictly behind a process/network boundary.

When to Consider This Package

Consider only as a reference, and only if:

• You are evaluating NATS / NATS Streaming as a transport and want to see what a PHP client integration looks like end to end.
• You are writing a technical spike, an ADR, or an architecture pitch and need a concrete prior-art citation.
• You are already on Symfony and inheriting an existing NATS Streaming deployment — in which case read the code, then look for the maintained successor.

Do not adopt when:

• You are on Laravel. No service provider, no Laravel-native config, no illuminate/* integration. You would be maintaining a bridge forever.
• You need supported, maintained code. The project is archived and explicitly deprecated. There is no security-response path, no PHP version treadmill, no bug fixes. Anything you build on it becomes your codebase's problem on day one.
• You are on NATS Streaming (STAN) at all. STAN is itself superseded by JetStream in the NATS ecosystem. Building on a deprecated client for a deprecated server feature is a compounding bet. Evaluate a JetStream-capable PHP client instead.
• Your license model can't absorb GPL-3.0. Especially for on-prem or distributed binaries.
• You have a low risk tolerance and no in-house PHP eventing expertise. Zero dependents means zero community debugging surface; support is entirely you.

Default recommendation: cite it, don't ship it. If event streaming is on the roadmap, fund a short spike against a maintained client and write the ADR this repo makes easy to justify.

How to Pitch It (Stakeholders)

For executives — one paragraph. We evaluated lebrains/lenats, a PHP/Symfony integration for NATS Streaming, as a shortcut to event-driven architecture. It is archived, deprecated, has effectively no adoption (2 stars, 0 dependents), and carries a GPL-3.0 license — so it is not a viable production dependency. Its value to us is as a cheap reference: it confirms that the PHP client surface for this kind of streaming is small and well understood, which de-risks our own build estimate. Recommendation: do not adopt; use it to inform a spike and an architecture decision record, and select a maintained, permissively licensed alternative if we proceed.

For engineering — the practical read. It's a Symfony bundle wrapping a NATS Streaming client: connection management, publish, subscribe with handler callbacks, ack/nak semantics. Two things to take from it: (1) the integration surface is genuinely thin, so a first-party Laravel package on top of a maintained NATS client is a small, bounded piece of work; (2) the deprecation is a signal about the transport, not just the wrapper — STAN is superseded by JetStream, so don't let this repo anchor us to the old model. If we go ahead, target JetStream and keep the transport behind an internal interface so the roadmap isn't coupled to a client library again.