Anyone using ReScript for servers or full stack apps right now?

1

Is anyone using rescript for node servers right now? I do see some express bindings but seems like the primary use case is on the client side, wanted to see if anyone was replacing their typescript servers with rescript in a production capacity?

I think having a solid isomorphic option for rescript would be a big selling point for me. I do know there is a nextjs template, however sometimes you need a bit more than this for an application ie. nestjs’ typescript abstraction on top of express / fastify.

2

Hello, im actually building a rescript server with HapiJS and RxJS.
I am finishing my server actually with all CI/CD stuff, i will do a REX on the forum when it’s done :smiley:

As a teaser, i can say that the DX is better than TS/JS for server related stuff. In order to enjoy the paradigm, i suggest, for those who are new to FP, to read Domain Modeling Made Functional

5 Likes
3

I’m actually using ReScript for a small but highly visible (company internal) Slackbot, using the Express binding created by @bloodyowl : https://github.com/bloodyowl/rescript-express

Development was fast and smooth, and it’s working well, but you need a little bit of experience to be able to have good dev velocity. As long as there is a ReScript champion in the team, it should be doable.

5 Likes
4

I’m using ReScript full-stack for a couple of projects. Yes, it’s totally possible and feels fine.

Here’s a blog post where I’ve shared some experience: https://fullsteak.dev/posts/fullstack-rescript-architecture-overview

5 Likes
5

We’re using multiple rescript-based backends in production using custom express bindings, it works extremely well!

3 Likes
6

Thank you for your great article! Personally I like moving more logic from handlers to services using ports and adapters aproach from the
hexagonal architecture. But I write very-very thick frontends, haven’t tried it with a server backend yet.
Talking about rescript on the backend, I worry that it will be difficult without async await I’m so used to. Is there a problem with this or I worry for nothing?

1 Like
7

At the times of ReasonML I used https://github.com/reasonml-labs/bs-let for async calls and now in ReScript I have to shift down to Promise.then chains. It’s more clunky and requires more code split/organization/planning but nevertheless doable.

I’m very excited about a technique presented recently by @kevinbarabash (Alternate async/await proposal). I haven’t got a chance to try it in practice, but probably that’s a nice way to go with async in ReScript avoiding promise and callback nesting hell.

1 Like
8

Fullstack serverless if that counts. Elm on the front deployed to AWS Amplify, ReScript on the back deployed to AWS AppSync. Elm talks to ReScript Lambdas via GraphQL. They all share the same GraphQL so the types are so close, it’s… scary. Being able to confidently blame, but more importantly, help other services when they break our stuff deterministically is an amazing feeling. How can you not be in love?

GraphQL:

enum LoanProductType {
    DeferredInterest
    FixedRate
    NoInterest
}

type LoanProduct {
    rate: String!
    termLength: Int!
    pricingProductType: LoanProductType!
}

Elm:

type LoanProductType
    = DeferredInterest
    | FixedRate
    | NoInterest
    
type alias LoanProduct =
    { rate: String
    , termLength: Int
    , pricingProductType: LoanProductType
    }

ReScript:

type loanProductType
    = DeferredInterest
    | FixedRate
    | NoInterest

type loanProduct = {
    rate: string,
    termLength: int,
    pricingProductType: loanProductType
}
8 Likes
9

This sounds cool (and strange!). What were the runners up behind Node.js for the backend?

10

This is a good question and I probably can go long on this one. So the vast majority of my team is very familiar with node and typescript, however, there are the obvious issues with typescript. The real appeal to this style of programming for me came from elm, I loved the idea of if it compiles, it runs, and found that to be quite true. The error messages not being this giant blob of crap was also pretty incredible. The main problem is, we are still writing typescript on the server, so can we get those guarantees on the server?

My considerations were all over the place, F#, Haskell, OCaml, Rust, Go. Basically looking to solve the whole terrible error message drag of typescript, but also have more security. The issue is now we lose isomorphism and in some cases simplicity. I run an agency so speed of development is pretty equal in importance to correctness. I also have to be able to sell my customers on the idea. F# and Go are pretty easy to sell in to enterprises at this point I think. Haskell and OCaml would be a tougher sell outside of a finance customer. All this being said, the other reason I like node is because of all the integrations with different software solutions. Lots of my customers already are integrated with 5 - 10 SaaS platforms or more and almost all of them have docs and drivers for node, ruby, python, and now sometimes go. So the appeal to rescript is totally there for the server because I get isomorphism, exceptional type safety and correctness, the ability to use the node packages from all these other services a customer may use, and way better error messaging.

The part that gives me pause was there not being a great first class server framework. It seemed silly to use rescript on the front end (since it has first class react support) and then nest on the back end, so my hope was there was some type of first class support coming or that someone had build for express or fastify etc. It seems like right now, it still might be too soon to go all in on a production project for someone outside of the front end. However the answers in this thread show me that it might be ready ready quite soon.

I don’t know if anyone else is really wrestling with this decision the same way I am though. I really like typescript, but I just feel like there is something better out there that gets me to the promised land where we can have correctness, development speed and productivity, as well as access to this amazing ecosystem.

3 Likes
11

I started writing a service this weekend, and I just create custom bindings for fastify. It’s not that difficult even for a newbe like me.
Although I haven’t figured out yet how to connect schema with the request type.
For express there is even a library with rescript bindings.

12

I’ve been thinking of doing the same for Fastify as well as getting things like a graphql server working and some database drivers. I think the fear for me is to travel down that path on a client’s project and then hit a wall or end up with a time consuming issue. In that light typescript is sorta the devil you know scenario. However, I think that a solid rescript server framework that is well tested and documented could be a very formidable tool in this tool chain.

I’m excited to see some of the other projects in this thread get some traction.

1 Like
13

Are there reasons to prefer Node over compiling ReScript into OCaml’s binary?

14

One of the biggest advantages of rescript is a wast javascript ecosystem. If you want to compile to the ocaml binary it’s easier to write a program initially on ocaml

2 Likes
15

One reason is that it’s easier to convince people to try out ReScript because it’s less risky than native OCaml. You can just say that ReScript compiles to simple JavaScript that looks like it was hand-written, and if the experiment fails, we can just ‘eject’ by deleting the ReScript files and keeping the JavaScript output. It makes it easier for people to take the risk if they know they can get out easily.

EDIT: I also misread your question. ReScript doesn’t support compiling OCaml into binary, only to JS. OCaml-to-binary is a different toolchain (dune + opam/esy) and different package registry (opam packages).

2 Likes
16

I’m gonna be one of those persons that recommends a new tool lol. But seeing as how you’re even willing to look at Haskell or Ocaml.

Try out development with https://remix.run, and use rescript. I wager that most of your clients don’t need a separate frontend and backend. I became proficient enough with bindings after forcing myself to write them for a month, and not even as a day job. And if you need background jobs, use serverless-stack.com (an abstraction over aws cdk) to easily setup any lambdas, queues, pubsub, etc.

There’s also Haskell and https://ihp.digitallyinduced.com/. It’s a web framework hoping to become Haskell on Rails.

1 Like
17

Back when this was called ReasonML+Bucklescript I had planned to do full stack ReasonML with the understanding that Nodejs was just a means to an end. Given Rescript is becoming its own thing I’m planning to do Rescript frontend, and convert my ReasonML backend to Ocaml + js_of_ocaml and use NodeJS as a glue and for the ecosystem of libraries. The main reason is that if I adopt Rescript on the backend, I’m pretty much guaranteed to be stuck with Nodejs forever. With Ocaml, I at least have some options. However, also evaluating some alternatives like Purescript and Idris 2, as they can compile to JS as well + others.

18

As someone who has used haskell, ocaml, scala, c#, and ruby at various companies, I’m personally betting on golang (and python) for now. I am looking for an ecosystem that attracts developers who are both motivated by the product and the delivering a high quality, performant implementation. I also want get closer to geospatial, which seems to use python heavily.

(My question was actually curiosity about what the person who chose rescript + elm was considering, but it was interesting to hear your answer as well)

2 Likes
19

I’m of the same inclination. Turns out, a simple all in one ecosystem and tooling is my number one metric for productivity and scaling of teams. I recommend Go for most new projects if there aren’t any major caveats or appetite to use something specific.

1 Like
20

I dunno. Languages w/o ADTs seem a dead-end to me.

6 Likes