Comparison with GraphQL for non-email APIs

[TuhinNair]

Hey, first just wanted to say thanks for JMAP.

I love that JMAP utilizes the ubiquity of JSON and simple HTTP(S).

Both JMAP and GraphQL seem to solve the overfetching/underfetching problem and allow all required data to be retrieved by a single request.

For non-email API's are there any advantages to using JMAP instead of GraphQL?

[neilj]

GraphQL is a good fit if you:

• don't need offline support
• are almost entirely read-only (your client doesn't make many changes)
• have one huge graph of related data

Essentially, if you have Facebook's problems, then Facebook's solution is probably good.

Most apps though are much more like an email client: if you have a traditional database-backed application with tables of different data types, then JMAP is probably a much better fit. With JMAP you get very powerful generic mechanisms for resyncing data when a change is made elsewhere, full push updates support, an efficient and consistent way to perform mutations, access to progressively loading queries to display huge volumes of data efficiently, etc.

While email was the first application for JMAP, at the IETF we are almost finished finalising the spec for Calendars (i.e., to replace CalDAV) and will do Contacts soon after. At Fastmail we use JMAP for everything, and it makes it super easy to add new data types – we don't have to think about what the API will look like or how to sync them, just what the data for a record should look like.