Help: neat way to add other things to schema

[molexx]

JPA is working well but we need to add other (non-JPA generated) functionality to the service too.

A simple way looks to be to use jpa-annotations to annotate a method:

https://github.com/Enigmatis/graphql-java-annotations#fields

jpa-annotations that requires that the GraphQLObjectType it builds be passed to schemaBuilder.query() but that is already called by GraphQLJpaSchemaBuilder and cannot be called twice.

Any suggestions on how we might go about merging these in a clean way please?

[igdianov]

@molexx It is possible to use Graphql-Java Apis to merge two GraphQL schemas into one, but the care should be taken to handle GraphQL type names from each schema, so they don't override each other.

Do you use Spring Boot to bootstrap you app? I can make a Spring Boot auto-configuration module that covers your use case.

[molexx]

That sounds promising, thanks. Yes I do use Spring Boot, that would be great please.

[igdianov]

@molexx I have made a quick spike to explore defining and merging several GraphQL schemas (query, mutation, subscriptions) registered in the Spring application context via GraphQLSchemaConfigurer: #70

I expect problems with clashing root field names and object types. Let's try to figure out use cases and build unit tests to figure out how make names and types isolated within each schema.

[molexx]

This looks great, thanks! I'll have a play.

RE clashing root field names, would it be appropriate within graphql to insert another level at merge time? That could mean that for example instead of all the JPA entities being directly under query they are instead all under a query item called 'jpaEntities' or something?

If that's possible, and not going against graphql best practise, maybe make it optional - if a root name is provided for each schema when calling registry.register() then branch off a new Object of that name otherwise just merge to root as now.

Otherwise I don't see a magical way to handle clashes... either warn or fail would be ok.

[igdianov]

@molexx Sounds good. I will try to play with namespaces derived from root if present. If you have any suggestions let me know.

The field names are going to be less of a problem, but the object types will be. For example, if you have same GraphQLTypeObject name i.e. Date in both Jpa Query and Mutation schemas, then GraphQL-Java Api will fail to build GraphQLSchema if GraphQLTypeObjects for Date do not have the same reference.

I think JavaScalars registry could be used to share common data types, so that if you want to use Date type in mutations schema, you need to wire it using the reference from JavaScalars.of(Class<?> key)

[molexx]

This works well for me, thanks!

A couple of minor points:

• I can't see a way to set the root schema's name?
• is there a way to set the order as in which group of fields appears above and which below?
• if looking at the tests as an example of how to use it it's not obvious that graphql-jpa-query-boot-starter automatically creates and registers a JPA schema.

Now I can use graphql-java-annotations to add non-JPA-based utility functions needed by the front-end. In some of those it would be useful to be able to set the Executor's context - in particular I'd like the HttpServletRequest. Might there be tidy way to do that? This might best be a separate issue and PR?

Yes I see the problem with the (non-common) object types. I guess GraphQL isn't designed to have nested scopes or namespacing. Probably OK to leave that for now I think, if anyone has suggestions we can discuss them in a new issue. Maybe make fail vs warning a parameter?

Thanks again!

[igdianov]

@molexx

• I can't see a way to set the root schema's name?

A: Can you provide the example of how you would like to set the schema name? I can extend the GraphQLSchemaFactoryBean to provide a configurer Java api to customize the merged schemas root names, etc.

• is there a way to set the order as in which group of fields appears above and which below?

A: Can you give me a specific example what you want get as a result?

• if looking at the tests as an example of how to use it it's not obvious that graphql-jpa-query-boot-starter automatically creates and registers a JPA schema.

A: The tests in auto-configure module do not need to use jpa-query-schema module. I thought it would make sense to keep the more abstract. The starter module has an GraphQLJpaQueryConfigurer to wire the schema.

Now I can use graphql-java-annotations to add non-JPA-based utility functions needed by the front-end. In some of those it would be useful to be able to set the Executor's context - in particular I'd like the HttpServletRequest. Might there be tidy way to do that? This might best be a separate issue and PR?

A: Let's create a separate PR for that. I think it is low hanging fruit....

Yes I see the problem with the (non-common) object types. I guess GraphQL isn't designed to have nested scopes or namespacing. Probably OK to leave that for now I think, if anyone has suggestions we can discuss them in a new issue. Maybe make fail vs warning a parameter?

A: You will need to use JavaScalars to share common data types between Query and Mutations.

If you are OK with initial implementation in the PR, let's merge it, release it and iterate.

[molexx]

The example app sets properties graphql.jpa.query.name and graphql.jpa.query.description - these are now ignored when merging.

Thanks. Yes a separate PR is fine.

This is great as it is, please merge. Thanks!

[igdianov]

@molexx I have merged the PR and released graphql-jpa-query:0.3.12 to Maven Central. Thank you for feedback. Let's iterate to improve things.