A chat with my friends over at Emelle.tv
YouTube - December 2021

A chat with my friends over at Emelle.tv
YouTube - October 2020

A walk through OneGraph for user feedback with swyx
YouTube - April 2020

Implementing user-authorization using can be much simpler using a well-formed GraphQL schema.
Bengaluru - February 2020

Developers are increasingly empowered to choose the APIs they want to build their product experience. That means API providers must up their DX game in order to out-compete other APIs a developer may be looking at.
London, England && Paris, France - November 2019 && December 2019

Thanks to wasm, Rust can reach the platform with the largest reach: the browser. We'll take a look at how thanks to the impressive language design, thoughtful compiler error messages, and great documentation, JavaScripters can unlock high-performance concurrency and graphics thanks to Rust. We'll step through Rust/wasm/JS interop, see what it's like to get a reference to a canvas instance, to communicate with services workers, and to pass data between all the pieces involved. We'll take a look at what's enabled, as well as pitfalls around the data boundaries involved, and the size of the final payload, so that it's clear where the cost of introducing Rust is outweighed by its benefits. Finally, we'll speculate on how the web may develop, with a Rust-core/JavaScript-surface design, combining high performance, safety, while maintaining ease-of-use.
Prague, Czech Republic - October 2019

Build a podcast player using the new (as of 2019) simplified React component syntax, GraphQL, and write bindings to Ant Design. Great success!
Chicago, Illinois - October 2019

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.
Vilnius, Lithuania - May 2019

Let’s explore the benefits and tradeoffs when pairing GraphQL and Reason, both from a server’s and a client’s point-of-view. We’ll build a small but realistic full-stack app together that you can take away and tweak for real-work projects afterwards.

We’ll start with a quick overview of GraphQL’s properties, how the system works, and what the overall ecosystem looks like.

From there, we’ll use GraphQL + ReasonReact on the frontend to build a client for a small app against OneGraph, so we have a sense of what consuming GraphQL is like in a day-to-day context.

Next, we’ll move on to building a fully-native Reason GraphQL server. We’ll take an existing project that uses a high-performance http server (httpaf), Reason’s GraphQL server (ocaml-graphql-server), and a PostgreSQL-compatible model library (oneSql) to quickly iterate and build a custom GraphQL application for our client.

Once we have our application running locally, we’ll set up continuous deployment via CircleCI and push our app to production, where anyone can hit it! The CD process will include automated tests that will fail if we attempt to push breaking changes to our GraphQL schema, unless we manually override it. This is a great way to combine the speed of CD with the comfort of knowing you’re (likely!) not breaking any clients.

Towards the end of the day, we’ll see what it’s like to consume another GraphQL service from the server, while still retaining the type safety and convenience that we enjoyed earlier in the day on the client.

Finally, we’ll explore what schema stitching might look like, so that we can enjoy all the existing work that’s gone into the GraphQL SaaS ecosystem, while still providing our own custom data.
Vienna, Austria - April 2019

A fun, fast-paced lightning talk at Vercel
Vercel, SF - March 2019

This is a rehash of the previous ReasonMl/GraphQL talks, but targeted at a less reason-specific audience. If you're wondering more about why Reason and/or GraphQL might be interesting - especially if you're much more into dynamic languages like JavaScript or ClojureScript - this might be a better talk for you.

• GraphQL is the bee's knees: More control for the client, no more over/under fetching
• GraphQL's type-system enables safety-guarantees and tooling that'll make you swoon
• ReasonML can incorporate GraphQL's type system on the client to make app dev easier, safer, and faster
• Introducing a ReasonML GraphQL server or client is straightforward and doable today
  Malmö, Sweden - November 2018

Let's build a small ReasonReact app from the ground up that will read/write with real-world GraphQL APIs.

We'll start from the basics, going over built in Reason data structures, syntax, libraries, editor/compiler tooling, and continue our way up into ReasonReact JSX, Javascript interop, and typed GraphQL support.
Prague, Czech Republic - October 2018

• We'll discuss the origin, advantage, and also challenges of ReasonML.
• How to incrementally adopt Reason today in your day-to-day work
• How GraphQL solves the biggest challenge Reason and Reason-like languages (or Elm, Haskell, etc.)

One of the biggest challenges faced in closed-systems like Reason (or Elm, Haskell, etc.) is interacting with the outside world,and in today's world, every application must interact with the outside world in the form of APIs.

The interaction and combination of GraphQL's type system with Reason's bridges the gap, to bring both speedy and safe application development to reality today.
Slovakia: Košice, Bratislava | Czech Republic: Brno, Hradec Králové, Prague - May 2018

When is programming intrinsically fun, and when is it laborious? What drives some developers towards the rapidly developing JavaScript ecosystem, while others flock to less-developed and more esoteric languages and ecosystems? What keeps us using metaphors and abstractions developed so many decades before, when we've spent so much effort designing clean-slate systems? We'll look at this discussion through the prism of ReasonML, a new syntax and set of tooling around OCaml.
Malmö, Sweden - November 2017

A fast, furious, and live demo of OneGraph in front of 1,000+ attendees all exhausted from two days of non-stop high-tech talks.
Bratislava, Slovakia - October 2017

A variation on the previous two talks, a bit slower and more in depth for a smaller crowd. I definitely enjoy being able to answer Q&A a bit more in this style.
Brno, Czech Republic - November 2016

The traditional rehearsal at ReactVienna as a polish step before giving the full talk at ReactiveConf a few days later. I go over some of the compelling ideas behind ReasonML to some of the future founders of ReasonVienna, the world's first (and possibly most productive) Reason meetup.
Vienna, Austria - October 2016

With libraries like Mirage, js_of_ocaml, & ARM compiler output OCaml apps can operate at such a low level we don't even need operating systems on the backend anymore (removing 15 million lines of memory-unsafe code) - while at the same time, writing UI's is easier & more reliable than ever before, with lightweight type-checked code sharing between server, browser clients, & native mobile apps. We'll look at what's enabled by new tech like Unikernels, efficient JS/ARM output, & easy host interop.
Rome, Italy - July 2016

Writing (or recording) tests manually is a tedious, robotic, and dangerous practice. It combines the worst of human nature (it's easy to avoid, easy to forget about edge cases, and difficult to maintain) with the worst of computers (no creativity in trying to break the tests, no understanding of how the underlying system works). What if we could assert high-level properties about our product (in this case, a web site), and then teach the computer to generate tests in order to try to break those assertions?
Bengaluru, India - June 2016