Now, would you say, @sdeleuze, that Spring Fu is inspired by #ktor?

Spring Fu might even be inspired by #vertx.

Believe me or not, I never had a look to Ktor to avoid tentation to copy.

i don’t see anything in the documentation regarding integration with regular spring beans did i miss something? or does that mean that it’s all or nothing? it could ease migration a lot if there would be some integration path

@sdeleuze I see, may be you should look at ktor, there’s no problem copying, and may be you can find some ideas for better DSLs

@nfrankel These are regular Spring beans. You can mix JavaConfig and functional beans if you use the right application context impl. Please create a documentation issue about that I will update the doc.

@sdeleuze i’m thinking about migrating the spring pet clinic

Good idea, maybe when SQL support will be available

and when it’s available as a standard dep 😉

Is the underlying implementation still the same? I’m wondering, because in TechEmpower Benchmarks Spring is somewhere at the bottom, and I wonder why. And if Spring Fu will have a different story.

1) TechEmpower benchmark, especially the simple tests are very far from real world use cases so not really relevant. 2) Spring Fu is based on WebFlux.fn which is I believe not benchmarked yet, but Reactor and Netty super fast and scalable and WebFlux.fn is a very thin layer on top of that so I am confident 3) Spring Fu and WebFlux targets much more than just request / Reponse. We will give the SQL benchmark a try asap Reactive SQL support is finished.

i’d really be in a favor of a non-webflux implementation i’m afraid a lot of people already think about migrating to webflux while reactive is clearly not suited to every use-case

I would agree with Reactive API only but one of the Spring Fu design principle is to provide Coroutines API as well for imperative-like programming.