GraphQL, and the end of shared client-side model objects

How to use GraphQL, React and Swift to get exactly what your app needs

In traditional client-server development, client-side models don’t often differ too dramatically from server-side models.

Should they?

A standard RESTful API might serialize a server-side user model as such:

Instances of this same user model type can be vended by multiple routes, e.g.:

1. /me — A route that returns the currently authenticated user
2. /friends — A route that returns the current user’s friends

RESTful APIs aren’t inherently type-safe, so a frontend developer will generally learn that these routes both return objects of the same User type by looking at the API documentation (and hoping that it’s accurate¹), or by eyeballing the HTTP traffic itself.

After realizing this, a type definition like the following can be manually added to your client-side application, instances of which you can populate when parsing response bodies from either of these two routes:

This shared, canonical User model can be used by any part of the frontend application that needs any subset of a user’s attributes. You can easily cache these User instances in your client-side key-value store or relational database.

Suppose that your application includes the following capabilities (and is continuing to grow in complexity):

1. Rendering user profiles (requires all user properties)
2. Viewing a list of friends (requires user names and avatars only)
3. Showing the current user’s avatar in the navigation (requires avatar…