RFC: The future of Bs-Express


#8

I’d go the route of making it feel like express while fixing up some of it’s shortcomings. If it’s any guide, ReasonReact is a bit of a departure from what people are used to with JS React (reducerComponent, etc.). I think devs just need to know that there is energy/activity in a module, and that it’s familiar enough.

As an express user myself starting to look hard at Reason, you’d connect with me if it was just as easy to set up an app and register routes in a similar way. I’d more than tolerate differences if the design improvements were clearly explained. In fact, it would just make a stronger case for why I’d want to build an app wth Reason.


#9

I’m super impressed by rust’s rocket web framework – I’d love to come up with something as usable & fast & safe out of the box!


#10

@jaredly Rocket looks very cool.
Q: What is the thing about rocket that impressed you the most? The typesafe routing engine?


#11

For what it worth, we are using ocaml as server side language at very big scale at Ahrefs, including http server, and it works pretty well. So I don’t think you will be blocked unless you are Facebook or Google.


#12

@Khady Out of interest. What are you using as your webserver at Ahrefs currently?


#13

We are using https://github.com/ahrefs/devkit/blob/master/httpev.ml
It is probably too low level for what you would like to do. But I think it’s a good example that “simple” stuff can reasonably scale up.


#14

Yeah – I love that it feels as easy to use & get started with as express (maybe easier?) but it’s much safer


#15

One thing that might would help in applying ocaml tested stuff would be to maybe roadmap how one might use @Khady’s suggestion in a reasonml project. What would it take to do that? Doesnt seem to hard. Maybe build it with esy? I need to see that work flow one time. Would be useful in all kinds of other projects as well and would accelerate the proliferation of ocaml work into reasom land.


#16

@idkjs: Would you mind explaining a little more about what using @Khady’s suggestion means? I’m not quite clear as to what you’re suggesting.


#17

@ncthbrt i guess I mean, what would a quick port look like. ahrefs doesnt seem to be using it in public reason project yet though they are writing bindings so they might be.


#18

@idkjs Looking at the code, feels like it would be something that would be quite difficult to port. Which is why I would rather attempt to create an abstraction layer which could be easily ported to different backends.


#19

i love it when you talk that way. I dont know what an abstraction layer is but I can guess what you mean. So what would an ‘abstraction layer’ look like then on that project?


#20

I agree with having a familiar interface for newcomers to ReasonML.

I also think that there is probably a lot of room for improvement, so the ideal would be to do both IMO.


#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.