package dream
Install
Dune Dependency
Authors
Maintainers
Sources
sha256=c8d988568fbbeffb151abdb4d6b903fbd3897842d3eb9b2c28fb350f0f02bbd4
md5=b8ad7f3e30f3e88e5451d92e42b49ce4
Description
Dream is a feature-complete Web framework with a simple programming model and no boilerplate. It provides only two data types, request and response.
Almost everything else is either a built-in OCaml type, or an abbreviation for a bare function. For example, a Web app, known in Dream as a handler, is just an ordinary function from requests to responses. And a middleware is then just a function from handlers to handlers.
Within this model, Dream adds:
- Session management with pluggable back ends.
- A fully composable router.
- Support for HTTP/1.1, HTTP/2, and HTTPS.
- WebSockets.
- GraphQL, including subscriptions and a built-in GraphiQL editor.
- SQL connection pool helpers.
- Server-side HTML templates.
- Automatic secure handling of cookies and forms.
- Unified, internationalization-friendly error handling.
- A neat log, and OCaml runtime configuration.
- Helpers for Web formats, such as Base64url, and a modern cipher.
Because of the simple programming model, everything is optional and composable. It is trivailly possible to strip Dream down to just a bare driver of the various HTTP protocols.
Dream is presented as a single module, whose API is documented on one page. In addition, Dream comes with a large number of examples. Security topics are introduced throughout, wherever they are applicable.
README
README.md
Dream
Easy-to-use, feature-complete Web framework without boilerplate.
Dream is one flat module in one package, documented on one page, but with many examples. It offers:
WebSockets and GraphQL for your modern Web apps.
HTML templates with embedded OCaml or Reason — use existing skills!
Easy HTTPS and HTTP/2 support — Dream runs without a proxy.
Helpers for secure cookies and CSRF-safe forms.
Full-stack ML with clients by Melange, ReScript, or js_of_ocaml.
...all without sacrificing ease of use — Dream has:
A simple programming model — Web apps are just functions!
Composable middleware and routes.
Unified, internationalization-friendly error handling.
Cryptography helpers, key rotation, and a chosen cipher.
A neat logger, and attention to configuring the OCaml runtime nicely.
Every part of the API is arranged to be easy to understand, use, and remember. Dream sticks to base OCaml types like string
and list
, introducing only a few types of its own — and some of those are just abbreviations for bare functions!
The neat interface is not a limitation. Everything is still configurable by a large number of optional arguments. Where necessary, Dream exposes the lower-level machinery that it is composed from. For example, the basic body and WebSocket readers return strings, but you can also do zero-copy streaming.
You can even run Dream as a quite bare abstraction over its underlying set of HTTP libraries, where it acts only as minimal glue code between their slightly different interfaces, and takes care of horridness like ALPN.
And, even though Dream is presented as one package for ordinary usage, it is internally factored into several sub-libraries, according to the different dependencies of each, for fast porting to different environments.
Getting started
Dream is not yet announced or released! Before release, Dream will get a quick-start script, and some other help for getting started quickly. However, if you want to try Dream now, you can add:
"dependencies": {
"@opam/dream": "aantron/dream:dream.opam"
}
to your esy.json
. See example w-esy
for a minimal project.
Alternatively, if you are using opam:
git clone https://github.com/aantron/dream.git --recursive
cd dream
opam install .
Note: the clone must be --recursive
, because Dream vendors several packages as git submodules. Also, if you have gluten
, httpaf
, h2
, or websocketaf
, or their gluten-*
, etc., subpackages independently installed in your switch, you may have to remove them with opam remove
to avoid conflicts. However, they should not be pulled into a basic build of Dream and most programs that use it.
After that, go to one of the examples, such as 1-hello
, and try building it:
cd example/1-hello
dune exec --root . ./hello.exe
If you prefer Reason syntax, try example r-hello
instead.
You should be able to copy the example out to a completely separate directory, if you didn't use a local _opam
switch scoped to Dream's clone directory. If you did, you can pin Dream to your clone in a different opam switch with
opam pin add dream /path/to/your/clone
Documentation
Tutorial — Threads together the first several examples of Dream, touching all the basic topics, including security. See the full list and start wherever you like, or begin at
1-hello
, the Dream version of Hello, world!Reason syntax — Several of the examples are written in Reason. See
r-hello
.Full-stack — see skeleton projects
r-fullstack-melange
,w-fullstack-rescript
, andw-fullstack-jsoo
.Examples — These cover various HTTP scenarios.
Contact
Apart from the issues, good places to discuss Dream are...
The OCaml Discuss forum.
Highlight @antron
to poke @aantron specifically.
Contributing
Dream uses several submodules, so be sure to clone with
git clone https://github.com/aantron/dream.git --recursive
Acknowledgements
Dream is based on work by the authors and contributors of its many dependencies and their transitive dependencies. There are, however, several influences that cannot be discovered directly:
Templates are inspired by ECaml from Alexander Markov and Embedded OCaml Templates from Emile Trotignon.
Dream's handler and middleware types are simplified from Opium by Rudi Grinberg and contributors.
The lower-level HTTP and WebSocket servers are vendored copies of Antonio Nuno Monteiro's forks and original works, with credit also due to their contributors, and Spiros Eliopoulos in particular, as the original author of two of the projects.
The API docs are instantiated by Soupault from Daniil Baturin.
The name was inspired by Morph from Ulrik Strid, which was itself partially inspired by Opium.
Raphael Rafatpanah and El-Hassan Wanas provided important early feedback.
Roadmap
[x] GraphQL subscriptions.
[ ] Optimizations: router, logger, microparsers (form data, etc.), fully zero-allocation streaming.
[ ] WebSocket and stream backpressure.
[ ] HTTP3/QUIC.
[ ] Review JSON.
[ ] Review SQL prepared statements.
[ ] Switch to AEAD_AES_256_GCM_SIV for the cipher.
[ ] WebSocket streaming (frames).
[ ] Factor out internal sub-libraries to port Dream to MirageOS, etc.
[ ] Token rotation-based session management.
[ ] Lots of optionals for decoupling defaults, e.g. forms without CSRF checking, SQL sessions with a different database.
[x] Bundle GraphiQL into a single HTML file that does not access any external CDN.
[ ] Maybe a logo.
[ ] i18n helper, URL templates.
[ ] Auth library.
[ ] Maybe REST helpers.
[ ] Maybe Async support.
[ ] Multicore.
[ ] Effects.
[ ] Proxy headers support.
[ ] Introspection.
[ ] Dependency reduction, especially system dependencies.
[ ] And lots, lots more.
Dependencies (32)
- result
- psq
- faraday-lwt-unix
-
faraday
>= "0.6.1"
-
digestif
>= "0.7.2"
-
bigstringaf
>= "0.5.0"
-
angstrom
>= "0.14.0"
- yojson
-
uri
>= "4.0.0"
-
opam-installer
build
-
ocaml
>= "4.08.0" & < "5.0"
-
multipart-form-data
>= "0.3.0" & < "0.4.0"
-
mirage-crypto-rng
>= "0.8.0" & < "0.11.0"
-
mirage-crypto
>= "0.8.1" & < "1.0.0"
- magic-mime
-
logs
>= "0.5.0"
-
ssl
>= "0.5.8"
- lwt_ssl
-
lwt_ppx
>= "1.2.2"
- lwt
- hmap
- graphql-lwt
- graphql_parser
-
fmt
>= "0.8.7"
-
dune
>= "2.7.0"
- cstruct
- conf-libev
-
caqti
>= "1.4.0" & < "2.0.0~"
- caqti-lwt
- bigarray-compat
-
base64
>= "3.1.0"
- base-unix
Dev Dependencies (3)
-
ppx_expect
with-test
-
bisect_ppx
dev & >= "2.5.0"
-
alcotest
with-test
Used by (8)
-
dream-cli
< "0.2.0"
-
dream-encoding
< "0.2.0"
-
dream-livereload
< "0.2.0"
- graphql_jsoo_client
- hyper
- ppx_dream_eml
- u2f
- universal-portal
Conflicts (5)
-
tls
>= "0.15.0"
- websocketaf
- h2
- httpaf
- gluten