[GraphQL] kernel.view event never fired

[jamesisaac]

The API Platform Event System Documentation lists many places in the request/response cycle you may want to attach your own listeners, the majority of them on kernel.view. This uses GetResponseForControllerResultEvent which is a helpful event, as you can do some useful things with the controller result. I've had good results adding some business logic to my API here (e.g. advanced authorization, sending out automated emails).

However in my experiments with using GraphQL, the kernel.view event doesn't seem to be getting fired for either queries or mutations?

Is this intentional? This makes it hard to offer a dual REST/GraphQL API that offers the same behaviour when similar actions are performed...?

Symfony: 4.0
API Platform: 2.2.8

[dunglas]

It's unfortunately a known issue. There is currently no event system for GraphQL.
We have a plan to fix this:

1. create new "domain" events like "serialize", "persist", "validate"
2. throw these new events from actual REST listeners and from GraphQL

I'll work on this ASAP, but any help is welcome if someone want to handle this before I do it :)

[jamesisaac]

Hmm I see, thanks for the quick response. Some thought on this:

1. Might be worth having a note in the docs about this in the mean time (and if there are any other major features missing), as I presumed the state of GraphQL support was: ready to use, but a bit less that's done for you out of the box. But having no events to hook into adds a lot of limits to what's actually possible without modifying this library itself.
2. More events will be needed the way you describe: will need "pre_*" and "post_*" events for everything you listed, as API platform isn't performing its logic in response to those events any more, so you can't use priorities to control whether the user's listener comes before/after.
3. Looking at how the GraphQL integration works, might it be a bit tricky mapping it to the same linear flow of events? I'm not that familiar with it, but it seems to be more along the lines of "resolving" (carrying out most of the lifecycle) on one entity at a time. I guess while mutations are limited to a single entity that might not matter though.

I've made a very simple implementation here: master...jamesisaac:graphql-events which I think is enough to get what I need in my project (still listening to the old style REST events, as well as GraphQL dispatching a new event that shares a similiar interface).

But I don't think I'm familiar enough with API Platform's codebase to know how you'd really want those events designed / where exactly they should be dispatched from, sadly.

[antonioperic]

@dunglas do you have any update on this maybe?

[lukasluecke]

@dunglas Do you think this is solved now with the GraphQL Stages (and we could close this issue)?

[dunglas]

Yes you're right! Solved by https://api-platform.com/docs/core/extending/ too.