Laravel Lighthouse tracing integration

[stayallive]

This PR aims to add out of the box tracing support for Laravel Lighthouse.

Sneak peek of how a batched request executing multiple GraphQL queries would look like:

/cc @spawnia

[spawnia]

I think it would be better to use only the top-level fields for naming and grouping operations. That makes it very predictable, whereas using operation names and aliases is dependent on the client and might change on a whim.

If tracing on the level of named operations is wanted, this can still happen from the client side. In integrated scenarios, the clients are most likely using Sentry too 😉

[stayallive]

Yeah, I do not agree on that. The operation name is super useful IMHO, but I also see where you are coming from and I might even consider adding a configuration option or something else so you can switch between the two without too much work on the integrator.

[spawnia]

I can see how both approaches might be desirable in different scenarios. We have multiple clients using our API, so using operation names does not work well for us. It might group operations where the fields are completely distinct but coincidentally named the same, and fail to group operations where the fields are actually the same but named differently.

[stayallive]

Yeah exactly, I think having both is the best option here because it would depend on the use cases. For us the difference between query{viewer} and query{viewer} would be desirable and could be indicated by the operation or query name because although they only query the viewer they can have a vastly different subselection of fields.

[spawnia]

I am quite excited to try this out!

[stayallive]

So what about this for changing if the integration ignores operation names?

<?php

namespace App\Providers;

use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    public function register()
    {
+       $this->app->when(
+           \Sentry\Laravel\Tracing\Integrations\LighthouseIntegration::class
+       )->needs('$ignoreOperationName')->give(true);
    }
}

This seems like a pretty cool solution to prevent needing to make life too difficult?

[spawnia]

@stayallive Woah, that usage of the Container is pretty advanced. Looks acceptable to me.

[stayallive]

I have started testing this branch on our staging environment and I'm pretty excited for this already!

You can test it by making the following change in your composer.json (and reverting that later!):

-   "sentry/sentry-laravel": "^2.5",
+   "sentry/sentry-laravel": "dev-lighthouse-integration#78f560d892aee0a92295e63af4d4fc8d7a4f3519",

No other configuration should be needed "out of the box" apart from setting up tracing in the first place.

If you want to ignore operation names passed by the client and want to group transactions on the root selection set instead you can add the following snippet to the register method of for example your AppServiceProvider:

$this->app->when(
    \Sentry\Laravel\Tracing\Integrations\LighthouseIntegration::class
)->needs('$ignoreOperationName')->give(true);

[spawnia]

Before and after in this screenshot, it is a great improvement:

[spawnia]

Eagerly awaiting the release 🚢