Performance problem even for small query on big schema.

[l-you]

I widely use GraphQLite for admin console in my Symphony project. I really enjoy it!
The only reason I don't use it for public API is overhead in execution speed.

For example such simple query

query ProductFeedbackManager_feedback_count(
    $input: ProductFeedbackSearchInput!
) {
    productFeedbacksCount(input: $input)
}

Such simple query have overhead of ~100-140ms comparing to simple RESTful endpoint with the same logic.

Here is some screenshots of XDebug profiler output

I would like to discuss about ideas how codebase could be improved in direction of execution speed.

For example, if we look deeper into AggregateControllerQueryProvider->getQueries() we would see such picture.

Method mapReturnType takes 9% of the execution time for the entire script.
Inside mapReturnType we have many nested toGraphQLOutputType() called by type mappers. Almost 5k following the screenshot.

As I know primary work for type mappers is converting docblocks/attibutes Type to GraphQL type.
So, is there a way we could move such logic to the compile time? Or, maybe some kind of generated code that is stored in cache like in overblog/GraphQLBundle

Im pretty sure there are many things that could be optimised. But seems it cannot be done without breaking changes.

[oojacoboo]

So, there seems to be a few ongoing discussions around performance. I'd really like to pull all of these together and come up with something actionable. See #566 & #562. @oprypkhantc you may also find interest in this discussion.

[oprypkhantc]

I'm just starting to integrate GraphQL into our projects. We have over 300 models and 1.4k endpoints, so if there's a performance degradation with bigger projects we'll see it pretty quick.

Given we use Swoole and hold the entire Schema in memory, alongside all possible types & fields, it's likely we'll not see any performance hit because it's all already resolved prior to any requests.

But I'll take a look some time this week to see if there's really a problem here.

[oojacoboo]

I think we should look into offering a schema caching option in the SchemaFactory. In #562 @oprypkhantc outlined what annotations are dynamic for schema generation: #562 (comment).

#[Logged], #[Right], #[FailWith], #[HideIfUnauthorized] are all handled by AuthorizationFieldMiddleware which is partly dynamic:

• it statically changes the type of the field to nullable
• it dynamically sets field resolver based on the authorization (which comes from the request and hides the field when not authorized

I'm not sure how many people are using these annotations. I'd argue there are probably better ways of doing all these things and that they should generally be avoided in favor of a more native PHP userland approach.

For BC reasons, we should probably keep them and can simply throw an Exception if these are used in conjunction with schema caching being enabled.

---

I also think we should implement something for stateless routes, something I mentioned here: #125 (comment)

---

I think the combination of these two would offer significant performance increases while maintaining BC and relatively trivial to implement. Would love to hear other thoughts on this. I don't currently have the time to put together a PR for these, but happy to assist where I can.

[l-you]

I've spend some time on investigation considering some ideas.
As I see something like #562 (comment) is rejected because of webonyx/graphql-php#1329 ?

It's hard currently to see the complete picture.
"runtime" and "compile-time" code is mixed in every inch of library.

But there should be some starting point, that would help to see possible solutions.
So, I am wondering about some kind of differentiation for "compile-time" and "runtime" code execution starting with not a big changes (but potentially breaking).

Let's take a look at field middlewares. We can organise logic for static and dynamic code as following.
(dynamic code = runtime, static code = compile-time = cached code)

/**
 * @template T
 */
interface FieldMiddlewareInterface
{
    /**
     * @return T serializable output after compilation that will be stored in long live cache, where key consist of class and definition name
     */
    public function processCompile(QueryFieldDescriptor $queryFieldDescriptor,):mixed;

    /**
     * @param T $compileOutput
     */
    public function process(mixed $compileOutput, FieldHandlerInterface $fieldHandler): FieldDefinition|null;
}

Current AuthorizationFieldMiddleware looks like this

graphqlite/src/Middlewares/AuthorizationFieldMiddleware.php

Lines 32 to 89 in 5a9c03b

	public function process(QueryFieldDescriptor $queryFieldDescriptor, FieldHandlerInterface $fieldHandler): FieldDefinition|null
	{
	$annotations = $queryFieldDescriptor->getMiddlewareAnnotations();
	$loggedAnnotation = $annotations->getAnnotationByType(Logged::class);
	assert($loggedAnnotation === null || $loggedAnnotation instanceof Logged);
	$rightAnnotation = $annotations->getAnnotationByType(Right::class);
	assert($rightAnnotation === null || $rightAnnotation instanceof Right);
	// Avoid wrapping resolver callback when no annotations are specified.
	if (! $loggedAnnotation && ! $rightAnnotation) {
	return $fieldHandler->handle($queryFieldDescriptor);
	}
	$failWith = $annotations->getAnnotationByType(FailWith::class);
	assert($failWith === null || $failWith instanceof FailWith);
	$hideIfUnauthorized = $annotations->getAnnotationByType(HideIfUnauthorized::class);
	assert($hideIfUnauthorized instanceof HideIfUnauthorized || $hideIfUnauthorized === null);
	if ($failWith !== null && $hideIfUnauthorized !== null) {
	throw IncompatibleAnnotationsException::cannotUseFailWithAndHide();
	}
	// If the failWith value is null and the return type is non-nullable, we must set it to nullable.
	$type = $queryFieldDescriptor->getType();
	if ($failWith !== null && $type instanceof NonNull && $failWith->getValue() === null) {
	$type = $type->getWrappedType();
	assert($type instanceof OutputType);
	$queryFieldDescriptor->setType($type);
	}
	// When using the same Schema instance for multiple subsequent requests, this middleware will only
	// get called once, meaning #[HideIfUnauthorized] only works when Schema is used for a single request
	// and then discarded. This check is to keep the latter case working.
	if ($hideIfUnauthorized !== null && ! $this->isAuthorized($loggedAnnotation, $rightAnnotation)) {
	return null;
	}
	$resolver = $queryFieldDescriptor->getResolver();
	$queryFieldDescriptor->setResolver(function (...$args) use ($rightAnnotation, $loggedAnnotation, $failWith, $resolver) {
	if ($this->isAuthorized($loggedAnnotation, $rightAnnotation)) {
	return $resolver(...$args);
	}
	if ($failWith !== null) {
	return $failWith->getValue();
	}
	if ($loggedAnnotation !== null && ! $this->authenticationService->isLogged()) {
	throw MissingAuthorizationException::unauthorized();
	}
	throw MissingAuthorizationException::forbidden();
	});
	return $fieldHandler->handle($queryFieldDescriptor);
	}

And here is a AuthorizationMiddleware following approach mentioned earlier.

/**
 * Middleware in charge of managing "Logged" and "Right" annotations.
 */
class AuthorizationFieldMiddleware implements FieldMiddlewareInterface
{
    public function __construct(
        private AuthenticationServiceInterface $authenticationService,
        private AuthorizationServiceInterface  $authorizationService,
    )
    {
    }

    public function processCompile(QueryFieldDescriptor $queryFieldDescriptor): array
    {
        $annotations = $queryFieldDescriptor->getMiddlewareAnnotations();

        $loggedAnnotation = $annotations->getAnnotationByType(Logged::class);
        assert($loggedAnnotation === null || $loggedAnnotation instanceof Logged);
        $rightAnnotation = $annotations->getAnnotationByType(Right::class);
        assert($rightAnnotation === null || $rightAnnotation instanceof Right);
        $failWith = $annotations->getAnnotationByType(FailWith::class);
        assert($failWith === null || $failWith instanceof FailWith);
        $hideIfUnauthorized = $annotations->getAnnotationByType(HideIfUnauthorized::class);
        assert($hideIfUnauthorized instanceof HideIfUnauthorized || $hideIfUnauthorized === null);

        if ($failWith !== null && $hideIfUnauthorized !== null) {
            throw IncompatibleAnnotationsException::cannotUseFailWithAndHide();
        }
        // If the failWith value is null and the return type is non-nullable, we must set it to nullable.
        $type = $queryFieldDescriptor->getType();
        return [
            'skipMiddleware' => !$loggedAnnotation && !$rightAnnotation,
            'wrapInNullable' => $failWith !== null && $type instanceof NonNull && $failWith->getValue() === null,
            'hideIfUnauthorized' => null !== $hideIfUnauthorized,
            'right' => $rightAnnotation?->getName(),
            'logged' => $loggedAnnotation !== null,
            'failWith' => $failWith === null ? null : [
                'value' => $failWith->getValue()
            ]
        ];
    }

    public function process(array $compiledOutput, QueryFieldDescriptor $queryFieldDescriptor, FieldHandlerInterface $fieldHandler): FieldDefinition|null
    {
        // Avoid wrapping resolver callback when no annotations are specified.
        if ($compiledOutput['skipMiddleware']) {
            return $fieldHandler->handle($queryFieldDescriptor);
        }
        if ($compiledOutput['wrapInNullable']) {
            $type = $queryFieldDescriptor->getType()->getWrappedType();
            assert($type instanceof OutputType);
            $queryFieldDescriptor->setType($type);
        }

        // When using the same Schema instance for multiple subsequent requests, this middleware will only
        // get called once, meaning #[HideIfUnauthorized] only works when Schema is used for a single request
        // and then discarded. This check is to keep the latter case working.
        if ($compiledOutput['hideIfUnauthorized'] && !$this->isAuthorized($compiledOutput)) {
            return null;
        }

        $resolver = $queryFieldDescriptor->getResolver();

        $queryFieldDescriptor->setResolver(function (...$args) use ($compiledOutput, $resolver) {
            if ($this->isAuthorized($compiledOutput)) {
                return $resolver(...$args);
            }

            if ($compiledOutput['failWith'] !== null) {
                return $compiledOutput['failWith'];
            }

            if ($compiledOutput['logged'] && !$this->authenticationService->isLogged()) {
                throw MissingAuthorizationException::unauthorized();
            }

            throw MissingAuthorizationException::forbidden();
        });

        return $fieldHandler->handle($queryFieldDescriptor);
    }

    /**
     * Checks the @Logged and @Right annotations.
     */
    private function isAuthorized(array $compiledOutput): bool
    {
        if ($compiledOutput['logged'] && !$this->authenticationService->isLogged()) {
            return false;
        }

        return $compiledOutput['right'] === null || $this->authorizationService->isAllowed($compiledOutput['right']);
    }
}

So, method processCompile executed only once at production and cached its output with opcache (If you use PhpFiledAdapter).
On the other hand method process is triggered on each request.
Such approach reduces reflection calls and related parser stuff, storing output in cache with following format:

[
          'skipMiddleware' => bool,
          'wrapInNullable' => bool,
          'hideIfUnauthorized' => bool,
          'right' => bool,
          'logged' => bool,
          'failWith' => null | [
              'value' => mixed
         ]
]

My examples shows only a general idea.
Potentially we can do the similar approach with type mappers, FieldDefiniton's and other stuff that performs static data on each request.
I believe even many internal classes can be refactored. For publicly available API we can mark legacy interfaces as deprecated.

With time there will be many classes adopted in such way, so we can see the complete picture which code is "compiled" and which is executed on each request.

Seeing the complete picture, we can potentially extract such pieces into separate classes and combine their output (they all are executed only once, at the "compile-time").
This will reduce the frequency of cache calls caused by mentioned approach.

As a result, fast and contributor-friendly library :)

[oprypkhantc]

@rusted-love I'm not an active maintainer so I'm not making any decisions here. But here are my two cents on this:

Yes, the approach you're proposed will certainly work. Many things in graphqlite are currently getting cached a similar way I believe.

But there are many problems with this:

• major complexity of the library in every single part of it as practically everything needs to be cached. This means that every single piece of code must think through it's own way of caching & invalidating cache, which isn't as easy as it might sound. This affects maintenance efforts and adds a lot to the difficulty of adding new features
• hard-couples it with caching, i.e. the code is built around caching, not caching is built on top of the code. Instead of having a single CachedTypeMapper, graphqlite has multiple type mapper which have a hard dependency on cache and an unpredictable set of local (in memory) caching properties, again leading to complexity of maintenance, understanding, testing etc
• most importantly, it will not give you the absolute best performance you can get; only a moderate improvement

Given all the efforts that are needed to support this (not small) project and lack of maintainers, I don't think it's a good idea.

This might sound counterintuitive, but in the long run, I believe it'd better to instead drop support for PHPFiles/opcache caching altogether. The reason I'm saying this is I believe PHP is slowly moving towards long running servers which don't need quick boot times, like the rest of the web industry. If you look at practically any other language/technology/stack, they all have one thing in common: they don't start a new process for every request.

This has become somewhat of a trend in the recent years since the release of RoadRunner, Spiral and just now - Laravel Octane, which made it easy to implement this in real world apps.

When eventually this becomes the norm, graphqlite (and not only) could ditch file-level caching altogether and rely on a pre-initialized instance with everything pre-resolved and not having to worry about compilation or caching. This is esentially the same "compilation" step, but without having to do it manually, handle any of the "compiled" configs, do any of the "php files" caching or invalidating anything.

Might be a bold statement, but it might even be easier for you to move to Swoole/RoadRunner/AMPhp/React or other libraries than to fully cover graphqlite with compile caching everywhere. Our projects (only the .php part of it) is 700k lines and we've managed to fully move to Swoole in about 3 months start-to-finish with only me working on it part-time.

As a bonus, you'll definitely see a big increase in RPS and reduction of response times. For us it decreased the average response times about 2x and increased RPS about 2.5x without really having to do any fancy caching.

[l-you]

every single piece of code must think through it's own way of caching & invalidating cache, which isn't as easy as it might sound.

Those code pieces does not care about "own way of caching & invalidating cache". The only care is "what to cache".
Everything is stored in pool provided by developer. It can be any of Psr16Cache compatible adapters. Lifetime of that cache never ends until a new deployment.

hard-couples it with caching, i.e. the code is built around caching, not caching is built on top of the code

Actually, maybe it's better instead of 'caching' name it 'compilation' for better comprehension.

Instead of having a single CachedTypeMapper, graphqlite has multiple type mapper which have a hard dependency on cache and an unpredictable set of local (in memory) caching properties, again leading to complexity of maintenance, understanding, testing etc

Yes, I completely agree that current codebase is very complex and hard to understand.
Also, I believe that proposed separation of code will help to better understand library codebase and debug process may become less complex.

most importantly, it will not give you the absolute best performance you can get; only a moderate improvement

After deeper testing with X-Debug profile I even became more confident that such approach potentially fixes most unnecessary execution overhead. Even if we take into account frequent cache pool calls for some not performant cache adapters.

When eventually this becomes the norm, graphqlite (and not only) could ditch file-level caching altogether and rely on a pre-initialized instance with everything pre-resolved and not having to worry about compilation or caching. This is esentially the same "compilation" step, but without having to do it manually, handle any of the "compiled" configs, do any of the "php files" caching or invalidating anything.

"everything pre-resolved", what exactly?
It resolves php-fpm architecture problem, removes class initialisation overhead, maybe even class reflections performance (don't know exactly).
But how it affects performance of type resolvers similar stuff if its resolved during executeQuery?

As I see it, in combination with Swoole proposed idea of logic separation gives double profit.

P.S I suspect, maybe I didn't explain clearly enough the proposal.

[l-you]

@oprypkhantc
You mentioned somewhere that your company is migrating 1.4k endpoints to graphql.
Would you share some performance insights of your graphql after that migration? I suppose you have some high-load endpoints.
I'm interested in how Swoole + graphqlite with that amount of controllers would behave in some high load situation.

[oprypkhantc]

Lifetime of that cache never ends until a new deployment.

It's not that simple, unless you want to kill local development experience.

Yes, I completely agree that current codebase is very complex and hard to understand.
Also, I believe that proposed separation of code will help to better understand library codebase and debug process may become less complex.

I don't think so. The thing with compilation (if you wish to call it that) is you still have to take care of it manually, so the whole codebase would be bloated with it. When doing the same sort of caching in memory only (i.e. as long running servers allow you to), you only need build the correct architecture to reuse as many object instances as possible. That's easier to achieve and certainly is much easier to understand.

"everything pre-resolved", what exactly?

Well, quite literally everything. Vendor auto-loaded, caches warmed up, some services pre-resolved, all the configuration applied. On the GraphQL side, the whole schema AST generated & sitting in memory, controllers found and resolved through DI with dependent services, types also found and fields resolved (with parsed annotations, attributes, docblocks, types), type mapper resolved every single type found in properties & parameters & return types, all field & parameter middleware called.

It resolves php-fpm architecture problem, removes class initialisation overhead, maybe even class reflections performance (don't know exactly).
But how it affects performance of type resolvers similar stuff if its resolved during executeQuery?

That's the point - it is not resolved during executeQuery :)

Basically everything that can be taken care of ahead-of-time - already is in graphqlite if you simply share the same Schema instance across requests. With all of that resolved, webonyx/graphql-php can go through schema AST and validate the payload (not having to resolve AST for every request), then resolve fields (again, not having to parse anything or go through middlewares) and just call the resolver - i.e. literally just call the controller method (once again, not having to parse docblocks or return type or handle attributes on parameters).

As I see it, in combination with Swoole proposed idea of logic separation gives double profit.

No, it actually doesn't bring any benefits at all aside from majorly complicating things. It might even make it slower if Swoole isn't taken into account.

---

Would you share some performance insights of your graphql after that migration? I suppose you have some high-load endpoints.
I'm interested in how Swoole + graphqlite with that amount of controllers would behave in some high load situation.

We just now started integrating GraphQL and only have migrated 10 so far. The rest will take years.

I haven't actually tested it, but the amount of controllers/types/fields shouldn't matter. As long as you "warm" your Swoole worker's Schema instance by resolving all types & fields ahead of time, actually getting & calling an already resolved controller should take the same amount of time regardless of their amount. I suspect you can warm the whole Schema easily by running an introspection (not real code):

// done before any requests
$schema = new Schema();
$schema->runIntrospection(); // resolves all types & fields

// request comes in
$schema->resolveType(AController::class) // instantly returns the resolved type
    ->getField('someField') // again instantly returns the field
    ->resolve($payload); // does validation, then deserializes $payload into a DTO and call `someField`

// another request comes in, same schema instance, same type instance, same fields instances
$schema->resolveType(AController::class)
    ->getField('someField')
    ->resolve($payload); // again instantly

[oojacoboo]

@oprypkhantc you make some good points and I'm certainly not in disagreement that, from a performance perspective, async servers are going to offer the best performance. I don't think this is really up for debate. And, I think with some of the PRs you've submitted, and have been merged, the lib is well on it's way to accomplishing those goals. Let's keep them coming!

Also, as an aside, if you'd do us a solid in writing a doc section for using an async server with GraphQLite, that'd be awesome! I'm sure others would find this very helpful going forward.

That said, I don't think it's practical to expect everyone to migrate their entire stack, or even just their GraphQL portion of their stack, to an async server right away. There are many reasons why this might not be possible, and it's still not a norm in PHP land. Therefore, I think trying to cache what we can, now, especially from a schema compilation standpoint, is a worthwhile endeavor.

The performance hits this might have from cache hits, can be minimized and should be a consideration and objective with any improvements to caching.

@rusted-love as opposed to trying to preserve the runtime field resolving made available by only a few annotations, why don't we consider throwing exceptions within those annotations if schema level caching is enabled - maybe even look at deprecation of these annotations in favor of separate schemas. See #562 for more discussion on this topic.

I think we can achieve both objectives here.

However, I do agree with @oprypkhantc that, within a dev environment, making changes to the schema and having to clear cache within workflows is certainly not desirable. But, even with an async server, you're still going to have to recompile the schema after any changes. So, while you may not have to explicitly clear the cache, you still have longer compilation times during development efforts and have to "reboot" the server or explicitly "recompile" the schemas.

IMHO, having to clear the cache/recompile schemas during dev efforts isn't that big of a deal. We already have to clear-cache for a number of different portions of our stack during development. That would just be a caveat you'd have to deal with for the added performance benefits - again totally optional.

[oojacoboo]

As a quick test I tried to throw the schema into a PSR16 cache, but of course that's not possible with closures. I did find this library to support closure serialization though: https://github.com/opis/closure. However, I'm guessing these would have to be wrapped in webonyx, in addition to graphqlite.

Created an issue regarding recursively wrapping closures within an object: opis/closure#131

[l-you]

As a quick test I tried to throw the schema into a PSR16 cache, but of course that's not possible with closures. I did find this library to support closure serialization though: https://github.com/opis/closure. However, I'm guessing these would have to be wrapped in webonyx, in addition to graphqlite.

@oojacoboo
I also tried to make some quick test, but after many failed tries I decided to consider another approach.

The issue with serialization is that closures rely on local variables that often are objects with same type of closures or have circular dependencies.
So I decided maybe some kind of such logic separation mentioned in #569 (comment) would help extract static things as a starting point. Those static things later would be combined and passed to methods that resolve stuff similar to QueryFieldResolver.

That way closures can become a static methods
(kind of [SomeResplver::class, 'someClosure'], and no need for https://github.com/opis/closure) .
Data that is currently accessed through use (...) will be serializable and stored in QueryFieldResolver if we are taking this as an example.

As a side note, I have tried for a 2 days to make deep serializations of QueryFieldResolver with https://github.com/opis/closure , deeper and deeper refactored a codebase for this to make some prototype, but I failed.

Maybe, we need to replace QueryFieldResolver with some serializable alternative that will be just a factory for QueryFieldResolver.
Those alternatives contain only a static function reference and static data.
I believe any occurrence of anonymous closures can be removed from graphqlite.
There can be workaround in case resolver rely on some non cacheable thing. For example there is $context in webonyx/graphql that is passed to each resolver. The only purpose of $context is to have static closures but do not lose access to such things as Request object, which is dynamic for each request.

@rusted-love as opposed to trying to preserve the runtime field resolving made available by only a few annotations, why don't we consider throwing exceptions within those annotations if schema level caching is enabled - maybe even look at deprecation of these annotations in favor of separate schemas. See #562 for more discussion on this topic.

Do I understand it right way? You propose to disable support for #[Right] and #[FailWith] annotation? Personally, I use them in ~ 70% of fields.

[oojacoboo]

@rusted-love good to know that you've already gone down this path. I guess we were thinking along the same lines - hoping for an easier solution.

Do I understand it right way? You propose to disable support for #[Right] and #[FailWith] annotation? Personally, I use them in ~ 70% of fields.

Based on our discussions in #562 and my understanding of these annotations (we don't currently use them):

• [FailWith] would only require that the return type doesn't need to be modified. So, it cannot make the field nullable dynamically. It can only fail with whatever return types are typed.
• [Right] would be problematic since it causes fields to be hidden from the schema.

The argument was made by @Lappihuan, which I agree with; that changing the actual schema dynamically, is really the wrong approach and in most cases. You're better off with an authorized and unauthorized schema, or multiple schemas per role type. This is something that we could add some support for as well - making it easier for multiple schemas to be compiled based on a specific "role" value. You can then deliver the appropriate schema based on your Authorization headers, and/or by url.

Any annotation that makes modifications to an otherwise static schema, is problematic. I believe that's

• [Right]: maybe resolved in this PR Fix authorization middleware on long running servers #571 (@oprypkhantc confirm)
• [HideIfUnauthorized]
• [Logged]: maybe resolved in this PR Fix authorization middleware on long running servers #571 (@oprypkhantc confirm)

I'm suggesting that these annotations throw an Exception if schema caching is enabled, so as to avoid accidentally exposing fields to unauthorized API consumers.

@oprypkhantc also mentioned that SourceField and MagicField could be problematic, but had some ideas to resolve these. See that discussion here: #562 (comment). It'd be great to get a PR on this @oprypkhantc.

Again, I think this is all doable but multiple schemas is the most logical and fool proof design IMO.

[oojacoboo]

For supporting multiple schemas, I was thinking we could add an additional argument, schema, to the following annotations:

• [Query]
• [Mutation]
• [Type]
• [Input]
• [Field]
• [SourceField]
• [MagicField]

Then, when compiling the schema, we'd simply check this schema value and only compile the appropriate types and fields.

[l-you]

@oojacoboo
Personally, I don't use [HideIfUnauthorized]. Introspection is only exposed to front-end through token.

Going back to serialization problem.
I have made some confusion mixing up contextValue and rootValue meanings in last reply.
I am convinced we should widely rely on $contextValue provided by webonyx/graphql. This is a possible solution to the serialization problem.
I want to provide a small example.

Take a look at this class.

graphqlite/src/Types/UnionType.php

Line 18 in 51a3011

class UnionType extends \GraphQL\Type\Definition\UnionType

Its initialised here

graphqlite/src/Mappers/Root/CompoundTypeMapper.php

Lines 151 to 155 in 51a3011

	}
	$graphQlType = new UnionType($nonNullableUnionTypes, $this->recursiveTypeMapper, $this->namingStrategy);
	$graphQlType = $this->typeRegistry->getOrRegisterType($graphQlType);
	assert($graphQlType instanceof UnionType);

Type resolver function relies on RecursiveTypeMapperInterface that is initialised in SchemaFactory.

graphqlite/src/Types/UnionType.php

Lines 39 to 51 in 51a3011

	'types' => $types,
	'resolveType' =>
	static function (mixed $value) use ($typeMapper): ObjectType {
	if (! is_object($value)) {
	throw new InvalidArgumentException('Expected object for resolveType. Got: "' . gettype($value) . '"');
	}
	$className = $value::class;
	$result = $typeMapper->mapClassToInterfaceOrType($className, null);
	assert($result instanceof ObjectType);
	return $result;
	},

As specified in documentation we can access context in resolveType .
So, if we will use power of $context argument this will look like this. Graphql type with completely static and serializable data.

<?php

declare(strict_types=1);

namespace TheCodingMachine\GraphQLite\Types;

use GraphQL\Type\Definition\NamedType;
use GraphQL\Type\Definition\ObjectType;
use InvalidArgumentException;
use TheCodingMachine\GraphQLite\Mappers\RecursiveTypeMapperInterface;
use TheCodingMachine\GraphQLite\NamingStrategyInterface;
use function array_map;
use function assert;
use function gettype;
use function is_object;

class UnionType extends \GraphQL\Type\Definition\UnionType
{
    /** @param array<int,ObjectType&NamedType> $types */
    public function __construct(
        array                        $types,
        RecursiveTypeMapperInterface $typeMapper,
        NamingStrategyInterface      $namingStrategy,
    )
    {
        // Make sure all types are object types
        foreach ($types as $type) {
            if (!$type instanceof ObjectType) {
                throw InvalidTypesInUnionException::notObjectType();
            }
        }

        $typeNames = array_map(static fn(ObjectType $type) => $type->name(), $types);
        $name = $namingStrategy->getUnionTypeName($typeNames);

        parent::__construct([
            'name' => $name,
            'types' => $types,
            'resolveType' => [self::class, 'resolveTypeNonClosure']

        ]);
    }
    public static function resolveTypeNonClosure(mixed $value,mixed $context): ObjectType
    {
        if (!is_object($value)) {
            throw new InvalidArgumentException('Expected object for resolveType. Got: "' . gettype($value) . '"');
        }

        $className = $value::class;
        
        //Somewhere in root we set our context with any desired format
        //yes, currently there is no public getRecursiveTypeMapper, but we can add it
        $typeMapper = $context['schemaFactory']->getRecursiveTypeMapper();
        
        $result = $typeMapper->mapClassToInterfaceOrType($className, null);
        assert($result instanceof ObjectType);
        return $result;
    }
}

Yes, maybe somewhere in middleware or other place resolver is modified, but I believe it has a solution too.