I Am Keeping My Mind Open About GraphQL
I Am Keeping My Mind Open About GraphQL
I'm not 100% convinced that GraphQL is the solution we are looking for, but I am convinced that I should be learning more about it.
Join the DZone community and get the full member experience.Join For Free
Ready for feedback: How would you use Capital One’s Virtual Card Numbers API?
I wrote a post the other day sharing my thoughts around GraphQL seeming like we were avoiding the hard work of API design. Shortly after publishing Sashko Stubailo (@stubailo) from Apollo, a GraphQL solution provider, wrote a very thoughtful response to me comments and questions about GraphQL. First I wanted to say that I really dig this approach to responding to other people's blog posts, with a blog post of your own, within your own personal or company domain.
I don't think Sashko has convinced me 100% that GraphQL is the solution we are looking for, but he has convinced me that I should be learning more about it, keeping a closer eye on the technology, and better understand how people are putting it to use.
Regarding my primary question regarding how GraphQL could benefit non-technical folks and end-users — I would say he answered it 50% of the way:
"I’m a frontend developer. GraphQL makes my life easy."
It doesn't touch on whether or not non-technical users will be able to reverse engineer and put it to work for them, but that's OK for now. One thing that Sashko touched on for me — that moves GraphQL closer to being simple enough for non-technical users, is he helped differentiate GraphQL from SQL:
"GraphQL is a query language, like SQL? While GraphQL looks like a query language at first, I think its name might be one of the things that gets people off on the wrong foot. GraphQL is not at all like SQL ... So GraphQL is a “query language” just like URLs are the “query language” of REST — it’s a contract that describes how to tell the API server what you’re looking for."
I like the separation from "structured" query language, and moving us to something that augments HTTP and the URL, and doesn't just tunnel into the backend database. This has the potential to move REST forward, not drag the database out front for me — which leaves me more hopeful.
Another area Sashko answered for me was regarding GraphQL seeming like it was too hard:
"This is a very real concern whenever a new technology is introduced. Is this going to make stuff more complicated for everyone who isn’t in the know?"
Fair enough. It makes me happy to hear this from a service provider who is leading the charge when it comes to GraphQL. His stance seems like it is pragmatic, and aware of the importance that GraphQL needs to be accessible to as wide as possible audience as we can — building on the momentum REST has in this area.
What really pushed away my concern, and got me more interested in paying more attention to GraphQL, was when Sashko talked about this just being the beginning:
"The most exciting thing to me is that GraphQL has been publicly available for barely more than a year, and already a huge number of people I respect for their technical abilities and design thinking are trying to figure out ways to add it to their architecture."
OK. Now I want to see where this goes. I've been tracking on GraphQL as a subset of my data API research, but will spend some extra cycles each week keeping an eye who is doing anything interesting with GraphQL. I've added Apollo to my research, and I will work on a roundup of other providers, and any open source tooling I can find out there. I also wanted to thank Sashko for taking the time to answer some of my questions, and respond to my uncertainty around GraphQL. I dig it when API service providers and API providers provide responses to my storytelling on API Evangelist — makes for good conversation in the API community.
Published at DZone with permission of Kin Lane , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.