I've been using GraphQL for a bout a year now on several projects. the 'flexible' part for me comes in more advanced scenarios like: Once I establish a relatio

I've been using GraphQL for a bout a year now on several projects. the 'flexible' part for me comes in more advanced scenarios like: Once I establish a relationship between two entities (`Types`), I can fetch an arbitrary combination of them from my endpoint. e.g., the resolvers that allow me to execute a query like 'fetch all posts by users who signed up since last week' to the same endpoint' can also answer 'fetch the Id of the authors of posts that start with the letter "a",' or even "fetch me every post by an author who's published a post in the past week titled with a word that starts with "C"'. All of these are possible just by defining the relationship b/t `Post` and `User`. The other part I find really something is custom field-level resolvers. Instead of every field corresponding to a database table, the `GraphQL` server can execute arbitrary code to resolve a field. In the `User` / `Post` example, I can add a field called `weather` to `Post`. Whenever the endpoint is returning a `Post` with `weather` included in the response, it could fire an API call to a weather API for the weather at the time / location that post was created. To the API consumer, this is totally transparent and `weather` is returned as though it was already in the database. This sort of arbitrary composition of data types is really at its best with `schema-stitching`. I have a bunch of content in a GraphQL-powered CMS BaaS, and using a few lines of code with `graphql-yoga` (a server), I can combine the CMS schema with a schema for my own custom data model, and even merge the two. e.g., extend my `Post` type in my CMS with a `weather` field from above.