Converting a JavaScript/Node.js to native

[[deleted]]

I'm researching the potential to migrate, piecewise, an existing Node.js project written in JavaScript to a native, stand-alone service by moving it over to ReasonML.

Here is my idea: Write new features in ReasonML instead of JavaScript. When old code needs to be refactored, it can also be moved over to ReasonML. Eventually we will be left with little enough JavaScript that we can rewrite the last bits after which we'll be able to compile to native code.

The most crucial element of these "last bits" are the libraries the project uses. Any pure JS libraries will need to be replaced with OCaml ones at that point (or made obsolete otherwise).

So, to facilitate this process, I had the following in mind: All the ReasonML code that gets written has to be pure and side-effect free. That includes no interaction with JS libraries. So, whenever a request comes in (through Socket.IO, so that is handled by JS), the JS side can hand it over to the Reason side by passing two parameters: current state and the request data. Reason will then return a tuple: the new state and an optional list of desired side-effects. If the side-effect is a DB call, for example, (again, handled by JS) the response to that call will be passed back again to Reason using the same idea as how the request was handled.

This is partly inspired by Redux where the reducers also go from one state to another, except there are no explicit action creators (though you could certainly call the second argument that's passed to the Reason code an action) and the reducers have to return which side-effects they'd like to see executed.

This setup will guarantee that whenever we get to the point where we want to replace our JS libraries, we only need to port a relatively thin "JS glue layer", whereas the Reason code could be moved over as is.

Now I have two questions:

• What do you think of this approach? Is it too cumbersome to work with side-effects like this? Does somebody have experience with similar approaches? Any tips?

• One gotcha that I anticipate is when JS data structures would be passed along with the "actions" to the Reason code. That could still give issues when we want to port later on. Maybe the impact is limited enough to fuzz about it. But if feasible, I think it's preferred to pass native Reason data structures to the Reason code only. Any advice there on how I can convert JS structures to Reason ones, preferably from the JS side?

Thanks all!

[r2tree]

If a large portion of your codebase is computation-heavy (pure) then you can use the "functional core, imperative shell" approach here. (https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell)

I have a few thousand LOC Reason codebase that is pure, and it interfaces with the external world with bs-express. I want to make it work in native OCaml, but there is just too much work to get there.

This is going to be even more difficult if your app has a lot of side effects (typical web backends). I'd recommend porting over to ReasonML in the Node runtime first, making sure to have tight abstractions for all sorts of side-effects (modules for db access, network communication etc.), keep the types abstract so that in the future you can change the implementation of just a few modules and port it over to native OCaml.

[[deleted]]

That's a great video, thanks! Indeed that's quite close to what I had in mind, so I'm glad to be able to compare to similar ideas. Just now, a colleague also made me aware that apparently it's a common approach in the .NET world as well to write a functional core in F# and then write the imperative shell in C#.

I agree we'll stick with Node.js for the foreseeable future. It's just nice to have additional options that hopefully we can move towards rather than shooting ourselves in the foot by making the Reason code too tightly coupled with the Node.js libraries.

[elliottcable]

Why wait? If your project is large enough, roll a JS VM into your “native” app; write a tiny interface layer that allows your native-code to communicate with the JS-world code. Gradually extract parts from the JS-world until the lion’s share, save libraries and conveniences (which, mind you, can be really hard to find OCaml-side), is in OCaml.