Pbj Laravel Package

Product Decisions This Supports

• Schema-first data contracts: Deciding whether message shapes (events, commands, API payloads) should be defined in schemas and code-generated rather than hand-written DTOs.
• Event-driven / messaging architecture: Supports decisions around producing and consuming structured events with binary protobuf or JSON serialization.
• Build vs. buy for the serialization layer: Informs whether to hand-roll message classes, adopt google/protobuf, or use a schema-driven abstraction like this package.
• Interoperability strategy: Whether the product needs a stable wire format that can cross PHP/JSON boundaries and potentially share schemas with non-PHP services.
• Validation boundaries: Choosing where required-field and type validation lives—at message construction (builders) versus controller/request validation.
• Service-to-service contracts: Relevant for internal APIs and async messaging where immutable, typed messages reduce integration defects.
• Roadmap input for schema registry / codegen tooling: Adoption signals demand for centralized schemas and generation pipelines.

When to Consider This Package

Consider it when:

• You are building in PHP/Laravel and already use, or plan to use, Protocol Buffers or protobuf-style schemas for message contracts.
• You need both binary and JSON serialization from the same message definitions.
• You want immutable, schema-generated message classes with fluent builders and required-field validation, rather than hand-maintained DTOs.
• You are in or aligning with the Gdbots ecosystem and its code-generation tooling.
• You can tolerate a small, single-vendor dependency and are prepared to pin, wrap, or fork it.

Look elsewhere when:

• You don't actually need protobuf semantics—spatie/laravel-data or plain DTOs will be simpler and better supported.
• You need a mature, widely adopted dependency: this package shows 0 stars and 0 dependents, a serious bus-factor and supply-chain signal.
• You require enterprise support, SLAs, or active community triage.
• Your contracts are better expressed in OpenAPI / JSON Schema and consumed by non-PHP clients.
• The team cannot own maintenance or absorb the risk of an orphaned dependency.
• You need ecosystem breadth (framework integrations, validation bridges, observability hooks) that only mainstream packages provide.

How to Pitch It (Stakeholders)

For executives: This is a niche, schema-driven messaging library that can reduce boilerplate and enforce type-safe contracts in PHP services. It is technically sound in concept (immutable messages, builders, binary/JSON serialization, Apache-2.0 licensing), but it currently has no visible community adoption. Recommendation: treat it as an evaluation candidate, not a default dependency—run a time-boxed proof of concept and decide based on whether schema-first messaging is on our roadmap.

For engineering: The package offers generated immutable message classes, fluent builders with required-field validation, and dual binary/JSON serialization—useful if we standardize on protobuf-style contracts. Risks: single-maintainer project, zero dependents, and coupling to Gdbots codegen. Mitigations: wrap it behind our own message interface, pin versions, and confirm Apache-2.0 permits an internal fork if needed. If we don't need binary protobuf interop, prefer mainstream alternatives.

Decision ask: Approve a short spike to validate fit and measure the cost of wrapping it; defer any production dependency until adoption, maintenance health, and build-vs-buy are re-assessed.