Update web server to http4s

[pauljamescleary]

We have been using akka-http for a while. As a tech project, would like to explore changing to http4s as part of standardizing the stack.

Opening this as a discussion to explore ideas. Here are the major parts that would need to be moved:

1. JSON - there is custom json validation that is now outdated. Should move to circe, care must be made here to ensure request and response payloads remain backward compatible

2. Authentication - the signing process is separate, which I hope would make using auth in http4s straight forward (but have not delved deeply as of yet)

3. Services - the existing Akka HTTP stuff is rather thin, all the business logic resides behind services. Like with JSON, remaining backward compatible is key.

4. Tests - we have a lot of tests using the akka-http test kit. This is definitely a lot of work

Considerations:

• We have hundreds of automated E2E tests, so staying backward compatible should be covered by running those tests

[remerle]

As a tech project, would like to explore changing to http4s as part of standardizing the stack.

@pauljamescleary What's the benefit of moving to http4s? How does this standardize the stack?

TBC, I'm not opposed, I just want to understand the rationale.

[pauljamescleary]

Good questions. The json stuff originally implemented is dated and there are much better ways to do it now that would simplify the code. That’s the gateway drug to be honest.

We have moved to using other typelevel libraries to where typelevel libraries are the norm. Those include fs2, cats, cats effect and pureconfig. Moving to http4s and circe rounds out our typelevel migration. The effect is consistency, akka-http is a bit of an odd ball at the moment. We have to do an unsafeToFuture in it which is ok but would be preferable to be cats effect all the way down.

Some random thoughts there as I’m mobile right now, but happy to have the discussion.

[remerle]

Yeah, it would be great to not have to worry about processing the effectual actions. The fewer unsafe* calls that the devs have to make, the fewer will be made unnecessarily.

I do like to remain pragmatic, though, and this would be a tough to do incrementally. Maybe it's time to consider a major release that makes some major foundational shifts - http4s, consolidated portal, Scala 3, improved CI pipeline, etc.

Since our current release isn't seeing many functional changes (though more are in the pipeline) it may be a good time to split off, and start work on VinylDNS vNext. We can port any functionality added to the 0.x version to the vNext version as they trickle in.

I would propose strictly foundational changes for vNext. We can build new and exciting features on that clean foundation after initial release. I think we have a good start for the foundation changes from several of your issues, we can wrap those into a roadmap/execution plan.

Something to consider. Maybe @vinyldns/maintainers can chat and come up with a strategy.

[pauljamescleary]

@raghu999 That's a good idea. I'll start a thread over there