Hey folks, happy Friday! I’ve thrown together an exploratory project using Arrow 2.0 and Http4k after getting more into FP since finishing the ‘Function Programming in Kotlin’ book. If anyone could spare some time to have a quick look and provide any feedback on how I’m using Arrow whether that’s reasonable and any other places that I’m not utilising it but it could help that would be really appreciated (feel free to make a PR or just reply here). The project is a simple Http service with which you can create, get and solve simple quizzes. To use the quiz endpoints you need to register with the user endpoint and use those credentials as Basic Auth. There’s a lot of real-world input validation missing as this is just a test project. You can find it here: https://github.com/TevJ/kfp-quiz Thanks

Just took a really quick look, scanning some of the files and noticed you're already using new APIs 💪

zipOrAccumulate

&

mapOrAccumulate

. What was your experience? And feedback? On a quick look it looks pretty nice IMO! Glad to see that now Arrow more easily supports http4k since the DSLs don't require

suspend

anymore ☺️ I really like the DSL style of http4k, but too bad they don't support

suspend

. I back tracked the issue, and feel their pain that no-one offered help to support it 😅 Given the size it's not a small endeavour in time of work hours sadly. Otherwise I'd take a stab at it.

Thanks for the great feedback Simon!

zipOrAccumulate & mapOrAccumulate. What was your experience? And feedback?

I found the

zipOrAccumulate

&

mapOrAccumulate

functions easy to use after a quick read through the PR discussion. I definitely agree that a separate

Validated

type is unnecessary and being able to use either everywhere feels more natural.

I really like the DSL style of http4k, but too bad they don't support suspend.

Yeah, it's definitely a shame there's no couroutines support but I still wanted to give it a try as the API is so nice and my company are big users of Http4s so I wanted to see the difference. I might see if I can get it working with Loom and run some performance tests.

Nit: I see you have some if/else usage here for example, and that is absolutely fine but you can also replace it with:

Nice! I hadn't seen the

ensure

function yet. I definitely prefer to use the available DSLs where possible over

if/else

so I'll update that.

Unrelated nit to Arrow, UserRepository & QuizRepository seems a bit unnecessary complexity if you follow YAGNI.

Agreed, I'm usually against unnecessary abstractions and the repository here is definitely in anti-pattern territory. I was thinking about attempting to model some sort of caching layer in there but I've decided that's out of scope for this project so I'll remove the repositories to clean up the codebase a little bit.

If you're interested, at the end of this month we're releasing our new website and I think it could be interesting to share your project as a Http4K project example.

That sounds great, I'd be more than happy to share the example on the new website. 😊 Thanks to you and the Arrow team for all your hard work on the library, Arrow 2.0's looking in great shape. 💪

@Tom Everton Good work overall! I had a couple of tweaks that might help, so I've raised a PR on your repo to make it a little more http4k-like (well - as we would write it). Happy to answer questions about it 🙂 Expect Loom in http4k v5, which is incoming - planning to have it released by around KC23 We'd be interested to know the results of any performance tests that you do - if it's anything like the TFB then we'll be happy enough 😉.

Performance should be completely unaffected by using Arrow. All code underneath is optimised everywhere, and the DSLs make working with functional patterns very lightweight. I would be extremely surprised to it having a negative effect on performance.

Expect Loom in http4k v5, which is incoming

Interesting, I guess this would offer a solution to the

suspend

issue. Where every

request

could run

suspend

in a separate

VirtualThread

? Or offer a

runVirtual

builder instead of

runBlocking

. Is there an on-going discussion on the changes of v5 somewhere publicly available?

Yeah - I don't expect arrow to make any difference to the performance - I was more interested in the differences between http4k other web libraries really (both in build and run modes 😉), The initial v5 Loom support concentrates on the Servers that support Loom. Whilst it's still not-Gold, we'll provide alternative ServerConfig objects (e.g

JettyLoom

) to support these cases so switching it back out will be a one-liner for most projects. The main reason for v5 is that we're going to start tracking major JDK versions and update our build JDK to 19, so this has an effect on what's available API-wise (Nashhorn for example). We'll also do a sweep of the current deprecations. But for virtually all projects this will probably be a no-op/minor impact upgrade. We're still looking to support everything from J8 onwards and the main APIs are unaffected.

Thanks so much for checking this out as well David! I'm just going through your PR now it's really helpful.

Expect Loom in http4k v5, which is incoming - planning to have it released by around KC23 We'd be interested to know the results of any performance tests that you do - if it's anything like the TFB then we'll be happy enough

That's very exciting news! I'll be sure to share any of my own results in the http4k channel. Shout out to you and the http4k as well for your amazing work, I loved using http4k while putting this little project together. It's definitely helped me cement the choice of using http4k and Arrow for an upcoming production project.