Request Controller Laravel Package

Product Decisions This Supports

• API/endpoint architecture: Informs how we structure single-action endpoints (webhook receivers, form submissions, one-off mutations). The pattern collapses validation and handling into a single invokable FormRequest, which is a concrete answer to "do we want fat controllers, action classes, or request objects?" Decide this once and apply it consistently.
• Build vs. buy (pattern vs. dependency): The package is ~a few hundred lines of MIT glue. The real decision is whether to adopt the convention, not whether to depend on the package. You can reproduce the core behavior internally in a day, which converts a "buy" decision into a "borrow and own" decision with zero vendor risk.
• Roadmap / tech-debt work: A candidate input to a refactor initiative aimed at reducing controller sprawl and standardizing validation. Useful as a reference implementation when scoping that work, especially for teams already standardized on Laravel FormRequests.
• Use cases where it pays off: Domains with many small, form-heavy actions — onboarding flows, settings screens, approval steps — where 80% of the "controller" is validation rules and the remaining logic is a handful of lines. Also useful for rapid prototyping where speed of adding endpoints matters more than long-term structure.
• Use cases where it does not: Complex multi-step workflows, authorization-heavy flows, or anything that needs orchestration across several services. Single-action requests hide too much once behavior grows past trivial.
• Release/risk posture: Last release November 2020 and 27 stars means this is a reference pattern, not a maintained dependency. Any decision here should be framed as "adopt the idea," with maintenance owned by us.

When to Consider This Package

Consider it when:

• The team is already fluent in Laravel FormRequests and wants a lighter alternative to full controller classes for simple actions.
• The codebase has a long tail of near-identical controllers whose only differences are validation rules and a few lines of persistence.
• You want a low-cost, low-commitment spike: vendor the ~small package source, read it, and decide whether the pattern fits before committing to a convention.
• You need a Laravel-idiomatic example to align engineering on "where does validation live?" without inventing a novel architecture.

Look elsewhere when:

• Laravel version support matters. A 2020 release targets the Laravel 7/8 era. Verify compatibility with your current Laravel and PHP versions before doing anything beyond reading the source; assume you may need to fork or patch.
• You need maintained dependencies. No recent releases and low adoption mean no security patching, no framework-compatibility guarantee, and no community support. Treat it as code you own.
• Your team wants established conventions. The same author's more widely adopted action-class approach (laravel-actions) covers a superset of this ground with far more usage and maintenance — evaluate that first if you're choosing a pattern.
• The action is non-trivial. Once an endpoint grows beyond validation plus a short mutation, an explicit controller or service class is easier to test, review, and hand off.
• You need clear separation of HTTP concerns from business logic for auditing, authorization policies, or layered architecture reviews.

How to Pitch It (Stakeholders)

For executives: This is a zero-cost, low-risk exploration, not a procurement. The package is a small MIT-licensed pattern that consolidates request validation and handling into one class in our Laravel stack. The upside is less boilerplate and faster delivery on simple endpoints; the downside is that it hasn't been maintained since 2020 and has negligible adoption, so we should not take it on as a production dependency. Recommendation: spend a short spike reading and, if useful, reimplementing the pattern in-house, then adopt it as an internal convention only if it measurably reduces code and review time. No budget, no vendor contract, no lock-in.

For engineering: The idea is sound and small: an invokable FormRequest that validates and then performs the action, eliminating a thin controller layer for single-action endpoints. It is easy to audit and trivial to reproduce internally, which removes the maintenance concern entirely. Two cautions: (1) compatibility is unverified against current Laravel/PHP — check before relying on the package itself; (2) the same author's action-class library is the more proven expression of this idea and is worth comparing before we standardize. Proposal: one engineer, one short spike, one documented internal convention, with a clear rule for when an endpoint outgrows the pattern and graduates to a controller or service class.