Should Finch run directly on Netty? Cut out the middleman, Finagle?

[vkostyukov]

I'm taking some time off work and may be able to focus on rewriting FInch's core to stop depending on Finagle, and leveraging Netty's HTTP implementation directly instead.

The future of @finagle is little concerning. I don't see us getting any OSS releases going forward.

@rpless @joroKr21 @tpetillot: how do you all feel about it?

[joroKr21]

Yeah with the current situation at Twitter I agree that's a smart thing to do. My time for OSS continues to be very limited but I would happy to review and merge PRs to move to Netty. Should that be a separate module to make it clear?

[sergeykolbasov]

The whole situation is heartbreaking 💔

Most of the "high-level" HTTP libraries or frameworks have one level of abstraction to connect raw HTTP protocol with the API layer. For Finch it's Finagle, for http4s it's blaze. Does it make sense to introduce something similar with Finch?

Also, there is a client counter-part, wonder if it makes sense to have it in scope.

Anyhow, all of it sounds like a massive amount of work.

[spockz]

I agree with, what I think is, @sergeykolbasov's point. It makes sense to have an abstraction layer. On a technical level finagle has always played that role adequately.

Now given the tragedy at Twitter, In my opinion it makes makes more sense to fork finagle and maintain that fork, rather than to rebuild everything it has build on netty directly in finch. More people can benefit from it.

I do not know how to properly maintain it though. Twitter has been a very active and steering custodian of finagle which allowed people to consume finagle passively. As such there also is no vibrant already active community and it would need to be booted first.

[rpless]

I generally agree with the points that have been made here.

I feel like a fork would be the better option from finch's perspective. However, it is not going to be as simple as forking finagle. util, bijection, and any other finagle dependencies that Twitter maintained would also need to be forked and maintained. Plus lack of community as @spockz points out.

Given those challenges, I think it would be worth figuring out what features that finagle http server's currently support that we need and what that might look like if we moved to Netty. The other challenge I see is needing a replacement for Filters. I know in theory there are ways we can replicate a lot of that functionality with Kleisli/Writer/StateT, but that remains largely undocumented.

[vkostyukov]

Maintaining a Finagle fork is a big commitment. I don't know how feasible it is without being backed by some corporate entity.

I think our realistic options are either Netty or blaze (which re-implements HTTP/2 protocol outside of Netty). I'm going to experiment with the former (Netty) over the long holiday break and see what it looks like.

[dimitarg]

Digression on the http4s bit - I think these days ember is "the reference" http4s server implementation, as opposed to blaze. Have run it in production for a year and something now - stability is pretty great had no issues. I can't comment on latency and throughput comparisons with blaze and netty, though. The services I've had to operate were always pretty database-bound so I never had to care.

[yaroot]

@vkostyukov Hi, have you considered http4s, which is quite low level (imho) for http abstraction. There is also a not so new http impl in http4s called ember, which also targets js and native. It would be cool for finch to support js and native too.