RFC: The future of Bs-Express


#21

Just a bit busy at work, @idkjs, but can draw up a diagram later on.


#22

What is your current throughput in RPS? I’m assuming that you’re using horizontal scaling with some sort of containerization scheme?


#23

ReasonML seems an obvious choice for a tierless web framework like Ocsigen or Ur/Web, since it already has a story for the Javascript tier. What I find nice with Ur/Web is that it is very opinionated, it makes learning easier (I am not saying it is easy!). There might be some ideas worth stealing. The paper I found most readable, is: http://adam.chlipala.net/papers/UrWebPOPL15/


#24

Will give the paper a read. Thanks @th3rac25 :slight_smile:


#25

@th3rac25 Just read the paper, Ur/Web’s programming model seems incredibly powerful. However I believe such a model would be a poor target for a sucessor to bs-express for a few reasons:

  1. It feels significantly more complicated to implement and I think getting a decent web programming environment available now in bucklescript/reason would be more valuable to community than one in a year. I feel that starting small instead of getting over ambitious is the responsible and probably more rewarding thing to do
  2. Here my own biases come to the fore, my career thus far has largely consisted on implementing APIs for consumption by multiple platforms. Ur/Web’s model does not really make provisions for this use case. A more generalized computational model would be preferred. Unison is doing some interesting work here. An actor model which could also run on the browser would also be an approach to tierless computation but is risky in that it is a largely unexplored design space.
  3. Approachability: a few people have expressed the view in this thread that it is important that a web framework be approachable to those coming from other languages and web frameworks. Ur/Web is quite a different way of thinking and thus would fail in that goal.

That being said, there are probably a few ideas that could be incorporated into a new framework as you’re suggesting. Intriguing is their support for atomic transactions. This is something important that isn’t really baked into current web frameworks but probably should be. In a sense their treatment of transactions sounds a little like a less general (and more automated) form of a saga.


#26

Thanks everyone for the comments.

In general it seems like the general consensus it that an important quality to factor in here is familiarity:

The framework needs to feel safe and familiar to users coming from other frameworks, but differences can be tolerated if they can be justified and are adequately explained.

Increased typesafety should also be important to the design, but should not necessarily come at the cost of reduced usability. This may require some form of compiler extension.

I still feel that suave.io is still an admirable model to crib from, but I believe I might have found a general design which could compose as well as suave while still supporting other “flavours” of building APIs. The main difference is that express middleware has the general signature of (request, response) => unit.

Changing this to:

module HttpContext = {
     type t = { request, response };    
};
type result = 
    | Handled(HttpContext.t)
    | Unhandled;
type t = (HttpContext.t) => Promise.t(result);

Allows you to perform monadic operations on the ctx object, forces middleware to return a result (middleware also now becomes just function composition) and could support a familiar API to that of express.

Adding support for different compilation targets would be a matter of mapping from the request record and mapping to the response record, along with perhaps offering cross-platform niceties such as an isomorphic JSON encoding/decoding api.


Reconstruct Project Log
#27

Not sure if this was the case when these conversations were active but I was looking through this thread today and looking at the links you all provided. It looks like http://ocsigen.org/ has the option to view their docs and tutorials in Reason or regular OCaml. You were talking about porting and maybe they have already begun that process.