Strong typing from the server to the UI with GraphQL

updated 5 months ago; latest suggestion 5 months ago

GraphQL is a strongly-typed and efficient method for fetching structured data from a server, designed to be an alternative to REST. It was developed in 2012 at Facebook, and has powered Facebook's main iOS and Android apps for the last five years. After being open sourced in 2015, it is now being used by an increasing number of well known companies.

An important benefit over REST is that it allows clients to ask for the exact data they need, without the server sending extraneous results or having to perform extra roundtrips to fetch related objects. It also makes it possible for a single server endpoint to support multiple versions of your app, without explicit versioning of your API.

In this talk, I will introduce GraphQL, discuss why it is such a great match for mobile development, and talk about our efforts to build an open source GraphQL client for iOS, written in Swift.

In particular, I will explain how we take advantage of code generation and the GraphQL type system to enable static type safety from the server to the UI, complete with Xcode integration.

I will also discuss how GraphQL fits in modern iOS app architectures, and allows you to eliminate common glue code. Our client is built on immutable models, one way data flow, and automatic consistency management. Especially when combined with advanced GraphQL features like real-time updates over WebSockets, this leads to a very powerful and elegant programming model that greatly simplifies app development.

Suggestions

  • The proposal author responds 5 months ago

    Good point, I should definitely make sure to explain that.

    GraphQL includes a built-in deprecation mechanism as part of the schema, but it's an open question how long to keep supporting deprecated fields. Facebook has chosen never to remove fields, so they claim even their five year old clients still continue to run against the same endpoint. But there is a cost to maintaining fields, especially with less homogenous and evolving backends. So you probably want to keep track of field usage and remove fields if this drops below a certain percentage (or if only client versions you don't care about still use it).

  • 762cbf482cafe446ed8edb5b007cbe0778287a09?size=100x100 762cbf482cafe446ed8edb5b007cbe0778287a09 suggests 5 months ago

    One thing I'd want to hear about is how you make sure an unversioned GraphQL API doesn't break older versions of an API - do you have to support every single query parameter ever introduced until the end of time, or are there more graceful ways of deprecating a particular object?