Pity the Spring Server library doesn’t support the MVC flavor, just WebFlux. It’s not in your plans right? Congrats on your work and making it open-source!

We don’t have plans to support the mvc models as those do not support non-blocking io. You can still use all the other libraries though for the schema generator and federation and have your own custom spring code or even use it in a non-spring server library

With Loom on the radar (Java 17 the next LTS), don’t you think that would make sense to keep support for blocking IO that will become non-blocking underneath ?

my understanding is that Loom will implement something very similar to Kotlin’s coroutines so not really a game changer for this situation. Still I wonder if it would possible to replicate Spring Server on MVC using CompletableFuture, but I really don’t know the details to assert it.

I guess it depends of the perpective you take. My point is that Loom should enable non-blocking IO with existing blocking API. Its effiency still need to be verified, but still. Also our POV in the Spring team (I am one of the Spring Framework/Spring MVC developers) has never been to replace Spring MVC by Spring WebFlux, more to provide a complementary web framework with different capabilities. Coroutines and Reactive APIs are much more powerful than what Loom will likely offer short/middle term, but if it fulfills its promise to make Spring MVC non-blocking without changing user code and with minimal modification on Tomcat/Spring MVC side, I think it will remain the major server used by developer and thus make sense to be supported by the ecosystem. That's obviously only my POV and each open source maintainer puts its energy where he/she wants. 😉

Good to know 👍

You bring up good points, and we encourage our library users to use coroutines where needed (but there are some downsides as we have to go back to CompletableFuture in

graphql-java

), but we just didn’t take the time to build the extra coded need to run both a spring mvc and a spring webflux endpoint. You can look at our implementation in

graphql-kotlin-spring-server

and if there is some code that we could split up into a more general server library we would be happy to do that.

If there is an interest in MVC flavor I’m pretty sure we could create another lib (and we are always open to contributions!). side note: we did originally started with MVC model using

graphq-java-servlet

but since most of our use case resolved around blocking IO calls Webflux fit our needs better

Exciting to know there’s the possibility of support for the MVC flavor! I’m looking into integrating GraphQL into our apps and this lib does a great job in reducing the complexity and boilerplate, but don’t think it makes sense for us to change our apps from MVC to Webflux as it adds a bit of complexity and probably wouldn’t get significant performance improvements, the bottleneck is essentially the db. I feel like this is true for a lot of people and though I don’t have the numbers surely Webflux is being used by a small minority compared with MVC. So here’s my vote for MVC support 😉

One addition thing to consider is that by default all graphql fields should be resolved in parallel - this implies some dedicated threadpool in mvc

right, for my specific situation it wouldn’t be a problem. I’m not yet familiar with coroutines, not sure if it would simplify things.

Carlos, just FYI we've been using just the schema generator of

graphql-kotlin

in a dropwizard context with great results. Could do similar integration for spring MVC pretty easily I'd imagine. https://github.com/trib3/leakycauldron/tree/master/graphql/ is our code -- a minimal spring MVC integration could probably just replicate the

@POST

endpoint of

GraphQLResource

(ignoring the cookie and auth stuff), and get something working pretty quickly.

Thanks @Joe, I’ll take a look.

so any way to use this with ktor server and ktor client ?

schema-generator

can be used with any server