Closed jbjonesjr closed 7 years ago
I'm not very familiar with GraphQL... I'll have to do some research and get back to you.
At DevOps Days Baltimore last week GraphQL continued to come up in conversations.
Here are two varied takes on the topic that should provide a good view of the overall pros and cons:
Just to reiterate, i'm only suggesting an addendum/section that mentions what it is and what it could be used for, and pointers to learn more, rather than replacing any existing content.
@jbjonesjr, after reviewing GraphQL, we've decided not to include it in this version of the handbook as it introduces a different design pattern. However, we may revisit GraphQL in future versions. Thanks for the feedback!
Similar to my conversation (#79) about partially hydrating objects, as I look at more and more complex object relationships (and my own follies of past API decisions), I'm getting more excited by the possibilities GraphQL provides for searching and retrieving complex object structures.
Unlike some folks who are debating whether to move solely to this as an API endpoint, I do not believe the :us: Government, specifically the DoD, is ready for a move of that nature. However, I do think it can provide a much more efficient answer for retrieving and querying complex relationship data from a data store.
So, am I suggest you add a complete section on GraphQL? No. But It would be really nice and forward leaning if this document had a small discussion as a sibling technology that should be explored for complex relationships and query requirements. Maybe I'm too optimistic at the impact this can have, but I've seen too many great DoD documents get adopted, and then still in use almost a decade later. Keeping that forward leaning aspect would definitely help our Future Selves(:tm:)