Could you please describe your stack for web apps development in OCaml with reasoning about it?

web

#1

Could you please describe your stack for web apps development in OCaml with reasoning about it?


#2

I’m curious about this as well. This is what I’ve understood so far:

  • there are no production-grade database bindings for Postgres. Discussion here.

  • there are no full-fledged web frameworks in the OCaml ecosystem with commercial users and maintenance. Ocsigen has quite a bit of learning curve and probably is not a good fit for small inexperienced teams.

  • there is Opium by @rgrinberg, which adds routing and HTTP niceities to CoHTTP, which is a robust web server. It is minimalist compared to things like Rails. But with a session management library like inhabitedtype/ocaml-session and OCaml’s power and type-safety, we can hand-roll a sturdy web app.

Only if there was a better story in the database binding section… :slight_smile:


#3

About postgres in production:

Markus’ Posgres bindings are very very solid
http://mmottl.github.io/postgresql-ocaml/
(PG’OCaml, without the syntax extension, is fine too, and more Lwt-friendly, but if you need TLS, you need to setup tunnels separately).

About web-development stacks:

We’ve used the whole Ocsigen/Eliom stack in a decently big project,
it was a few years ago, it was overall good, but indeed the whole stack at once can be a bit
hard to learn and a bit of a moving target (much less nowadays).
And it could be a bit annoying to manage flexible deployments (I mean compared to what we are used to in OCaml, but not compared to popular frameworks in mono-typed languages…
anyway nowadays it just means “use docker”).

In a few much more recent projects, I’ve used an Ocsigen-light setup:
Cohttp + Js_of_ocaml + Tyxml_js + (Búnzli’s) react.
That’s really nice and very "flexible/hackable” (things like having the result of js_of_ocaml's compilation lifted on the server code as a string, or using JSONP servers, webworkers, etc.).
There is a one-time build-system & communication initial setup cost though because everything is custom (jbuilder/dune has made things easier there too).


#4

I’d second that. After playing with it when building ezpostgresql, the impression I get was that these bindings are pretty much stable, in the sense that most postgresql features have proper representations in it so you don’t have to write any C code. One thing to note is, to achieve that, the API is not necessarily user- or FP-friendly. However, one can build a functional abstraction on top of it if they want to (which ezpostgresql is intended to be for me personally, and has been so far).

For webservers, I’m a fan of a lightweight ones (e.g. Express, Sinatra, Flask, etc.), so Opium hits the spot nicely. It supports middlewares so you can pretty much do anything with it. I seldom have to think about HTML and templating since the frontend will usually get separated anyway (and if it does, you might be interested in Reason and ReasonReact).


#5

There is a one-time build-system & communication initial setup cost though because everything is custom (jbuilder/dune has made things easier there too).

Do you have an example online of such a setup ?