Create a Request object and an interpretRequest path

[dmaze]

There is a mostly-standard JSON request format that's pretty widely support across GraphQL implementations, even if not part of the spec per se. This PR adds a Request type that mirrors that format, and a top-level interpretRequest entry point to run it.

The real goal of this is to allow a Servant path like

type GraphQLAPI = "graphql"
                  :> ReqBody '[JSON] GraphQL.Request
                  :> Post '[JSON] GraphQL.Response

graphQLServer :: Server GraphQLAPI
graphQLServer = liftIO . runRequest

The one big caveat in this PR is that you can't 100% deserialize Value objects without knowing their type context. This assumes that JSON strings are always GraphQL strings (they could also be enums or schema-specific scalar types) and that JSON numbers are always GraphQL floats (they could also be integers and that's probably the common case).

[jml]

Hi @dmaze,

Thanks for this PR—it seems like a good idea. I'd like to have a look over it before merging to make sure I understand it.

Out of curiosity, can you share a little about what you're using graphql-api and servant for?

Thanks, jml

[dmaze]

My day job is using GraphQL pretty successfully, and in particular, the React+Relay+Flow JavaScript stack has been a pretty comfortable way to write front-end applications that don't need much state beyond what they can get from the server. For my personal tasks I prefer to use languages where, say, it's possible for my editor to notice simple typos.

The specific thing I'm actually playing with is an application that reads the MBTA's (Boston public transit agency) real-time data feeds, caches them in a Persistent (SQLite) database, then re-serves the cached data to a front-end that can display the actual travel times between a pair of stops on a day-to-day basis (while the T claims the Red Line has a 92% on-time rate, it feels to my like at least 25% of my commute-time trips have significant delays). If the back-end exposed a GraphQL interface, then the front-end would be very familiar space to me...which brought me here.