Laravel Responder puts Fractal behind a responder() call

The problem: returning a model hands over your database columns

Laravel lets you return models directly from a controller method to convert them to JSON. The README calls this a quick way to build APIs, and identifies the problem in one sentence: it leaves your database columns exposed.

That exposure is a real design problem rather than a style complaint. A model carries whatever columns the table has, including the ones that exist for the application's own convenience, and a column that leaks into an API response today is a contract you cannot take back without breaking clients.

Fractal, a popular PHP package from The PHP League, solves this by introducing transformers, which describe what a given resource looks like on the way out. The catch the README points at is integration friction, and it shows the raw usage:

 public function index()
 {
    $resource = new Collection(User::all(), new UserTransformer());

    return response()->json((new Manager)->createData($resource)->toArray());
 }

A Collection, a transformer, a Manager, a createData call and a toArray call, for every controller method that returns a collection of resources. The README's judgement is that this is not that bad, but that everyone gets a little spoiled by Laravel's magic, and then it asks whether the same thing could be written as:

public function index()
{
    return responder()->success(User::all())->respond();
}

The package exists to make that second version possible. The stated goal is to create a high-quality package that feels like native Laravel, one that lets you embrace the power of Fractal while hiding it behind what the README calls beautiful abstractions, with a lot of focus and thought on the documentation.

The audience is therefore a Laravel developer whose API has outgrown returning models, and who does not want every controller to know what a Fractal Manager is.

Four ways to reach the same responder

The package gives you four access styles for the responder, and the README presents them as equally valid options.

The first is to inject the Responder service class into the controller method:

public function index(Responder $responder)
{
    return $responder->success();
}

The second is the responder helper function, for people who like Laravel's response helper, and the README notes that if you are a fan of that helper function you may like this one:

return responder()->success();

The third is the Responder facade, which is listed as optional:

return Responder::success();

The fourth is the MakesResponses trait, Flugg\Responder\Http\MakesResponses, which you add to your controllers so the calls become methods on the controller itself:

return $this->success();

The service class has a success method and an error method, and the same pair exists on each of the four access styles, so the choice of how you reach it does not change what you can build.

That is a generous amount of API surface for what is conceptually one object, and it is worth picking one style and sticking to it in a codebase, because a project that mixes the trait and the facade will have controllers that look like they were written by different people. The README itself says which option you pick is up to you, they are all presented as equivalent.

Installation is a Composer require and a provider registration

Installing the package through Composer is one command:

composer require flugger/laravel-responder

For Laravel, the service provider is registered by appending one line to the providers key in config/app.php:

Flugg\Responder\ResponderServiceProvider::class,

The README then notes that the package supports auto-discovery, so on Laravel 5.5 or later you can skip registering the service provider and facades because they are registered automatically. That matters for a modern application, where the manual step would otherwise be a line of legacy configuration.

The facades are optional in their own right, and if you like them you may add the Responder and Transformation facades to the aliases key:

'Responder' => Flugg\Responder\Facades\Responder::class,
'Transformation' => Flugg\Responder\Facades\Transformation::class,

The Transformation facade is worth a note. It is the entry point to the transformation side of the package, the Fractal layer itself, and it is the one you would reach for when you need a transformer for a single resource rather than a response for a collection.

The requirements section is brief and dated in a way that tells you what the package supports. It requires PHP 7.0 or newer and Laravel 5.1 or newer, or Lumen 5.1 or newer.

Publishing the config, and the Lumen caveat

The package configuration and the language file are published with the vendor:publish Artisan command:

php artisan vendor:publish --provider="Flugg\Responder\ResponderServiceProvider"

That produces two files. The first is a responder.php configuration file in your config folder, and the second is an errors.php file inside your lang/en folder which can be used for storing error messages.

The separation of the two is the interesting part. The config file holds the package settings, and the error messages live in the application's language directory rather than inside the package, which means the text of an error response is translatable in the same way as any other string in a Laravel application rather than being fixed at build time.

Lumen is handled differently at every step, and the README is explicit about it. The service provider is registered in app/bootstrap.php rather than in a config file:

$app->register(Flugg\Responder\ResponderServiceProvider::class);

and the facades are added with class_alias calls in the same file:

class_alias(Flugg\Responder\Facades\Responder::class, 'Responder');
class_alias(Flugg\Responder\Facades\Transformation::class, 'Transformation');

The asset publishing caveat is the one to remember. The README says that since there is no vendor:publish command in Lumen, you will have to create your own config/responder.php file if you want to configure the package. So the package works on Lumen, but the ergonomics of setting it up are worse, and a project on Lumen should plan to write that file and keep it in version control, because it is now part of the application rather than something the package can regenerate.

That difference is the practical argument for Laravel over Lumen if you adopt this package, since the auto-discovery and the publish command do the registration work for you.

What the repository says about its own health

The file listing is the usual Laravel package shape: src/ for the code, config/ for the configuration file that gets published, resources/ for the language files, tests/ with a phpunit.xml, and a composer.json, a CHANGELOG.md and the LICENSE.md at the root.

The badges in the README tell you about the tooling rather than about the features. There is a Packagist badge for the latest stable version and one for the download count, an MIT licence badge, and then three CI badges: a Travis CI build status for the master branch, a Scrutinizer code quality badge and a Scrutinizer test coverage badge for the code structure.

That combination is dated and it is informative. Travis CI is no longer where new projects put their continuous integration, and Scrutinizer is not a service most teams are using now, so this repository was last set up with a toolchain from a few years ago. The project has kept going, with the last push on 2026-09-22, and the licence is MIT.

The repository publishes no GitHub releases, so the version history is in the CHANGELOG.md and in the Packagist version. For a package like this, the changelog is the file to read before a bump, because the important question when upgrading is whether the response format changed, and a change in the shape of an API response is a breaking change for your clients even when the package version says minor.

There is also a donation link in the badges, which is a reminder of the maintenance model here. This is a package maintained alongside a body of other work by one author, with a PayPal link at the top of the README. The code is MIT and permissively licensed, so forking it is straightforward if the project ever slows down.

Editorial conclusion

Adopt Laravel Responder if you are building a JSON API in Laravel or Lumen, you already use Fractal or want to stop returning database models straight to the client, and you want one place that builds success and error payloads. Do not adopt it if your API is trivial, since the overhead of a transformer layer for a handful of fields is not worth a dependency, and note the Lumen caveat, where there is no vendor:publish command and you have to create the configuration file yourself. Before you upgrade it, read the CHANGELOG.md in the repository, check that the version you take supports your PHP and Laravel versions, the README asking for PHP 7.0 and Laravel 5.1 or newer, and decide which of the four access styles you want, since the package offers all of them and picking one keeps the codebase consistent.

Frequently asked questions

Official sources

1. flugg/laravel-responder on GitHub
2. Issues
3. License: MIT
4. README