The new `http4k-bridge-spring` module seem like a ...

# http4k

[Andrew O'Hara]

The new http4k-bridge-spring module seem like a very exciting feature to show off. If I understand correctly, all the bridge does is let you expose a spring HttpHandler as an autowireable Controller. So you'd probably do a full migration in steps like this:

1. Migrate spring controllers to http4k, one-by-one
2. Replace the spring filters with http4k filters
3. Replace the server with an http4k one
4. Replace the autowiring with pure dependency injection
5. Replace the spring application with a main method
6. delete spring
But I'm not sure I'm practiced enough with Spring to come up with a bad complex enough starting point to make a full migration feel authentic to an audience of veteran spring developers. Maybe I should just give it a try anyway 🤷

[dave]

yes - the idea is to implement the functionality endpoint by endpoint into an internal Http4kApp, then remove the migrated controller. When you're finished, you've got fully formed app which you can then just throw away the wrapper of and then attach to a runtime

[dave]

We've got a few basic examples from here

[Andrew O'Hara]

Yes, the example was a good place to figure out what the bridge does.

The part I'm more concerned about is steps 2-4, which I think might can be quite a bit more complex in your typical spring app. I've seen hundreds of lines of xml configuring filters...

[dave]

well yes - there is no getting around some types of complexity. But it will allow people to make a good start hopefully.

[dave]

And of course, you can use the reverse idea to migrate FROM http4k to something else 🙃

[Andrew O'Hara]

Yeah. Well, I'll give it a shot 🤷 . Remains to be seen whether I can make it simple enough to fit into a single video, or if will require a series.

[dave]

I've made an entire career out of this type of thing! 😂

[Andrew O'Hara]

Ah, that's right! Maybe I'll run the script by you then 😉

[Andrew O'Hara]

How do you convince people to leave their precious spring behind? Besides testability.

[Andrew O'Hara]

Ah, here's some other complications I thought of while shoveling snow.

1. It's very common for people to use spring extensions like spring-data and wherever RestTemplate comes from. Since the RestControllers depend on them, our HttpHandler tests will still depend on spring, which eliminates the performance improvement of http4k. We would have to replace those dependencies before we can obtain any benefit
2. Spring locks their users into specific java versions. I believe my old colleagues are currently TRYING to upgrade to java 9. I fear that the bridge requiring java 21 will preclude the majority of spring users from upgrading to http4k

[Tim Mortimer]

On point 1. I'd probably think of it more like strangler fig? Find an aggregate / small bounded context to separate out into an HTTP4k endpoint?

On point 2., the new step 1 becomes "upgrade to Java 21" 😬

[dave]

How do you convince people to leave their precious spring behind? Besides testability.

yeah, that's a real skill 😂 . A lot of time, projects have worked their way into such a state that they cannot deliver anything at all and are willing to listen to someone they think can help. Also - it's amazing how little people actually understand about how spring works under the covers when you ask them,...

[dave]

It's very common for people to use spring extensions ...

We can't expect all of the benefits to come at once when migrating. Performance is only one of them - the less stuff you have in your magical map the faster it will start/run, so it's about incremental improvement really.

Of course, you can write the tests against your spring app to prove it's not busted as you go) as integration tests (or maybe we should bridge the inbound traffic as well so it hooks into the spring testing madness 🤔), and then once you have finished you can just rip away the integration layer and you have a set of instant unit tests which should have a super fast test suite...

[Andrew O'Hara]

it's amazing how little people actually understand about how spring works under the covers

It's not just spring developers that are quilty of this, but I agree it's shockingly common, and I feel like it lowers the overall quality of developers

On point 2., the new step 1 becomes "upgrade to Java 21"

I wish it were that easy. Spring dependency graphs are complicated, and upgrading spring versions requires major architectural revamps. You will often have to upgrade several major versions to get to one that supports java 21, and since it's so difficult to upgrade, developers often stick with the major version they started with 10+ years ago. Several migrations would be required just to begin gradually converting to http4k.

Since it seems like only a small chunk of spring projects are prepared for a migration to http4k, I'm not sure I would have a particularly large audience to target in this potential video/series. I think I'm less excited to talk about this topic now, and would rather do one of my other ideas.

[dave]

🤣

[Andrew O'Hara]

Maybe Duncan wouldn't find it so daunting to cover, but I think I'd rather start a new series on a greenfield http4k project. I was waiting for v6 to release before starting!

[Tim Mortimer]

I didn't say it would be easy, but I wouldn't make a massive meal out of it either. It's a boring job, but working through it one release note at a time is a good way to break up the work.

Sadly, the most common upgrade strategy I see in the wild is people incrementing the Spring version in pom.xml and fixing what breaks. They then tend to complain about how painful and messy it was.

Good luck with the series! I look forward to it 🙂

[Andrew O'Hara]

I'm now recognizing the irony of not thinking it worth to make a series on upgrading to http4k... perfectly mirrors spring developers not thinking it worth the effort to upgrade to http4k 🙄