I've been looking into implementing something like this @ Gogobot as well. This eliminates the need for all `/v/` type API versioning. The client requests what it needs for this request.
Experimenting with this we often saw 50-70% reduction in the payload being sent to the clients in some requests. If I only need the first, last and avatar from the User object there's no need for my response payload to suffer because other requests need 30 fields from the same object.
Implementing this without causing a lot of N+1 queries is the tricky part and that's where we're currently investing most of our time.
Awesome to see Github adopting this and releasing it to the public API.
I theory a GraphQL API can operate verison-less utilizing things like deprecation notices and field aliasing to smooth over any rough edges. Once we see calls on a certain thing reach zero and sustain that level, we can actually remove it and never have to bump a version anywhere.
That's the dream. We'll see how reality plays out.
For reference, we actually launched with some deprecated fields (see "databaseId" on the "Issue" type -- database IDs will be phased out for global relay IDs eventually) if you want to see what they look like.
That theory is Facebook's practice. Four years later and we're on GraphQL API version 1. We add things which is safe, deprecate fields which we want to remove, and delete when hit rates drop to 0.
Granted, our clients are all Facebook engineers, so we have some pull in helping the migration away from deprecated fields, and GitHub will have to find the right process which works for a broader set of API consumers, but not only is this theory a good one, it's considered GraphQL best practice.
Experimenting with this we often saw 50-70% reduction in the payload being sent to the clients in some requests. If I only need the first, last and avatar from the User object there's no need for my response payload to suffer because other requests need 30 fields from the same object.
Implementing this without causing a lot of N+1 queries is the tricky part and that's where we're currently investing most of our time.
Awesome to see Github adopting this and releasing it to the public API.