Hey folks, happy Friday! I’ve thrown together an e...

# arrow

[Tom Everton]

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

[simon.vergauwen]

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.

[simon.vergauwen]

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

fun from(password: String): Either<FieldValidationFailure, HashedPassword> =
  either {
    ensure(password.isNotEmpty()) { Empty("Password") }
    HashedPassword(BCrypt.hashpw(password, BCrypt.gensalt()))
  }

It's just a nit, if you prefer if/else expressions for using less foreign APIs that is absolutely fine. It does cut back on .left and right calls here. And ensure uses smart contracts so the compiler should know that password.isNotEmpty() == true in the next lines.

Unrelated nit to Arrow, UserRepository & QuizRepository seems a bit unnecessary complexity if you follow YAGNI. If you were trying to follow a specific architecture to mimic a big project guideline I think it's fine though.

Besides that I think it looks really neat! 🥳 Nice work 👏 And thanks for contributing an Arrow example with http4k to the community.

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.

[Tom Everton]

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. 💪

[dave]

@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 😉.

[simon.vergauwen]

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?

[dave]

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.

[Tom Everton]

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.