Dynamic, data-driven schemas and types based on route params

[ctadlock]

Our applications has user's projects in it; these projects are isolated sets of data. Each project has several tables/collections in it. Projects are created at runtime by the users. The projects start out with a base common schema and set of system fields (id, name, created_at, ..), but part of the application functionality is that users can add/modify/remove user fields as they wish. For example they might add an enum color: [red, blue, green]; that user field would only exist in that user's project. These user defined fields are stored in a table/collection "attribute" in the database for that project (name, type, required, default value...). The users can not modify the system fields.

To implement this, we are using MongoDB and a database-per-project architecture. We have a master database that maps projects to database servers and names. We want to use GraphQL and this package if possible to expose a public API to access and mutate the project data. We have almost everything figured out.. the connection to MongoDB, dynamic database connections and we have this package working great when connecting to a defined database connection (aka project).

What I would like to see is the GraphQL route exposed with a route parameter which identifies the project:
https://api.test.com/project/123/graphql
.. and then Laravel middleware that is responsible for getting the project id, validating and setting the correct database on the connection to MongoDB. All possible.

The question is how can we have dynamic GraphQL schemas and types (per project)? In this package there is a concept of multiple schemas and a default schema, but types are global; so it feels like part of this is there already. However we will have thousands of projects so thousands of schemas and types and they can change at any moment.. so defining them in the config file is out of the question. We have the underlying data to dynamically generate the schema and types from the project's attribute table. The only thing that really changes per project schemas are the type fields and query arguments. Is there a place to intercept or inject into this package when it loads the schema for the current request? These are defined by PHP types, so we would need to be able to also intercepts the call to fields() and args() so they could be modified with the per-project data. If that happens after the project identification middleware, then that would be a place to generate the schema for the current request. We would also like to get graphiql working per project.

[mfn]

In this package there is a concept of multiple schemas and a default schema, but types are global

There's a PR for this => #658
I've yet to start properly reviewing this though. Maybe you can give this a spin and see if it works for you?

---

graphql-laravel warps graphql-php and provides some bells and whistles around it (Laravel validation, SelectFields for Eloquent, etc.). You mentioned you're using MongoDB, so one major chunk is already out the window for you anyway.

The rest of your description really looks very specific to your project. How easy/complex this would be, I can't really see. It's not a requirement I ever worked with.

I wonder how much benefit you really have from using this package? Did most parts work out of the box for you? Did you override / replace much already?

I'm always open to make things more extensible / replaceable.

[ctadlock]

To anyone that comes along later...

I was able to get this working well using the underlying webonyx/graphql-php package. This graphql-laravel package doesn't have the appropriate design philosophy to make this happen. General issues:

• The types are global; not per schema
• The schema itself is static in that its driven by config
• The way types are loaded makes it hard to pass in a meta-context variable which would be used to effect the schema/types

None of this are really faults of this package; it just wasn't intended for this purpose.

[mfn]

Thank you for your feedback/summary 🙇

• The types are global; not per schema

Indeed, I hope I can move #658 forward soon

[mfn]

#667 (comment) has a great summary, I think that two of those points have been addressed recently 👍

The types are global; not per schema

#658 was finally merged and released as https://github.com/rebing/graphql-laravel/releases/tag/6.4.0

The schema itself is static in that its driven by config

Support for class based schemas have been added via #706 and released in https://github.com/rebing/graphql-laravel/releases/tag/6.3.0

The way types are loaded makes it hard to pass in a meta-context variable which would be used to effect the schema/types

TBH not sure what this really means 🤷‍♀️

[ctadlock]

Wanted to reopen this now that there are class based schema...

Is it possible for the schema defintion to be dynamic based on the HTTP request? Im not an expert in this library, but it seems like the schema are still being loaded too early in the process and dont have access to the request. Evrything would be able to be dynamic based on the request; queries, mutations, types...

I have since built my own wrapper around webonyx/graphql which does what I need, but its 95% similar to this library. Id prefer to use this library, and I think the ability to have dynamic grapghql apis would be a valuable feature to it.

@mfn

[mfn]

Good question. I personally don't use this feature so I can't give a good answer from that angle.

Just browsing the code, it seems to me that:

• the router (src/routes.php) instantiates the Schema classes
  • this is before the request hits the controller
  • but it does not actually use the "GraphQL schema", only requires the method, controller and middleware
• The resolving of the actual schema then happens in \Rebing\GraphQL\GraphQL::execute

So my impression is: it could work, but the issue I see is when serializing your Schema class via toConfig() is that you don't know if you just need the information for the router or the full schema.

So, adapting the ConfigConvertible would be necessary in some way. I would probably suggest to split but the toConfig() into two calls, one for the router related and one for the GraphQL schema or something.

WDYT? Are you up for testing out if this would work for you?