Multiple graphiqlite instances

[tobolleo]

Hi, I would like to continue in this discussion.
Based on that, I'm still not sure how should I achieve of two different separated instances of graphqlite. I need for them to have different security settings and non shared cache. Each with their own configuration file. You said it's possible to build two different APIs, so I assume that this is possible. Can you please provide me more detailed guide how to do this?

Thank you. @oojacoboo

[oojacoboo]

@tobolleo It's going to depend, of course. If you're expecting to put security at a lower level than your controllers, you're probably not going to have a very easy time. However, if you're okay with security (auth/authz) existing primarily at the "controller" (resolver) level, you shouldn't have too much trouble.l

I don't know what your code looks like, so you're going to have to translate what I'm saying into what makes sense for your framework.

Effectively, you're going to want to have two different front controllers. If you don't know what those are, do some research. From the front controllers, you'll just pass the request to two different request handlers (RequestHandlerInterface that will get the ServerRequestInterface and then pass the response to GraphQLite for handling.

You're basically going to split off how the requests are handled at the front controller level. Then from there you'll route each request to two different groups of controllers/resolvers.

[franzwilding]

I'm also trying to have multiple GraphQL endpoints. In our current solution we have one .graphql file for each api:
public.graphql -> /public
admin.graphql -> /admin

Since some types and operations are shared between this APIs, others are not, we can't just use different namespaces. I was thinking about something like an API annotation next to the Query / Mutation / Type / Input / Field annotations, where one could define the enabled apis for this type.

What do you think? Maybe this is possible with a custom middleware?

[oojacoboo]

What's the issue you're running into? I'm not convinced that there is a need for a new annotation to accomplish this. What's wrong with a separate front controller and controller layers? Do you need to customize your entities/models for each API?

[franzwilding]

Hey @oojacoboo, thank you for your answer!

One basic example of what I want to accomplish is this:

• admin API to CRUD "page" entities
• public API to only read "page" entities
• one shared entity for both of them

I tried this with two schemas (different controller namespaces, same entity namespace), how ever the output looks like this:

admin api: This looks good!

type Mutation {
  createPage(page: PageInput!): Page!
}

type Page {
  id: Int!
  title: String
}

input PageInput {
  title: String
}

type Query {
  findPages: [Page!]!
}

public api: the "PageInput" should not be part of the api.

type Mutation {
  """
  A placeholder query used by thecodingmachine/graphqlite when there are no declared mutations.
  """
  dummyMutation: String
}

type Page {
  id: Int!
  title: String
}

input PageInput {
  title: String
}

type Query {
  findPages: [Page!]!
}

If the schema would automatically remove all types / inputs / unions / enums that are not used anywhere in the schema, I think the approach with different controller namespaces for each api could work, but I guess this is not planed / working?

[oojacoboo]

So, GraphQLite helps you build out a schema for webonyx/graphql-php. The SchemaFactory is responsible for this. Specifically, the namespaces for your types, SchemaFactory::addTypeNamespace and SchemaFactory::addControllerNamespace.

If you have 2 separate front controllers, you now have control over how things are built up per API.

If you're putting your InputType attribute definitions on your entities/models that are shared, this is going to be an issue probably, since you won't have a way to separate them out. However, if you're defining independent InputTypes per API within a separate namespace, you should be fine. We actually include our InputTypes alongside our operation controllers. We want a strict separation between our input and output types and aren't trying to share the same class.

So, you'll point your webserver route to the frontcontroller. Define some kind of global variable or service detector that can identify which API is being used, and then in your schema config, just conditionally set your namespaces.

Now, I believe the schema and types are cached and you're going to want this. So, the cache layer will need to be "namespaced" for each API as well. Otherwise, you're just going to end up with some missing types for the API that wasn't originally cached. We're using the APCu cache adapter from Symfony (https://symfony.com/doc/current/components/cache/adapters/apcu_adapter.html). You can include a namespace argument for this PSR16 adapter.

And that should be it. I can't really think of anything else. It'll also be a positive that you have separate configurations for each API, as it'll allow you some additional control over how each one performs.

[franzwilding]

Hey oojacoboo, thank you for your answer!
Your suggestion to have complete separate namespaces is a very valid architecture, however I am looking into GraphQLite, because we have a custom similar GraphQL API solution based on webonyx/graphql-php, where we generate multiple APIs based on shared objects and I was thinking about replacing it with GraphQLite.

I already diged a little bit deeper into GraphQLite's codebase and I think one solution would be to be more flexible about the extra types that will be added to the schema:

In TheCodingMachine\GraphQLite\Schema all defined types (that cannot be detected automatically by going through the controller) are added to the schema, even if we don't need them:

$config->setTypes(static function () use ($recursiveTypeMapper) {
            return $recursiveTypeMapper->getOutputTypes();
        });

I see two possible improvements here:

1. getOutputTypes() will only return an input OR an object type, however I guess it can be nice to add the Input as well as Object attributes to one php class:

if ($this->annotationReader->getInputAnnotations($refClass)) {
   $type = $this->mapClassToInputType($supportedClass);
} else {
   $type = $this->mapClassToType($supportedClass, null);
}

2. It would be nice to have more control over this extra types, that should be added to the schema (or not)

[oojacoboo]

@franzwilding another option here:

In your SchemaFactory config, you can a custom type mapper factory - addRootTypeMapperFactory. This factory will allow you to map your types accordingly (https://graphqlite.thecodingmachine.io/docs/4.0/internals#mapping-types).

So, with this, and with the independent schema config and front-controllers, you could then assign your own custom attribute to your entities and write the type mapper to handle them accordingly.

I think this would get the job done for you, so you could share your entities/objects across both schemas.

--

Now, that all said, I'm not opposed to introducing the concept of multiple schemas or namespaced schemas in GraphQLite. I do see the benefit of this, certainly. However, should this be done within the lib, a careful approach to the design and configuration needs to be taken into account.

The Type and InputType attributes could include a schema prop. The SchemaFactory configs and type mappers will need to take into account this schema. Also, I guess the caching layer will need to be worked into the schema concerns.

In reality, the SchemaFactory would probably need to accept a way to define all of the same configurations, but within some sort of new "schema" wrapper scope (probably a new Schema object). This would allow you to define multiple schemas, but still have full control over the configuration of each. But, within a single SchemaFactory config. It would eliminate the need to build out multiple SchemaFactorys. Then, you could eliminate the need to use multiple front controllers and just rely on whatever routing you desire. Personally though, if I'm doing something like this, I'm going to want a custom front controller being hit from my webserver. But, I realize this might not always be desirable for some people and might not be something they're comfortable configuring.