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.