Having Your Cake and
Eating It Too — GraphQL in Reason
Traditionally, soundly typed-language are warm and cozy in their own world, but as soon as they have to deal with the outside world (say, talking to a REST API), the pain quickly sets in: trying to keep a type definition in sync with a moving external service, manual conversion back and forth, and lots of boilerplate.
Well no more!
Proper GraphQL support in ReasonML libraries means that we can have full-stack safety, knowing that if our programs compile, the server can satisfy our requirements! And on top of that, we get all the other GraphQL goodies, like tooling, in-editor auto-complete, and fantastic compile-time optimizations, for free!
But what about the server-side, you ask? There are so many places things can go wrong when trying to maintain the promises you give to your GraphQL clients, I hear you cry out!
Dry your eyes, friend, for `ocaml-graphql-server` is here to guide you to the happy full-stack GraphQL+Reason world you’ve been dreaming of, where whole classes of errors are eliminated.
As in any good talk, however, we’ll also take a look at some of the painful points of this approach, and how ReasonML might make some tasks more difficult so that you can leave with a confident understanding of whether this new frontier is one you want to brave any time soon."
Sean Grove
Founder, OneGraph
Sean's been convinced there are better ways to develop applications across the stack for years, and built time-traveling debuggers, interface builders, layout tools, and graphic design tools in his quest to explore the space. His company was the first to deploy ClojureScript's Om library to a production app in early 2014, he helped lay the architecture for CircleCI's open-source frontend app and https://www.precursorapp.com, built systems to support tens of millions of dollars in transactions, and most recently founded OneGraph, a GraphQL API gateway to all your most important internet APIs.
