Comment by Sebastian on "How are you building GraphQL APIs? What are your biggest pain points with current tools & libraries?"

I was about to develop an own graphql service for our product. The deal breaker was that every Java implementation of graphql I found relied on a static schema system for the data types. But the final data type set is made by our customers.

The solution would be to create a dynamic schema generator for the data scheme on runtime and check that the Java lib would allow any kind of dynamic schema loading without forking it but I haven't found the time to digg into that because it's still currently a green field project.

Hmm, wonderful! I didn't think of this situation yet. Graphene (the python implementation) uses single schema "by default" like the java libs you mentioned, but this could change. Maybe you can load the schema based on a session or something similar. Think this is an interesting question that might be very useful for further development of our product as well. Can you inject some middleware in your webapp and load the schema similar to how most database connections are pooled?

It's not just only webapp. The GraphQL Service would be available to any client that wants to use our system this way.

loading and generating the schema at service startup would do the trick for me. However every implementation I saw required to generate the schema definition at development time and throw out some generated java classes which have to be compiled etc.

With reflection would this be a solvable task at runtime, but 1) reflection is gone with java 11, something to consider for the long run and 2) I'm not confident with this kind of solution, looks like a questionable move to me. I think this can be done better but like I said, currently there is no pressure to accomplish this task therefor currently on hold.

Hmm. Maybe use a more flexible language like Python for the graphql part? The schema is quite flexible and python doesn't compile in that sense, it translates really fast and caching does the rest. You could write the backend in Java. Would that help?

hmm I can think about that. I just used python for some scripting.

Does python have a eureka client (netflix)? The GraphQL Service will be deployed in a netflix technology based service registry and currently only Java/kotlin and nodejs are supported (officially on paper). But that's not a deal breaker yet.

Thanks for the tip. I will do some research if python can solve the issues I had with the Java implementations.

This is very interesting. Thanks for sharing.

On an unrelated note, I am curious if there are any advantages of using eureka over consul/istio. I don't work on java stack, but wondering if it has any novel features.

Search Hashnode