Dream — an easy-to-use native Web framework to go with ReScript

I’d like to announce Dream, a very easy-to-use native Web framework for OCaml and Reason, ReScript’s native cousins!


The easiest way to get started is with the quick start script:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/aantron/dream/master/example/quickstart.sh)"

The script just checks out the Dream repo and issues the same commands as in any of Dream’s examples. So, you can pick any of them as a starting point, copy it out of the repo, and go from there! In particular, see the ReScript full-stack example, which combines a simplistic ReScript client with a Dream server written in OCaml.

You can also try Dream online in its playground.

With that intro out of the way, Dream offers:

Concerning the language, OCaml and Reason have largely the same type system as ReScript. The biggest difference is that Dream is based on the opam native library ecosystem. However, Dream doesn’t recommend the opam client program — all the examples show how to use esy, an npm-like alternative.

Dream is secure by default. The obvious ways to use security-sensitive features, such as cookies, are automatically secure. The docs highlight wherever security still depends on the Dream app. Dream has selected a modern cipher, and supports key rotation.

Dream is designed for full internationalization. It has a centralized error handler that captures even lower-level HTTP errors, so that you can decorate them with your app’s internationalized error template. Dream’s URL encoders favor internationalized (UTF-8) URIs, and Dream’s router accepts them.

A Dream app can be run with or without a proxy, standalone or embedded in larger binaries, and used with external assets or with assets compiled in.


Dream has…

In particular, see

An especially twisted example is running GraphiQL in the playground:


Dream is in an alpha state. It is actually quite stable, but there will likely be API tweaks, as well as the inevitable bugs that can only be discovered in “battle testing.” The plan is to remain in alpha for about six months to work most of these out, and then announce the 1.0.0 release.

During the six months, I want to address:

  1. Flow control for very large responses, and getting the “advanced” part of the I/O API to be as close to zero-copy and non-allocating as possible.
  2. Remaining (optional) security enhancements, such as a default content security policy.
  3. Remaining session improvements, such as re-keying.
  4. Friction around native handling of JSON, database access, etc. This is not properly part of or caused by Dream, but it should be addressed for a better native Web development experience.
  5. Multicore and effects support.

That’s all. Happy Web programming!