I hadn’t heard of that format. I’ve been really pleased with GraphQL paired with Elm. dillonkearns/elm-graphql automatically generates type-safe Elm code for you so that you can build up queries that are guaranteed to follow the GraphQL schema. The decoders are abstracted away and guaranteed to be correct. There seems to be a lot of momentum around GraphQL, too, so I think it’s a great option!
To Evan’s potential con in the GraphQL section of the data interchange gist, it is indeed the case that there is a culture around backwards-compatibility with GraphQL. Here’s a post from Facebook that touches on it
When you’re adding new product features, additional fields can be added to the server, leaving existing clients unaffected. When you’re sunsetting older features, the corresponding server fields can be deprecated but continue to function. This gradual, backward-compatible process removes the need for an incrementing version number. We still support three years of released Facebook applications on the same version of our GraphQL API.
In fact, with dillonkearns/elm-graphql you can even setup a script to enforce that as part of your deploy pipeline. Just check if it compiles. If it doesn’t then your schema had a breaking change!
I’ll be speaking more about this library and some of these concepts in a talk about extending type-safety beyond Elm’s borders at elm-conf next month 
I’m curious, what are the tradeoffs between GraphQL and Transit?
