Hi,
I just read the 0.19 release notes and this gist from Evan about data interchange.
I was reminded of Rich Hickey’s Transit data format, which is not discussed in the gist.
I don’t know if it’s a good fit for Elm, but I thought it would be nice if language and library designers here would know about it. Maybe it can be an inspiration.
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!
Another option would be to use OpenAPI. This specification can be used to define REST APIs. Using OpenAPI Generator you can automatically generate/update your Elm models, decoders, encoders and HTTP requests. We use it to both generate server (interfaces) and client code.