Graph QL Support

[mbryzek]

graphql.txt

[mbryzek]

unstructured thoughts, but believe apidoc service.json gives us a lot of information to efficiently implement a graph ql server

{
  user {
    first
    last
  }
}

As input: 1 or more apidoc service files....

resource for the model named "user"

find the model named user is first a valid field? is last a valid field?

what service runs user - well I have the base url... (or at low it's convention user.api.flow.io)

[ GET https://api.flow.io/users ] map { value => if value is not an array - return error

  value.map { u =>
    Json.obj(
      first -> u \ "first",
      last -> u \ "first"
    )
  }

{
  order {
    id
    submitted_at
    user {
      first
    }
  }
}

get the resource for the model 'order' note that user field is of type 'user' get the resource for the model 'user'

GET URL/orders => array

collect ALL the user.id's (how do we know 'id' is primary key?)

• by convention, pkey is the first query paramater in the GET call and must be of type [string]

ordres 12, 14, 15 user id 123, 124

GET URL/users?id=123&id=124 // one API call filter to requested fields

merge two results

now we return the requested orders with the requested user data, and we did this all in two API calls

[kalmanb]

My 2c, we're starting to use graphql and grpc (protobufs). They both provide parts of what apidoc does. In a perfect world we'd define spec's in apidoc and generate graphql and protobuf specs. From the protobuf specs protoc generates clients and servers, we'd wrap protoc as an apidoc generator.

[kalmanb]

Note, one of the issues we had with both avro and protobufs is where do we store the specs. To be effective they really need a central place, be it git repo, web service etc. apidoc would be perfect ;)