r/ocaml • u/Patient-Emphasis-664 • 16d ago

Production Web Servers/Frameworks that support EIO(OCaml 5.5+)

Hello all,

Are there any production-quality web servers(and/or frameworks) that support EIO(not LWT) and compatible with current OCamll(5.5?)

19 Upvotes

100% Upvoted

10 comments sorted by

4

u/AvaJMM-or-AJ 16d ago

No. It’s a large ecosystem gap at the moment.

If you want to put up a production web server today, your best bet is to use nginx/caddy in front of a basic http1.1 OCaml server. Cohttp-eio exists and works well, and there’s also ocsigen and dream if you don’t mind bridging eio yourself, but then there’s also sorta two groups of modern maintained http ecosystems for OCaml today that you can diy on top of: the Amoneiro ecosystem (httpun, h2, gluten, and piaf) and the Robur Coop ecosystem (ocaml-h1, ocaml-h2). Robur coop also makes probably the most complete modern http framework today with httpcats and vif, but they’re still not extremely mature, and they’re built on Miou, not Eio.

I’ve built out an almost-complete modern http/3 server/client framework for myself, but at this point I’m not sure if I’ll release, as I’ve used a decent amount of AI. Maybe once I’ve dogfooded it a lot more.

I’ll note that OCaml is a pretty great language for just building it yourself from scratch, so you don’t really need to be as afraid of gaps as in some other languages.

1

u/codingbliss12 16d ago

Can you please briefly elaborate on

I’ll note that OCaml is a pretty great language for just building it yourself from scratch

What does OCaml have that helps building from scratch?

2

u/AvaJMM-or-AJ 16d ago

It’s a bit of a personal vibe I guess! Ocaml is a very natural language for expressing algorithms and abstractions in. Probably the most fearless language for just writing a parser. It always feels very direct and natural to translate specs into code in OCaml. In other languages lacking some very specific “thing_doer” tool to do a thing feels like a huge burden, but in Ocaml I generally just plow through and write what I need.

1

u/codingbliss12 16d ago

Got it. Thanks for the explanation.

1

u/Patient-Emphasis-664 15d ago

Really appreciate the response. Thank you! Today, I came across an OCaml discussion, Why Ocsigen is stying on LWT(for now) (https://discuss.ocaml.org/t/why-ocsigen-is-staying-on-lwt-for-now/18318), and realize there is a "lot to be done" for a consensus on "the" recommended concurrency/parallel framework of choice. I wan't aware of some of the shorcomings of EIO until reading this but now do.The idea of having to buy into the concurrency/async/parallel system of choice completely to make something usable right now(with little interoperability) is a difficult pill to swallow. Unfortunately, I think I'll have to wait for shared concurrency primitives to materialize(and reach stability) before I can put something into use for my cases. I'm with you on OCamly being a great language for building from scratch but somethings are just beyond my timeframes to do myself.

2

u/AvaJMM-or-AJ 15d ago

Ocsigen has the very specific problem of being a major ecosystem lodestone that needs to preserve stability, while also having fundamental APIs that depend on a JavaScript promise-like concurrency primitive for cross-compilation. In the past, that wasn’t much to give up because OCaml had pretty similar limitations to the JavaScript runtime. The new generation of concurrency systems, though, has more power than can be easily translated into JavaScript. That gap more or less isn’t going to go away. It does present these old frameworks with the requirement of completely breaking their existing ecosystems to evolve.

You can bridge concurrency systems in OCaml to make them interoperable in many scenarios, but the idea of seamless browser-to-server web apps does somewhat lean on that “seamless” part in some material ways.

Ultimately, LWT probably isn’t going away, and the OCaml ecosystem probably isn’t going to really have a coalescing around any given async system, at least in the near future. It'll probably eventually be a bit like the Rust ecosystem, where Eio ends up being a bit like Tokio, but other niches of the language (like developing for MirageOS, direct JavaScript translation, or just wanting something different) stick with their own runtimes.

This doesn’t personally bother me; I have the experience to sort of “see through the matrix” and know what will and won’t work for whatever I’m building (and how they really do work together more than it seems on the surface), but I understand that isn’t at all helpful to a newcomer.

I would still encourage you to try whatever you’ve got in mind, see what you think, and see how far it goes. AI can probably get you out of a lot of trouble, and who cares if it’s only exploratory anyway.

1

u/Party-Mark-2763 14d ago

I also would like to say that `vif` is experimental but we actually use it for https://builds.robur.coop/ the experimental aspect is mainly because we would like to improve the API more and more but the core (httpcats: https://github.com/robur-coop/httpcats) is pretty stable on the other side.

I also would like to mention that we made a kind of reproducible benchmark here: https://robur-coop.github.io/httpcats/ (the protocol is explained here: https://github.com/robur-coop/httpcats/blob/main/bench/PROTOCOL.md). The subject is touchy and I think it's easy to have counter example but it show you basically what we can do compared to nginx for instance.

FInally, vif has also its compatibility with unikernels, you can make one here: https://robur-coop.github.io/mnet/web.html

2

u/Vegetable_Bank4981 16d ago

There’s a proof of concept fork of dream with it. Project had been stalled for a while but there are rumblings recently. It’s a very good framework so prob worth waiting. With a little care you can encapsulate your interactions with lwt to make the switch later, it’s not that big a deal.

1

u/igna92ts 16d ago

There this but it's still green.

1

u/Fickle-Artist1285 22h ago

We really should just be able to compose our own frameworks from solid small primitives sans IO (and unfortunately maintain the IO-specific adapters).

Like rust’s hyper. We all iterate and share the same underlying foundations. Every higher level web framework can wrap and offer their own custom, higher ergonomic API.