Wow, thanks for this comment. I was not expecting such a detailed response! I hope it's OK if respond to a few things, though I think your comment could stand on it's own. You should turn it into a post here if you haven't already :)
for sure the causes are mostly technical.
First, I believe the problems GraphQL arose from are different from the problems a majority of people face in their day to day work. Facebook needed things like GraphQL and React because they had dozens of teams working on the same page that is used by millions. This isn't the case for most. Many times it's one team working in the frontend.
But second, I think all solutions arise because of human needs, desires, frustrations, anxieties, tensions, pain points, etc. People moved to NoSQL because it's hard to evolve a database, and that skillset became valuable career-wise. Performance is important because people want what they want and they want it now. It's why I say technical issues are not the primary reason.
So I'm not arguing here that GraphQL is a non-technical choice, but rather people change to it or choose it because it makes it easier for people to work together, or it's easier for people to reason about the domain.
But you end talking about technical reasons
What I'm saying in my comment is that GraphQL allows people to forget about these nuances. In other words, they like it for what they don't have to do, and they realize they could get rid of many difficulties and frustrations with modern APIs. Being "easy" or "flexible" are the flip side of frustrations like, "This is too hard," and "I can't deliver quickly or safely change what I've built."
The world has almost surpassed already the stage on which innovation relied on building new applications to implement well known business processes. The next stage is to integrate those applications and make profit of the big amount of data collected.
I really like this thought. I've borrowed the phrase "transcend and include" where we take the things that exist and mash them together to create something new.
Thanks again for the great comment and also the book recommendation. :)
What I'm saying in my comment is that GraphQL allows people to forget about these nuances. In other words, they like it for what they don't have to do, and they realize they could get rid of many difficulties and frustrations with modern APIs.
As long as I understand the GraphQL community feels very good about the current state of its toolset and capabilities:
expose quickly the data (system communications, HTTP and JS toolset, etc..)
query and combine info ( capabilities as query language)
I just to wanted to point out that the difficulties and frustrations most likely come from 2.
I remember that 15 years ago the Java and .NET community had a very mature toolset (SOAP tools) and conceptual basis (SOA). I can ensure that I never felt such frustrations about 1. (communication stack) just about 2. (querying and integrating data over disperse system).
I did really like the XML-based messages (SOAP) that could be validated against published schemas (WSDL) that could be used to generate server and clients. I still feel that thinks like OpenAPI is not so mature as WSDL.
I think that the shift was because of Microservices did appear for IoT, they did need short messages and not so formal contracts. REST protocol was minimalist and very useful for that. Given that it was based in JSON, then the javascript community did take the control and started to play with the integration from JS in the browser, removing the need of extra code to process the response to show the results to the user.
But even with those advantages, I still think that the past was not so frustrating for old API programmers regarding 1.
Still think about advantages in 2. ;-)
Thank you for bringing this topic.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Wow, thanks for this comment. I was not expecting such a detailed response! I hope it's OK if respond to a few things, though I think your comment could stand on it's own. You should turn it into a post here if you haven't already :)
First, I believe the problems GraphQL arose from are different from the problems a majority of people face in their day to day work. Facebook needed things like GraphQL and React because they had dozens of teams working on the same page that is used by millions. This isn't the case for most. Many times it's one team working in the frontend.
But second, I think all solutions arise because of human needs, desires, frustrations, anxieties, tensions, pain points, etc. People moved to NoSQL because it's hard to evolve a database, and that skillset became valuable career-wise. Performance is important because people want what they want and they want it now. It's why I say technical issues are not the primary reason.
So I'm not arguing here that GraphQL is a non-technical choice, but rather people change to it or choose it because it makes it easier for people to work together, or it's easier for people to reason about the domain.
What I'm saying in my comment is that GraphQL allows people to forget about these nuances. In other words, they like it for what they don't have to do, and they realize they could get rid of many difficulties and frustrations with modern APIs. Being "easy" or "flexible" are the flip side of frustrations like, "This is too hard," and "I can't deliver quickly or safely change what I've built."
I really like this thought. I've borrowed the phrase "transcend and include" where we take the things that exist and mash them together to create something new.
Thanks again for the great comment and also the book recommendation. :)
As long as I understand the GraphQL community feels very good about the current state of its toolset and capabilities:
expose quickly the data (system communications, HTTP and JS toolset, etc..)
query and combine info ( capabilities as query language)
I just to wanted to point out that the difficulties and frustrations most likely come from 2.
I remember that 15 years ago the Java and .NET community had a very mature toolset (SOAP tools) and conceptual basis (SOA). I can ensure that I never felt such frustrations about 1. (communication stack) just about 2. (querying and integrating data over disperse system).
I did really like the XML-based messages (SOAP) that could be validated against published schemas (WSDL) that could be used to generate server and clients. I still feel that thinks like OpenAPI is not so mature as WSDL.
I think that the shift was because of Microservices did appear for IoT, they did need short messages and not so formal contracts. REST protocol was minimalist and very useful for that. Given that it was based in JSON, then the javascript community did take the control and started to play with the integration from JS in the browser, removing the need of extra code to process the response to show the results to the user.
But even with those advantages, I still think that the past was not so frustrating for old API programmers regarding 1.
Still think about advantages in 2. ;-)
Thank you for bringing this topic.