
Deploying a ReasonML React app with Docker - anirudhmurali
https://blog.hasura.io/how-i-deployed-a-reasonml-react-app-with-docker-29dd2ce6de82
======
Kwastie
With pure Reason (No JS bindings) it should be possible to skip Node /
Bucklescript on the server and compile straight to binary.

This should be possible with something like bsb-native
([https://github.com/bsansouci/bsb-native](https://github.com/bsansouci/bsb-
native))

I haven't tried this because I don't have a pure Reason project

~~~
Drup
> This should be possible with something like bsb-native
> ([https://github.com/bsansouci/bsb-native](https://github.com/bsansouci/bsb-
> native))

Why not just use the real OCaml/Reason compiler ... ?

~~~
jordwalke
Reason is supported on every major version of the native OCaml compiler
(currently versions 4.02.3 up to 4.06).

~~~
Drup
I know, hence my question! Why go through bs (which is locked to an old
version of OCaml) to distribute executables, when you can use the normal
compiler and enjoy the latest improvements?

~~~
jordwalke
I don’t mean to ignore your observation - it is valid. Bsb is a build system
that works with a specific form of packages. What you suggest could work too.
The only (small?) challenge is that people have bsb JS projects, and they
aren’t configured for jbuilder/Dune etc. Because of JavaScript’s immense
popularity, the largest number of people will start with whatever build tools
integrate well with the JavaScript ecosystem and work from there. This plays
out quite predictably. Just as an example, the most important thing to web
developers is that each Reason input file becomes a commonJS (or es6) module.
That allows integrating your Reason React app with existing web apps easily.
So since people start with whatever tools integrate well with the JS
ecosystem, they then reach for the easiest tool available to adopt native
compilation.

------
anirudhmurali
Hi HN, here's the Dockerfile:
[https://gist.github.com/anirudhmurali/fee0181957bd9bcc9d5846...](https://gist.github.com/anirudhmurali/fee0181957bd9bcc9d5846a1045923aa)

~~~
vog
Thanks for the link, but why isn't it part of the article?

~~~
anirudhmurali
It is, but as in image form. I'll link this there.

------
theptip
One annoying thing you'll need to add before this is production-ready is
configurable environment config, so that you can deploy the same container for
your staging vs. production version of the app.

I use a `patch.sh` as the ENTRYPOINT, which says something like

    
    
      echo $API_URL >> /usr/local/nginx/html/config.js
      echo $OTHER_CONFIG > /usr/local/nginx/html/config.js
      ...
      exec nginx
    

Though there may be other ways to achieve this as well.

------
azr79
What can ReasonML do that TypeScript can't?

~~~
tango12
Prevent null bugs.

Typescript values can be null. A pure reason program will never have null
bugs.

[https://reasonml.github.io/docs/en/type.html](https://reasonml.github.io/docs/en/type.html)

~~~
billwashere
In case anyone didn't know, since Typescript 2 there is a compiler option to
enable strict null checking.

[https://blog.mariusschulz.com/2016/09/27/typescript-2-0-non-...](https://blog.mariusschulz.com/2016/09/27/typescript-2-0-non-
nullable-types)

~~~
realharo
Only since 2.7 (very recently) can you actually enforce initialization of
class properties: [https://www.typescriptlang.org/docs/handbook/release-
notes/t...](https://www.typescriptlang.org/docs/handbook/release-
notes/typescript-2-7.html#strict-class-initialization)

~~~
Rapzid
I was just wondering about this today; thx for the link! Not sure how I missed
it.

~~~
realharo
Unfortunately, libraries such as React have their own component lifecycle
management, which doesn't play well with this
([https://reactjs.org/blog/2015/12/18/react-components-
element...](https://reactjs.org/blog/2015/12/18/react-components-elements-and-
instances.html)).

This is also a bit of a pain point on Android with Java @NonNull annotations
or when using Kotlin.

~~~
Rapzid
Yeah... It would honestly be cool to have a TypeScript native React(as crazy
as that sounds). There are some really great projects out there killing it
like Nest, MobX, TypeORM, etc.. The React typings have come a long way though.

I do quite a bit of TypeScript for the server though(less context switching
and is mostly GoodEnough™) so still handy.

~~~
azr79
Angular plays very well with typescript, because the entire framework is
written in it, more than that, Angular Team is working with TypeScript Team to
help make TS better, and vice-versa.

------
jmcomets
Unrelated, but does anyone know what font/colorscheme are used in the
screenshots? I find it very slick for code presentation.

~~~
anirudhmurali
Haha, it's here: [https://carbon.now.sh/](https://carbon.now.sh/)

------
tuananh
since we use bs to compile, shouldn't we use a node image to compile and then
copy them over to runtime image later?

~~~
alberteinstein
True, optimising with a multi-stage build after `yarn build` should do it.

