Brainstorm for open-source community project

#1

I feel that Reason could really benefit from an open-source project that can also serve as a “reference project/app”. I’m thinking, what the Telescope project (now VulcanJS) was for Meteor community, we could benefit from something like that for the Reason community.

In that spirit, what problem would you choose to solve if you wanted to build something useful that solved a real problem, with ReasonML? I’m imagining something using React/GraphQL/Apollo, but it could certainly go beyond those technologies.

#2

The RealWorld project has a spec for the API and defined behaviour for the purposes you mention. It could be a good option for both having frontend and backend examples.

#3

If you end up porting Vulcan to Reason maybe we can all migrate to that version!

#4

There is a realworld frontend in ReasonML already here: https://github.com/gothinkster/reasonml-realworld-example-app

The backend story of ReasonML is kinda sad atm. Read this podcast for more information: https://reason.town/server-side

#5

Real world is like a slightly more advanced Todo-MVC. It may be good for a beginner to learn, but I think it’s not going to really inspire anyone!

Thanks, will listen to podcast (catching up)

#6

@SachaG I’m a big fan of VulcanJS. I’ve looked at it in the past at different points in its development and hacked with it a little bit. I think the biggest problem with Vulcan is one of perception. I don’t doubt that the architecture is superior to others (I personally like meteor and package.js instead of learnaJS “monorepo” or whatever is the latest trendy technology is), but since “webpack is so awesome”, some people see package.js and they are scared. Hmm, I wish Meteor did a better job in promoting its build system as a way to build more modular apps and systems. Maybe they were too ahead of their time and people got confused about what it actually was and what it’s good for.

#7

Yeah, in an ideal world I would snap my fingers and port Vulcan to whatever is the new hotness (Reason? ;). But I’ve made my peace with being stuck with Meteor, I’ll focus on things that are easier to change for now.

#8

VulcanJS would be a fantastic project, not only as a more advanced learning resource but simply as a tool to use. Its SmartForms are really nice if you do a lot of form generating/processing.

#9

I want to make a Jekyll-like layer around Gatsby in ReasonReact to make it more turnkey.

#10

Yeah! I don’t know/remember much about SmartForms, but I agree this would be cool and useful.

If it could be done gradually, it would be a fun project. It looks like to get a basic reason-vulcan example working, we’d have to convert and or wrap:
vulcan:core
vulcan:forms
vulcan:accounts

Although, I also wonder how coupled Vulcan is to Meteor collections and MongoDB. I guess Meteor and MongoDB is not necessarily bad, as long as there are decent options for hosting :thinking:

#11

Phenomic has Reason support already https://github.com/phenomic/phenomic

But I think this topic is about building something entirely in ReasonML, not a wrapper :stuck_out_tongue:

#13

So I have been working on a ReasonML playground project https://github.com/thangngoc89/rtop-ui

it started as a small frontend project but it has grownth into a full stack project. I would love some collaborations from the community to make it the best REpl (pun intended).

Some technology highlights:

  • Client: reason-react, reason-apollo, codemirror for editor
  • Server: hasura graphql-engine
#14

I was surprised that in the Reasontown backend episode they basically just recommend compiling to JS even on the server. Then I looked around and it really does seem the OCaml web backend space isn’t all that developed? I found Opium, which looks nice and simple, and was easy enough to use in Reason, but it’s certainly no Express. And I can’t even begin to penetrate the docs for Ocsigen :no_mouth:.

I’m hoping to do a little frontend/backend side project in Reason, and I’m a big fan of compiling to native, so maybe I’ll end up starting my own web framework. cohttp, which Opium is based on, seems like a reasonable place to start.