Open mbryzek opened 7 years ago
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?)
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
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.
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 ;)
graphql.txt