I’m interested in pros and cons of Eliom web framework to understand if it is well suitable for my idea of corporate blogging/content marketing SaaS. What successful SaaS projects made with Eliom do you know? Do you know any issues related to Eliom (or why many people prefer, for example, Dream)? Also I’m interested if there are any popular iOS apps made with Eliom?
There is a huge app written with Eliom: The Be Sport social network. It was written by a team of 2 to 15 developers over the past 7 years (including Jerôme Vouillon and myself, who are the creators of Ocsigen). You can have a look here: Be Sport and download the mobile apps on Google Play store or Apple app store.
Be Sport is 100% written in OCaml with Ocsigen, as multi-tier and multi-platform Eliom app. There is only one code base for the server part and the Web, Android and iOS clients. The mobile apps are running in in webviews, using cordova (or may be soon capacitor). Pages are generated on server side (for example for indexing by search engines, or if it is the first page you load) or on the client (in client apps, or if you change page in the Web app). This is the most distinguishing feature of Eliom w.r.t. any other Web framework (in any programming language).
Another advantage of multi-tier programming is that Web APIs are generated automatically by Eliom. More generally communication between server and client are transparent: as you have only one program, you can call server side OCaml functions from your client side OCaml program. Communication from server to clients (notifications) is also handle by Eliom. Of course you can define your own APIs if you need to interact with third party apps.
When you master them, these features save a lot of time and are probably what made possible to implement a very complete Facebook-like social network with such a small team. Of course if you don’t need all this, you can use Eliom for more traditional Web programming and it be very similar to what you can do with Dream.
Server parts of your app are compiled to OCaml module, loaded dynamically into Ocsigen Server (which is now using cohttp as HTTP lib) through its configuration file. There is currently no way to write standalone apps without this dynlink, but it is in our todo list.
Other features of Ocsigen:
- Ocsigen has a very powerful, yet simple, service identification mechanism to program server-side page generation,
- It implements continuation-based Web programming (through dynamic creation of specialized services),
- It includes a powerful session mechanism (you can for example decide if session data corresponds to a browser, or to a tab, or to all browser and mobile apps for a same user)
- HTML pages are statically type-checked with Tyxml
- Ocsigen allows to insert reactive page elements, using Functional Reactive Programming
- Several native libraries are available: A set of interface widgets designed to be compatible with multi-tier programming, an internationalisation library, user management, etc.
As Ocsigen innovates in many fields, you have some learning to do to become fully operational (lwt, reactive programming, multi-tier programming, html typing with polymorphic variants and phantom types, etc.). Everything is summarized on the first chapter of the programming manual.
Ocsigen is now mature. It can work without a lot of maintenance. However the project is currently not funded (no developer is currently paid to work on Ocsigen).
Do not hesitate to contact me if you need to build a team for your project. I may have some names.
Thank your for such a detailed response. I have few questions about Eliom:
- Does it support SOA/microservice architectures or only monoliths?
- Does it support “backends for frontents” approach?
We did not work on microservices which means that if you want to implement some microservices, you can, but I guess it will be very similar to what you can do with other frameworks.
The BFF patterns does not make a lot of sense in our vision, as you have only one frontend and build the frontend and backend together as a single app. Our multitier approach removes most the problems of multi-frontend apps. When programming with Eliom, you don’t have separate teams for each frontend and backend. One developer is responsible for its own feature from the db to the interface and for all patforms, which reduces a lot the need of communication between teams, and the risk of API problems.
However if you want several backends, for example to interact with external apps, of course you can do that. Eliom does reduce the possibilities w.r.t. more traditional Web programming.
Thank you a lot! I have one more question. Is it possible to run Eliom app on MirageOS? I want to make a bet on unikernels and I want to save money on hosting/hardware because my budget is very limited and because I really like the idea of unikernels.
I don’t think anyone made it work on MirageOS. It would probably require some changes in Ocsigen Server to adapt the system calls (file access?), but it should not be too difficult as we are using lwt and cohttp which work well on mirageOS).
I’m not a MirageOS expert, though.
I’ve made a cjkv info app with eliom, the old demo version is here(most of its functions are turned off and hidden): https://cjkv.smaji.org/
It collects variation, source info, input method code of characters among China, Japan, Korea, Vietnam, Hongkong, Taiwan, ethnic minorities and ancient books. e.g.
Overall, eliom framework is fantastic. All the links are eliom_service, its parameters and itself are typed. Session manage is powerful and flexible. Components are reactive with each other, seamlessly between server and client. An app written in eliom is intrinsically an SSR SPA, an integral whole.
Writing an eliom app, all I want to say is: damn! it’s too good!
- dune support
- merlin, ocaml-language-server
Your project is built by a manually managed Makefile and merln/lsp support is broken when you mix client/server code together in the same folder.
You only get these supports when you write standalone server and client separately.
But these flaws can be overcome. I wrote a custom code translator, which generates server code and client code from an eliom file into separate folders and make them still work together seamlessly. And in this case, I don’t need a Makefile, dune and ocaml-lsp works as normal projects.
It’s good. But it updates infrequently and doesn’t keep pace with other libraries closely. Because eliom depends on it and its dependence constraint sometimes requires old libraries, better create a separate opam switch when working with an eliom project.
In fact, it’s not a wart of eliom. It’s lwt Memory leak under heavy load · Issue #545 · mirage/ocaml-cohttp · GitHub
That’s why I stop working on the old demo and now is rewriting it again with another tec stack.
If only eliom depended on lwt/async optionally and came with an official code translator to overcome the dune/lsp integration issue.