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.
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.