High level comparison to cohttp-async

[mooreryan]

Hi! In this discussion on the routes repository, I saw you mention this library. It looks nice and straightforward!

I'm currently using cohttp-async, and I was wondering about the high-level (sort of philosophical) differences from that. Not necessarily about details I can read in the mli files, but more high level than that. E.g., are there certain use-cases you had in mind when designing it, or places where shuttle_http is clearly a better choice?

Thanks!

[anuragsoni]

Hello! 👋🏼

At a high level some of the differences from cohttp-async that I personally find useful are:

• Improvements around connection handling since it supports timeouts for idle/slow clients (helps close misbehaving clients so you don't leave connections open)
• Shuttle sets up a more robust error handler that traps any unhandled exceptions and ensures connections are cleaned up.
• Connection clean-ups also ensure that any streaming bodies get closed, so they can reliably release resources held by them (file handles, etc) if the remote client connection closes, or there is an unhandled error in the server handler.
• On the client side, there is better support for persistent clients

Aside from the differences listed above, the other changes are around performance (in my testing shuttle performs better than cohttp-async), and in general a simpler API (no need for conduit for working with SSL encrypted connections).

[mooreryan]

Thanks for writing this, it's is great info!

[anuragsoni]

Glad it helped! If you end up trying the library, don't hesitate to reach out on discussions here if you run into any issues!

[mooreryan]

Thanks! I did actually port a small service from cohttp-async to shuttle_http, and it was quite pleasant, thanks!!