Api Platform Profiler Bundle Laravel Package

Getting Started

First, the reality check: this is a Symfony bundle (mapado/api-platform-profiler-bundle), not a Laravel package. It extends the Symfony Web Profiler with a panel for API Platform, so "day-to-day" use only applies if you're running API Platform on Symfony. If you're in a Laravel codebase, the closest analogues are barryvdh/laravel-debugbar (request/query panel) and laravel/telescope (request watchers, gates, jobs) — neither shows API Platform metadata because Laravel has no equivalent resource/operation layer. Treat this bundle as reference reading unless you actually have a Symfony/API Platform service.

The repo is archived with no stars and no dependents, so install defensively: pin a version, vendor the fork if needed, and never plan on upstream fixes.

Minimal steps (Symfony, dev only):

composer require --dev mapado/api-platform-profiler-bundle

Register it in config/bundles.php (or app/AppKernel.php on older Symfony), confirm symfony/web-profiler-bundle is enabled for dev/test, then clear the cache and hit any API Platform endpoint with the toolbar enabled.

Where to look first:

• src/DataCollector/ — the collector class that gathers the data shown in the panel.
• src/Resources/views/ — the Twig template that renders the panel; this is your override point for extra fields.
• src/DependencyInjection/ — the extension/config tree, to see what's toggleable.
• composer.json — the API Platform / Symfony version constraints, which tell you immediately whether it will even boot on your stack.

First use case: open a resource endpoint (GET /api/books/{id}) in dev and check the panel to confirm which resource class and operation API Platform actually resolved, and which normalization context/groups were applied. Most API Platform debugging starts with "why is this field missing from the response" or "why did it hit the collection operation instead of the item one" — both are answered by looking at what the operation resolver chose before serialization ran.

Implementation Patterns

Operation resolution checks. Before you dig into serializers, confirm the panel shows the resource and operation you expect. A route matching the wrong operation (item_get vs a custom publish operation) explains a surprising number of "the wrong groups are applied" bugs.

Serialization group diffing. The useful workflow is: look at the resolved normalization context in the panel, compare it against the #[Groups]/@Groups on the entity and its relations, then look at the actual JSON. When the panel and the response disagree, you have a custom normalizer or a parent-class group you forgot about.

Correlating with the Doctrine panel. API Platform + serializer is an N+1 factory. Use this panel to confirm the operation, then switch to the Doctrine panel for the same request to count queries. If a collection endpoint issues one query per item, the fix is max_depth / #[MaxDepth], JoinFetch in the collection extension, or an explicit DTO — not a serializer tweak.

Test-env assertions. Enable the profiler in test and drive endpoints via KernelBrowser, then pull the profile ($client->getProfile() / $client->enableProfiler()) and assert on the collected data. This turns "the groups are right" into a regression test that fails when someone edits an entity annotation.

Extending the collector. If you need custom metadata (e.g., your own operation attribute or a feature-flag decision), decorate the collector service or add a small event subscriber that pushes data into it, plus a Twig template override for the panel. Look at how the collector is wired in services.xml first — the service id and whether it's public matter for decoration.

Laravel-side equivalent pattern. If you're porting the idea rather than the package: a Terminate middleware that logs route → controller → resolved resource class → JsonResource/transformer used, plus the debugbar query timeline, gets you 80% of the diagnostic value. Add the serialization "context" (which $hidden/$visible/$with applied) to that log line and you've reproduced the panel's core utility.

Gotchas and Tips

• Archived means frozen constraints. It almost certainly predates API Platform 3 and Symfony 6/7. Check composer.json before installing; if the constraint blocks you, fork and bump, or don't bother — the diagnostic value rarely justifies maintaining a fork.
• Dev-only, strictly. The Web Profiler stores request data (headers, payloads, SQL) on disk. Never enable it in production, and make sure web_profiler config isn't leaking into prod via a shared config file.
• Empty panel = no operation matched. 404s, non-API routes, and requests rejected by a security listener before API Platform runs will produce nothing. Verify with bin/console debug:router and bin/console debug:event-dispatcher that the request reaches the API Platform listener.
• collect: false hides it silently. Some setups disable collection for specific paths (health checks, webhooks). If the panel works on /api/books but not /api/health, that's config, not a bug.
• The panel shows the resolved context, not the effective one. Custom normalizers, #[Ignore], circular-reference handlers, and AbstractNormalizer callbacks can still change the output afterward. Always diff against the real response body.
• Message-driven writes never appear. Operations dispatched through Symfony Messenger or run from a console command have no HTTP profile. Debug those with -vvv and a Stopwatch around the handler instead.
• Clear the cache after config changes. Profiler panel templates and collectors are compiled; a stale cache is the usual cause of "the bundle isn't showing up."
• Prefer the first-party tools where they overlap. debug:router, api:json-schema (or debug:api), symfony/stopwatch around the serializer, and the Doctrine panel cover most of what this bundle adds, without the abandoned-dependency risk. Adopt this package only if the operation/context panel is genuinely saving you time on a legacy Symfony app you can't upgrade.