actually http response codes doesn't play an important role in graphql communication (now), so you would only check for errors in your application by inspecting the result: either you have "data" or "errors" field (indicating a technical error) or both. If you have "data", then - depending on your schema - that field can contain "expected" errors (like field validation errors, unmet requirements etc.) There is a spec proposal "GraphQL over http" that would add some http status codes, but I'm unsure about the state of that draft (github.com/graphql/graphql-over-http/blob/main/spec/GraphQLOverHTTP.md)

For me it's esp. the way you work with search params. I also like the typesafe routes, but not sure yet how really important they are in my apps. Also I like the loader api more than the one from react router, although I'm in general not a big fan of loading data in routes.

I've built the trace directive myself, not sure if it is working with newest Spring for GraphQL versions. I think the easiest is to use the TracingInstrumentation (www.graphql-java.com/documentation/instrumentation/#apollo-tracing-instrumentation) provided by graphql-java. You can create and instance yourself and return it from a Spring configuration @Bean method. Mono should work out of the box, maybe you need to configure the thread pool.

I'm not sure if there is an easy or generic way. There is the PropertyDataFetcher from graphql-java that is used if you don't register your own DataFetcher or resolver/mapping function for a field. That DataFetcher uses some naming conventions (java bean style). Maybe it would be somehow possible to write and register an own default datafetcher, but that might not be easy. If you only have a few cases where java attribute name does not match graphql field name, I would implement own SchemaResolver for that fields

@@nils-hartmann thanks for the reply, you are right. PropertyDataFetcher is the default one and following Java bean naming convention, but I was looking more generic way, like how we are going to mention the @JsonProperty annotation as part of our DTO or like @Column(name="") as part of the entity. It would be great, if you can have a video or article on the same how we are achieve that. I see in graphql-java-tools they were able to achieve the same with FieldResolverScanner. Is there any way we can use the same in Spring for GraphQL?

In general I see two options: first create a class that contains all fields from all union types you actually have included in your query. Something like this for the mutation from the video: // contains the fields you have selected in your query from Vet record VetResponse(String id) {} record AddVetResponse(VetResponse vet, String errorMessage) {} (mabye vet and errorMessage could be Optional's) Or you select also the __typename field in your query (mutation addVet(...) { __typename ...on AddVetSuccessPayload { ... } ...onAddVetFailedPayload { ... } }). The __typename field returns the name of the union type in your answer ("AddVetSuccessPayload" or "AddVetFailedPayload"). Based on the typename you can handle your response differently. For example using the execute-Method from Spring GraphQL's GraphQlClient Object (docs.spring.io/spring-graphql/docs/1.0.0-SNAPSHOT/reference/html/#client-requests-execute) you could first read the __typename field and then determine which field(s) you call the toEntity method for. It also might be that is easier to create an own Error-Object for the AddVetErrorPayload type (type AddVetErrorPayload { error: AddVetError }) if you have more than one field in the error type. This is definitley a place where code generators (like www.graphql-code-generator.com/ for TypeScript) would be helpful 😊 Hope that helps!

@@nils-hartmann Thanks, I will try and let you know how it goes.