Require functionality better than @GraphQLIgnore

[babyfish-ct]

This is a case that shows why "@GraphQLIgnore" is not enough

Postgres supports JSONB, like this

create table entity_a (
    id uuid not null primary key
    name text not null,
    content JSONB not null
);
create table entity_b (
    ....
);

The table entity_a has a column whose type is JSONB, many SQL frameworks(such as JOOQ) can map it to a java/kotlin type easily, That JSONB type is mapped to this type

data class EntityAContent(
    
    // Implicit foreign key references "entity_b" embedded in JSONB, not explicit foreign key constraint
    val primaryEntityBId: UUID, 
    
    // Implicit foreign keys reference "entity_b" embedded in JSONB, not explicit foreign key constraint
    val secondaryEntityBIds: Array<UUID>,
)

Then declare the Graph object type for "entity_a", it is used as the return type of query methods

data class EntityA(
    val id: UUID,
    val name: String,
    val content: EntityAContent
);
class EntityAQueryService : Query {
    suspend fun findEntityA(): List<EntityA> = ...
}

Then declare the graphql input type for "entity_a", it will be used as the parameter type of mutation methods.

data class EntityAInput(
    val id: UUID,
    val name: String,
    val content: EntityAContent
);
class EntityAMutationService : Mutation {
    suspend fun saveEntityA(input: EntityAInput): Boolean = ...
}

"EntityAContent" is shared by both query and mutations, graphql-kotlin uses it to generate schema twice, both object type and input type will be generated with similar code

Ok, let's improve EntityAContent

data class EntityAContent(
    
    @GraphQLIgnore(IngoreMode.ONLY_FOR_QUERY)
    val primaryEntityBId: UUID, 
    
    @GraphQLIgnore(IngoreMode.ONLY_FOR_QUERY)
    val secondaryEntityBIds: Array<UUID>,
    
    // Automatically ignored by grpahql-kotlin during input-type generation
    fun primaryEntitiyB(
        env: DataFetchingEnvironment
    ): CompletableFuture<EntityB> = env.getDataLoader()......
    
    // Automatically ignored by graphql-kotlin during input-type generation
    fun seondaryEntitiyBs(
        env: DataFetchingEnvironment
    ): CompletableFuture<List<EntityB>> = env.getDataLoader()......
)

Finally, for the common type shared by both query and mutation.

1. "primaryEntityBId" and "secondaryEntityBIds" are used to generate input type for mutation, the other two functions are ignored implicitly
2. "primaryEntitiyB" and "seondaryEntitiyBs" are used to generate object type for query, the other two fields are ingored by @GraphQLIngore(IgnoreMode.ONLY_FOR_QUERY)

Is it possible to support "@GraphQLIngore(IngoreMode.ONLY_FOR_QUERY)"?

[smyrick]

Is it possible to support "@GraphQLIngore(IngoreMode.ONLY_FOR_QUERY)"?

In theory, yes it would be possible with our schema generator to have this behaviour but that goes against the GraphQL spec. For comparison can you do this exercise for me: How would you represent your desired schema in SDL?

type Query {
  findEntityA: [EntityA]
}

type Mutation {
  saveEntityA(input: EntityAInput): Boolean
}

input EntityAInput {
  id: UUID
  name: String
  content: EntityAContentInput
}

# How do we have two types called "EntityAContentInput" that have different fields?
input EntityAContentInput {
  primaryEntityBId: UUID
  secondaryEntityBIds: [UUID]
}

# How do we have two types called "EntityAContent" that have different fields?
type EntityAContent {
  primaryEntityBId: UUID
  secondaryEntityBIds: [UUID]
  primaryEntitiyB: EntityB
  seondaryEntitiyBs: [EntityB]
}

[babyfish-ct]

No

# How do we have two types called "EntityAContentInput" that have different fields?
input EntityAContentInput {
  primaryEntityBId: UUID
  secondaryEntityBIds: [UUID]
}

# How do we have two types called "EntityAContent" that have different fields?
type EntityAContent {
  primaryEntitiyB: EntityB
  seondaryEntitiyBs: [EntityB]
}

[dariuszkuc]

Hello 👋
It is possible to do this in Java as it is not null-aware so everything is nullable and every object has a default null value. By default (without additional annotations that give hints to compiler), since all your fields in POJOs are nullable it is also possible to selectively populate only fieldA (in your example primaryEntityBId) or fieldB (secondaryEntityBIds) or nothing at all.

Kotlin enforces null safety at compile time so when you initialize your properties you have to explicitly provide values (unless using lateinit var or there is already a default value). Given (simplified your example)

data class Foo(
    val a: String, 
    val b: List<String>
) {
    fun c(): String = { ... }
    fun d(): List<String = { ... } 
)

It is not possible to initialize Foo without providing values for both a and b. You could make them nullable and provide default null value - this would allow you to mimic Java behavior but that would also change your contract on nullability of those fields.

If you have different requirements for your queries and mutations (or in your case it sounds like it is a difference between input and ouput types) -> just create separate types instead.

[dariuszkuc]

Your use case is very specific to your application logic and this cannot be enforced generically in the library - your logic implies that departmentId will be internally populated by the resolver logic (or if you don't have it set it to some dummy value to fulfill the non-null contract?).

[babyfish-ct]

OK, I change "departmentId/department" to be nullable

/*
 * "@SchemaShare" is important, 
 * it means this class is allowed to be used as both return type of queries and parameter types of mutations,
 * and it can be used to generate BOTH object type and input type.
 */
@SchemaShare 
data class Employee(
    val id: UUID,
    val name: String,
    
    /* 
     * 1. Ignore it when the class is used to generate ObjectType for queries, 
     * 2. Don't ignore it when the class is used to generate InputType for mutations.
     */
    @GraphQLIgnore(IgnoreMode.QUERY) 
    val departmentId: UUID?
    
) {

   // Functions are always be ignored when this type used to generate input object
   fun department(
       env: DataFetchingEnvironment
   ): CompletableFuture<Department?> =
       departmentId
           ?.let {
               env
               .getDataLoader("departmentLoader")
               .load(it)
           } 
           ?: CompletableFuture.supplyAsync { null }
}

The key point is the "@SchemaShare". Sorry, In previous discussion, I treated it as implicit so I didn’t mention it.

For example, If user want to create an complex tree data service, like XML DOM

data class Node(...) {}
data class Element(val childNodes: List<Node>, ...): Node(...)
data class Text(val value: String): Node(...)
data class Comment(....): Node
...Define 12 derived types of Node in accordance with W3C specifications...

This is an complex API design, If there is no technology for sharing object declaration and input declaration, the user need to do this repetitive work

data class NodeInput(...) {}
data class ElementInput(val childNodes: List<NodeInput>, ...): NodeInput(...)
data class TextInput(val value: String): NodeInput(...)
data class CommentInput(....): NodeInput
...Define 12 derived types of Node in accordance with W3C specifications...

This is really repetitive work, user must declare two sets of similar data structures and translate them internally.

Of course, @SchemaShare is not universal solution, because object types and input types are not always similar for any projects. Fortunately, users can choose to use it or not, if they are similar, user can choose to use @SchemaShare, not declare similar data structure twice.

[babyfish-ct]

This is actually a flaw in the GraphQL specification, but this solution can improve it by the code-first mode of graphql-kotlin

[huehnerlady]

Hi, I just found this discussion after running into a similar problem. If you want to create an item with an id, you do not want the API user to actually add an ID, you just want it to be generated once you get the data in. So in this case I would also find it quite handy if you could 'hide' the id field for eg. inputs, but keep the id visible as an output. So maybe that is something that also this specific use case can profit from? 🤔

[smyrick]

We wouldn't want to scope anything by the operation type. If we were to add any support it would be that fields can be restricted to being used only in input or output classes. We could do this with the existing @GraphQLValidLocations, but again that is making the logic more complex for use because you still have to pass in those values or have defaults for the use case when they are not being used.

The better approach from a GraphQL API perspective is to have explicit class Node {} and class NodeInput {} that have different values as that will match up to the actual schema and GraphQL spec