Batching with GraphQL

[UbiquitousBear]

I am trying to implement batching with GraphQL.

I currently have queries: allComponents, getComponent, the former returning a collection of items. Each item has a property, componentType, which is a separate entity.

How do I set up batching?

The current code I have is:

@Query
        public Uni<Component> getComponent(@Name("id") String id) {
            try {
                return componentService.getComponent(entityReferenceDecoder.getEntityReferenceFromString(id));
            } catch (RuntimeException t) {
                throw new ApiException(t.getMessage());
            }
        }

        public Uni<ComponentType> type(@Source Component component) {
            try {
                return sessionFactory.openSession().chain(() -> componentTypeService.fromEntityReference(entityReferenceDecoder.getEntityReferenceFromString(component.getType().getEntityReference())));
            } catch (RuntimeException t) {
                throw new ApiException(t.getMessage());
            }
        }

@Query("allComponents")
        public Uni<List<Component>> getAllComponents() {
            return componentService.getAllComponents();
        }

public List<List<ComponentType>> componentType(@Source List<Component> components) {
            return List.of(List.of());
        }

However, when calling the query:

query allComponents {
  allComponents {
    name, 
    type {
      name
    }
  }
}

I can't seem to get batching working, I'd expect an empty name value (given I'm using allComponents.

[quarkus-bot[bot]]

/cc @jmartisk (graphql), @phillip-kruger (graphql)

[phillip-kruger]

You can change the public Uni<ComponentType> type(@Source Component component) method to public Uni<ListComponentType>> type(@Source List<Component> component)

see https://www.youtube.com/live/PHWOzzusfrY?feature=shared&t=2752

[UbiquitousBear]

@phillip-kruger We can skip the JPAStreamer code and use Panache directly (list()): I've pushed up code the change this. A quick retest shows the same issue.

[phillip-kruger]

Ok I'll have a look again in the morning

[UbiquitousBear]

Thanks @phillip-kruger, I've made a small adjustment to the queries so we always return what has been asked for, new code has been pushed up; have a good evening!

[phillip-kruger]

OK. There is a few things going on here.

1. Lombok.

The original error you are getting is due to Lombok's equals and hashcode. I removed the @EqualsAndHashCode(callSuper = false) and @Data on both Component and ComponentType and added @Getter @Setter

2. Wrong parameter.

The parameter passes into the GraphQL @Source method needs to match the response type of the @Query. So I changed

public Uni<List<ComponentType>> batchedType(@Source List<Component> components)
to
public Uni<List<ComponentType>> batchedType(@Source Uni<List<Component>> components)

in ComponentResource

3. Conflicting field names.

So you have:

@ManyToOne(fetch = FetchType.LAZY)
private ComponentType type;

on Component

So in GraphQL there is a type field on component.

Then you also add a type field via the @Source annotation, so now there are two fields with the same name.

(@jmartisk we need to fail or at least warn when this happens - I created an issue for this: smallrye/smallrye-graphql#2064)

Now you have to choose one or the other:

A) Using @ManyToOne
If the field are on the Component as a ManyToOne, marking it as EAGER works. No GraphQL Batching is not involved. When not using Uni (so non-blocking) and the non blocking db driver, LAZY should work. I created another issues to look into getting LAZY to work with non-blocking driver (if possible) smallrye/smallrye-graphql#2063

B) Using GraphQL Batching
In this case there should not be a type field on the Component Object, only a Source that will fetch it. I am not sure if this will work as the current example are using the type field from the Component.

If you do change the implementation to use B, please let me know if that worked or if we need another issue

Hope this helps.

[UbiquitousBear]

@phillip-kruger sounds good - I think in this case, it makes more sense to set the fetch type to eager, and omit the type function in the resource - thanks :)