https://kotlinlang.org logo
Title
m

MrNiamh

02/03/2021, 2:51 PM
Hey guys 👋 hope you've been well, it's Niamh (from Bo)! I'm in a new role now, and we're using Spring Webflux 🤢 with netty , but the intention is to move to something else. I've of course mentioned Http4k, so just been reading a bit around migrating away. We can't/dont want to do a big migration, and would prefer to do it bit by bit. I saw this post, however it's more for mvc and not webflux, and I'm struggling to find something similar for webflux. Has anyone got any experience doing this migration from webflux? Any suggestions would be massively appreciated.
r

Razvan

02/03/2021, 6:17 PM
It can be difficult depending on how you use webflux in your project. If you use coroutines (or ReactiveStreams Flux/Mono) and a lot of asynchronous functions it might get quite challenging as http4k is not asynchronous.
d

dave

02/03/2021, 6:23 PM
there are a couple of approaches, both of which involve stealing functionality from the old app and replicating it either outside or inside your new app.: The first would be to build an http4k proxy on the outside which just passes through traffic to the spring app. then gradually steal the traffic from the spring one until you are done. The second would be to build the http4k stack inside the spring app and reconstruct http4k requests/responses in the controller to be passed through, injecting all of the dependencies for each endpoint (which can be magically injected into the spring controller). then you end up removing the controller itself.
but what @Razvan says is true - if you're relying on a bunch of streaming stuff then it will be harder (but that would definitely point to version 1 of that approach)
r

Razvan

02/03/2021, 6:24 PM
I didn't have the courage to think about such migration on the project we are doing the same... think we'll wait for a re-write, because if you get ride of spring you get ride of the hole framework not just the http handlers otherwise I can't see the hustle.
d

dave

02/03/2021, 6:26 PM
the most important thing is to abstract your tests first. rewrite them from spring automagic into standard http4k tests (and then use a real client instead of the in-memory app)
m

MrNiamh

02/08/2021, 1:57 PM
Thankfully we aren't using coroutines or many mono related things (even more reason to migrate away), so that part shouldn't be too hard. For the second approach, do you know of any examples for how we would build the stack inside the spring app? I suppose i'm not very clear on how that is done. Think it might be easier to go for the first approach. I also like the assumption we have tests 😉 That's a whole other thing I'm working on improving