Unrest — from REST to GraphQL

GraphQL: A new way to REST

The Side Project: a blessing and a curse. A time-limited yet open adventure where a balance between discovery and destination must be struck.

This is a story about a side project at Unlease.

The Brief

We needed to build an internal tool to help with account management, drawing data from our application and allowing it to be operated on. We’d hastily built something similar before and had plenty of lessons to learn from. The new tool had to be maintainable, abstracted from yet complimentary to the source application and, most importantly, a pleasure to develop.

It was also a chance to get a taste of the GraphQL hype that had been on our radar for a few months.

Going with GraphQL

Our first decision was whether to go full GraphQL or to create a proxy to our existing REST API. Ideally full GraphQL is the way to go but as we were building a satellite to our primary infrastructure a proxy was the best option for speed and stability. Aside: we called it Unrest — Unlease plus (or minus) REST…

We had a great opportunity to meet with Johannes Schickling from Graphcool who was amazingly helpful in giving us some context and advice on our options, approach and tooling. Graphcool is a very exciting addition to the ecosystem. If we didn’t have our existing API/database infrastructure it would have been a great fit. For a progressive startup developing a launch product it would be perfect .

Graphcool 5 min setup!

Learning curve

When working with these relatively new technologies it quickly became apparent that best practices and conventions are still being worked out by the community and contributors. Above all, the boilerplate currently required to setup Relay seems excessive and locks-in the GraphQL implementation.

Relay’s consumption of your GraphQL schema can be a bit of a gotcha too — early on I would quite often update some Type, forget to update Relay’s copy of the schema and get a compilation error. A clever solution to automate schema generation for client consumption would be awesome.

Anyway, these are my top, high-level tips for working with GraphQL/Relay:

  1. Wait for the new Relay core (or use Apollo). If you are using Relay, add react-relay-network-layer for some middleware sweetness.
  2. Get your application structure right. Organise folders by domain (auth, todo, user) not roles (queries, mutations, components).
  3. Use context to pass access tokens and database connections to your services.


Like a lot of the paradigms coming out of Facebook at the moment (React etc) the constraints imposed by GraphQL/Relay force you to rethink how you write services. Schema definitions in particular enforce stricter rules on data and API design.

Side projects are perfect for testing out these patterns and frameworks but it is crucial to produce something functional and resilient. The additional challenge for a young, small company is to ‘tread lightly’ — innovate now whilst not limiting your future options.