Roadmap

Web Roadmap

Lists needed improvements to Dream and the OCaml ecosystem for OCaml to be practically useful for Web programming.

Authentication

Today's websites use password login, social login, and two-factor authentication.

• ❌ Password login.

  • 👎 Currently, people have to roll their own solutions.
  • ✔️ Argon2 is the recommended hash function for password storage these days. ocaml-argon2 binds to its C implementation.
    • ❌ ocaml-argon2 recently failed to build on Mac, required porting, and just needs a look.
  • ❌ We need all the helpers around Argon2, such as the actual login flow, registration, recovery, etc.

• ❌ Social login.

  • 👎 Is basically not ever done by people in OCaml.
  • ✔️ ocaml-oidc implements OpenID Connect, used by most social logins, such as Gmail.
    • ❌ We need to test actually connecting to the various social login providers and work out all the quirks.
  • ❌ Providers such as GitHub implement a bare OAuth2 login process. We need to factor OAuth2 out of ocaml-oidc.
    • See Map of OAuth 2.0 Specs.
    • Wikipedia List of OAuth providers.
  • ❌ Facebook has its own Facebook Connect. We need to implement this.

• ❌ Two-factor authentication.

  • 👎 Does not exist in OCaml in the form most commonly found on the Web.
    • ✔️ u2f implements U2F, which requires specialized devices.
  • ✔️ qrc implements QR code generation.
  • ❌ Implement TOTP, the most common 2FA method besides SMS.
    • Appears to be done in https://github.com/marcoonroad/twostep. Evaluate it.
  • ❌ Make sure the implementation has an API that matches an expected API for SMS and U2F 2FA.
  • ❌ Integrate TOTP with QR code generation, as commonly used on the Web.

• Other auth methods.

  • WebAuthn?

• References

  • Buffalo Auth Generator

HTTPS

• ✔️ HTTPS itself is well-supported in OCaml.
• ✔️ Practical use of HTTPS by small-to-medium groups requires Let's Encrypt, implemented by ocaml-letsencrypt.
• ❌ ocaml-letencrypt needs to be adapted to Dream and made easy to use. This should use the ALPN challenge method.

JSON and data handling

• 👎 OCaml is really awkward at handling "just data," unlike Python and JS.
  • ✔️ Yojson does this to some extent, but has verbose combinators, and the types don't match JSON.
  • ✔️ ezjsonm's types exactly match JSON, but it is based on a slow parser.
  • ✔️ Consider jsonaf.
• ❌ Study existing solutions in OCaml, F#, ReScript, Rust, Go.
• ❌ Create a library with types that match JSON exactly, has a fast parser, and short combinators or custom operators.
• ❌ Port one of the Deriving PPXs to it.
• ❌ What should be done for form data?
• ❌ Dynamically tagged data is very nice for automatically putting into SQL prepared statements. Look into this.
• ❌ Consider implementing JSON5 as an option.

SQL access

• ✔️ Caqti is a common interface for accessing SQLite, PostgreSQL, and MariaDB.
• ❌ There is no ready migration option. People on Discord are using gomigrate.
  • ✔️ Antonio has a gist with some migration code.
  • ✔️ Look at ocoi.
  • Look at omigrate
• ❌ Caqti does not report detailed errors from database drivers.
• ❌ Caqti appears to lack a transaction wrapper.
• ❌ Caqti does not have a published manual, or neat API. It is necessary to convoluted functors spread across several .mli files.
• ❌ We need to find a link to how to write portable SQL (for those who want to do that).
• ❌ Direct use of Caqti involves a lot of boilerplate. Is there a way to reduce that without PPX?
• ❌ If a PPX can help with removing some lingering boilerplate, consider a non-intrustive optional PPX.
  • ✔️ There is ppx_rapper — study it.
• ❌ The Caqti Dream integration creates its own connection pool. Allow taking a connection pool created by the user.
• ❌ Study PG'OCaml and F#'s Npgsql.
• ❌ Consider some kind of schema checker to run at startup, perhaps part of the migration library.
• ❌ Consider Ecto.
  • https://hexdocs.pm/ecto/Ecto.Changeset.html
  • https://medium.com/flatiron-labs/how-to-use-ecto-changeset-a745633eefda
• ❌ What does Caqti 1.7.0 offer?

Effects port

• ❌ What will Dream look like with effects in the language?

Router

• ❌ A lower combinator layer allowing partial validation during routing, perhaps even allowing composing handlers using a monad. See #122.
• ❌ Optimizations, such as a trie. Possible solution: art
• ❌ Generate JSON schema from handlers/routes.

Regular expressions

• ❌ A cache to skip an explicit compilation step.
• ❌ Unicode support.
• ❌ Pick a favorite syntax (PCRE2).

Testing

• ❌ End-to-end testing.
• ❌ See React Testing Library.
• ❌ WebSocket testing.

Caching & CDN

• ❌ ETags.
• ❌ Aid for Cache-control, asset hashing.

WebAssembly

Compilation to JS

• ❌ There are js_of_ocaml, Rescript, and Melange.

Upstreaming

• ❌ All the vendored dependencies need to be upstreamed and/or released.

Internationalization

Cryptography

Deployment

Protocols

Email

#138

• ✔️ Library for sending emails via SMTP letters
• ✔️ Library for composing email mrmime
• ✔️ Library for validating email address (don't even try to do it with regex, it's really complex): emile
• ❌ Special handlers for common providers like Mailgun or Amazon SES, sending emails via http protocol.
  • ❌ API access to email-sending services will benefit greatly from Dream having a Dream-friendly client library.
• ❌ Message queue back ends:
  • ❌ In-memory.
  • ❌ Local broker-less persistent.
  • ❌ RabbitMQ (can already be accessed by amqp-client).
  • ❌ Amazon SQS (aws-sqs).
  • ❌ Optionally Redis.

Templating

• ❌ Improved syntax highlighting of eml (being worked on at Tarides).
• ❌ Full IntelliSense support in eml.

Logging

• ❌ Experiment with log-anything. https://discuss.ocaml.org/t/overview-of-libraries-for-showing-ocaml-values/12076
• ❌ Look at ezlogs.

I/O rework

• ✔️ Very clearly figure out, for both streaming bodies and WebSockets, exactly where allocations are done on each write, where buffering occurs, etc.
• ✔️ Exactly how and to whom are errors reported?
• ✔️ Implement proper flow control to avoid filling internal buffers server-side or client-side.
• ❌ Improve async detection of closed WebSockets.