Dto Api Bundle Laravel Package

Product Decisions This Supports

• Contract-first API design. DTOs become the single source of truth for request/response shapes, with OpenAPI generated from them. This directly supports the decision to treat the API spec as a versioned product artifact rather than a wiki page that rots — you eliminate the "docs drift" class of bugs and the support tickets they generate.
• Build vs. buy on the API plumbing layer. The alternative is hand-rolling serializer configuration plus hand-maintained OpenAPI annotations, or adopting a much heavier framework. This bundle is the "thin convention" option: opinionated enough to remove boilerplate, small enough to reason about. That is a legitimate third option between "write it ourselves" and "adopt API Platform."
• Streaming responses as a roadmap input. Native streaming support changes what you can promise for large exports, report downloads, and high-cardinality list endpoints without ballooning memory or introducing async infrastructure. If your roadmap contains "customer data export" or "generate report" features, this is a materially cheaper path than a queue-plus-S3 job.
• API surface scoping. "Boring JSON APIs" is a deliberate constraint. This supports the decision to not over-invest in a general-purpose API framework when the actual product need is CRUD-plus-a-few-actions — relevant for internal back-office APIs, service-to-service endpoints, and partner integrations where contract stability matters more than flexibility.
• SDK / integration enablement. Autogenerated OpenAPI unlocks client codegen and partner-facing docs as a low-marginal-cost follow-on, which is a product decision (open the API to third parties?) that becomes much cheaper to say yes to.

When to Consider This Package

Consider it when:

• You are on Symfony — this is a Symfony bundle, not a Laravel package. The Laravel framing is a mismatch: there is no Laravel service provider here, and adopting it in a Laravel codebase means an unsupported integration layer. That is a hard blocker, not a tradeoff.
• You are on a currently supported Symfony version. v0.1.5 added Symfony 8 support, so the package tracks the current major release rather than pinning you to an older one. Confirm your PHP version is inside the bundle's composer.json constraint before you plan around it — that, not the Symfony major, is usually the real gate.
• You are greenfield on a narrow, JSON-only API surface where DTO discipline is already the team norm.
• OpenAPI is a deliverable, not a nice-to-have (partner API, public API, compliance requirement).
• You need streaming endpoints and want them without new infra.
• You can treat adoption as a contained spike: one service, one bounded context, with an exit ramp.

Look elsewhere when:

• Adoption signals are absent. 0 stars and 0 dependents means zero evidence of production use, zero peer review, and no community bug-finding. The composite score here should be discounted heavily — it is measuring code shape, not trust. There is no ecosystem, no Stack Overflow surface, no third-party tutorials. A Symfony 8 compatibility patch does not move this number; it makes the package usable on current Symfony, not proven on it.
• Bus factor is 1. A single-maintainer dependency in your request path needs either a fork plan or a contractual relationship. Neither is available by default. The v0.1.5 release is a mild positive — the maintainer is responsive to upstream framework releases rather than letting the bundle drift — but one patch is a data point, not a track record.
• You need API stability guarantees. The package is 0.x. Patch releases are not contractually free of behaviour changes, and the compatibility bump itself is the kind of change that lands in a minor/patch on a pre-1.0 library. Pin the exact version and read the diff on every bump; do not rely on semver to protect you.
• You need batteries. Authentication, rate limiting, pagination, filtering, versioning, content negotiation, and HATEOAS are not the pitch here. If those are on the near roadmap, API Platform or NelmioApiDocBundle + your own conventions is the lower-total-cost choice.
• Procurement or security review applies. No release cadence history beyond a handful of 0.1.x patches, no security disclosure policy, no CVE track record. Some orgs cannot approve this dependency at all.
• You need GraphQL or RPC-style contracts. Wrong tool.

How to Pitch It (Stakeholders)

To executives: This is a small, focused library that makes our JSON APIs cheaper to build and keeps our API documentation automatically correct, because the documentation is generated from the same code that defines the data. Concretely: less time per endpoint, fewer integration bugs, and partner-facing docs that update themselves. It also gives us streaming responses without buying new infrastructure. The latest release (v0.1.5) adds support for the current Symfony version, so it is not a stale dependency — it will run on the stack we would actually build on.

The honest caveat, stated plainly: it is early. Zero public adoption, one maintainer, still pre-1.0. The new release is a compatibility patch, not a maturity signal — it tells us the maintainer is awake, not that the code is battle-tested, and on a 0.x package we should assume pinning rather than semver protection. We should not make it a foundational dependency. Recommendation: run a two-week spike on one non-critical service, measure endpoint build time against our current approach, and pin the exact version. Our exposure is bounded — the DTOs we write are portable, so if we switch to Nelmio or API Platform later, we keep the design work and lose only the wiring.

To engineering: DTO-first ergonomics, generated OpenAPI, streaming, no framework lock-in on your domain code. Runs on Symfony 8 as of v0.1.5 — verify the PHP constraint matches our runtime before committing. Wrap it behind a thin internal interface so the blast radius is one package swap. Add contract tests on the generated spec so a version bump can't silently break clients. Pin the exact version, read the changelog on every bump (expect compatibility patches to land in 0.1.x), watch the repo, and assign an owner — this dependency needs a named human, not a committee.