https://kotlinlang.org logo
#feed
Title
# feed
s

Shane Myrick

04/14/2020, 4:33 PM
c

Carlosb007

04/14/2020, 4:49 PM
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!
s

Shane Myrick

04/14/2020, 4:51 PM
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
👍 1
s

sdeleuze

04/15/2020, 9:57 AM
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 ?
c

Carlosb007

04/15/2020, 10:32 AM
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.
s

sdeleuze

04/15/2020, 12:52 PM
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. 😉
👍🏻 1
c

Carlosb007

04/15/2020, 1:00 PM
Good to know 👍
s

Shane Myrick

04/15/2020, 5:32 PM
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.
d

Dariusz Kuc

04/15/2020, 6:02 PM
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
c

Carlosb007

04/16/2020, 7:19 AM
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 😉
d

Dariusz Kuc

04/16/2020, 11:42 AM
One addition thing to consider is that by default all graphql fields should be resolved in parallel - this implies some dedicated threadpool in mvc
If you are using some thread locals (as we did) it also complicated things a bit with how to propagate those values over
Maybe it could be simplified now with coroutines
c

Carlosb007

04/16/2020, 11:45 AM
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.
j

Joe

04/17/2020, 3:27 PM
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.
c

Carlosb007

04/17/2020, 3:52 PM
Thanks @Joe, I’ll take a look.
n

Nikky

04/20/2020, 7:35 PM
so any way to use this with ktor server and ktor client ?
d

Dariusz Kuc

04/20/2020, 7:52 PM
schema-generator
can be used with any server
❤️ 1
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
🆒 1
👍 1
5 Views