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.

[Lappihuan]

As far as I can tell, the source fields system that worked for output types is not set up for input types.

@datasage
This is the case, i have stumbled over this while working on #466 but decided to not add it in this PR since it is a whole nother parsing branch which i did not feel comfortable to dig in yet.
My understanding was that this is sort of Laravel/Eloquent style of Field definitions and since i don't know either...
I think it should be doable in day or so to get the whole SoureField MagicField functionality for InputTypes on par with OutputTypes.

I don't know what your requirements are for the Custom Fields on the Entity.
How would such an entity look with your SourceFields applied and how would the input work?

[datasage]

The object would exist in two parts. One set of base fields which will make up most of the fields. These will be defined in code and will be the same for all tenants. The second part would be a set of custom fields. These would not exist as object properties and likely handled through a magic getter/setter.

On the output side, I extended the type object with FromSourceFieldsInterface and provided the additional mappings for the custom fields with that function. These map to a magic getter.

$fields[] = new SourceField(['annotations' => [new CustomField()]], $field->reference, $field->isRequired ? '!String' : 'String', null, null, '__get');

I added the middleware to override some internal mapping. Which prefixed the field name with custom_.

Then the magic getter pulled those fields and mapped it to an internal custom field function based on the prefix being added to the name.

I have not fully tested to see how this is handled in the cache. But it looks like I have options to namespace this if needed. But It's also ok if the custom part does not cache.

Being able to replicate the same setup on the input side would work perfectly for my needs.

[Lappihuan]

I guess you are following this?
https://graphqlite.thecodingmachine.io/docs/external-type-declaration#declaring-fields-dynamically-without-annotations

[datasage]

Yes, for output types.