<https://medium.com/expedia-group-tech/graphql-kot...

# feed

[Shane Myrick]

https://medium.com/expedia-group-tech/graphql-kotlin-2-0-4006ea41f774

[Carlosb007]

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!

[Shane Myrick]

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

[sdeleuze]

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 ?

[Carlosb007]

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.

[sdeleuze]

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. 😉

[Carlosb007]

Good to know 👍

[Shane Myrick]

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.

[Dariusz Kuc]

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

[Carlosb007]

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 😉

[Dariusz Kuc]

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

[Dariusz Kuc]

If you are using some thread locals (as we did) it also complicated things a bit with how to propagate those values over

[Dariusz Kuc]

Maybe it could be simplified now with coroutines

[Carlosb007]

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.

[Joe]

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.

[Carlosb007]

Thanks @Joe, I’ll take a look.

[Nikky]

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

[Dariusz Kuc]

schema-generator can be used with any server

[Dariusz Kuc]

as for the client I got WIP branch -> https://github.com/ExpediaGroup/graphql-kotlin/pull/595 few small issues left and hopefully will start splitting it up and merge it soon