Custom Fields on Input Types

[datasage]

I am working on implementing this as a proof of concept in the platform I am working on. I am running into an issue and looking for some pointers on the best way to solve it.

The platform is multi-tenant and supports custom fields on certain entities. Using source fields, i've gotten this to work with output types.

I am looking for a way to get this to work with a dynamic filter class. In general, there will be a base set of fields that are represented in code. As far as I can tell, the source fields system that worked for output types is not set up for input types.

Is there a preferred way to work around this? Or is this something that would need to be added?

[oojacoboo]

Firstly, for multi-tenancy, you might find this extension I authored for Doctrine helpful (sounds like you're using Doctrine).

https://github.com/rentpost/doctrine-multi-tenancy

As for how fields are represented, I'm not entirely sure I'm understanding the question or issue. Can you describe a bit more in detail what it is you're hoping to accomplish?

[datasage]

I am using doctrine and we use multi tenancy with unique schemas for users. This allows us to create custom fields for the tenant and index any that will be used as filters.

That brings me to graphQL and typing. See this example:

{
    units (filter: {name: {in: "The"}, custom_field_1: {in: "1"}}, sort: {name: DESC}) {
        count,
        items (offset: 0, limit: 20) {
            id, 
            name,
            custom_field_1
        }
    }
}

Due to the nature of this entity, there is a need to support a lot of filter combinations (which will get converted to querybuilder). My idea is to build a special filter object to handle this. Sort of modeled after the dgraph search schema.

Using SourceFields, i am able to get the output type to work with this. So far I have not found a solution to extend the input type to allow for custom properties.

[oojacoboo]

GraphQL is a strictly typed pre-defined schema. It really defeats the purpose to have a dynamic set of fields on a type, especially an input type. Instead, I would create an input type per tenant. Maybe you could maintain a custom map and generator for these input types. You can get a pretty clean DTO style input type with the #[Input] attribute.

If you want to pass in some random set of data, you'll have to create generic types with array inputs and maintain your own type validation - you'll lose all the benefits of introspection on the client-side.

[datasage]

Even though the application is shared, the endpoint does have a unique url per tenant via subdomain mapping. It would work to return unique type mapping per tenant.

[oojacoboo]

In this case you'd be returning a separate schema, or effectively running multiple GraphQL implementations on the same server. That's fine. It sounds like you're going to need to build a map/generator and let it generate all your input types organized by tenant. This is, obviously, pretty messy. But, this is what happens when you decide to go down the custom fields path per client. GraphQL really isn't built for this.

That all said, we do maintain a few entities/types that have custom fields, configurable by settings. This is somewhat similar to your case. We have an input type where all fields are listed and not required, then we have a validator that checks required fields and an updater that takes the input data and updates the necessary fields. I'd never want an entire schema designed like this though.