People like GraphQL, but I'm unconvinced it's primarily for technical reason.
But you end talking about technical reasons:
It allows consumers to forget about the nuances of HTTP methods.
I like more to think about the nature of the data and the evolution of the information systems. Something like the reasons you cited from Tim Berners-Lee. 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.
The same existence of software changes the dynamic of the human /apps ecosystem, the users know more about which is possible with the information and the developers know more about the problem domains where the information is generated. That results in new requirements and applications evolving at greater speed.
Relational databases use to fit very good for database-centric applications that do not change too much. The performance relied on the advantage of the indexes and other mechanisms that favour writing less and reading more.
But that did change with the advent of social networks and other apps from this evolution stage. In Facebook, for example, the amount of information written is greater than the one is shown to the friends. They needed another stuff. If implemented with relational databases, most of the time the db engine would spent it updating indexes and the performance would be not as expected.
A quick solution did arise with NoSQL databases, but they did required to plan very good how would the queries made in the moment of designing how to store it. So it was not optimal for an constantly evolving app and internet ecosystem.
Furthermore, integrating information from sparse systems and presenting it with relation started to give shape to new business models. Think about booking systems, for example. New useful information might arise every day. Darcy DiNucci coined this stage of the web as Web 2.0 in its article Fragmented Future.
It results that graph databases fits for both cases:
easy addition of information: The data schema is described in a simple structure and it is data it self. Everything did start to be internally like [nodeA]-relation->[nodeB] represented by tuplets (infoA, relation, infoB) that could be easily added in order to merge and relate info from different systems. This is useful for integrating information of spare systems minimizing the offline time.
flexible querying: Once the information is in the graph, it could be queried as you need it.
For this last point is that a query language is needed.
I think that is a consequence of the evolution of the whole ecosystem of internet apps but for sure the causes are mostly technical.
I mean it was not a functional requirement, it had nothing to do with the design of the business. It has to do with the technological (non-functional) requirements imposed to the IT that needed to support all of this. Mostly the database systems but sure the Web services also.
You can check a whole example developed from the old paradigm to the new one, step by step in the book Programming the Semantic Web which I consider a most-read to understand the paradigm shift. The problem domain is related to a restaurant.
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.
But you end talking about technical reasons:
I like more to think about the nature of the data and the evolution of the information systems. Something like the reasons you cited from Tim Berners-Lee. 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.
The same existence of software changes the dynamic of the human /apps ecosystem, the users know more about which is possible with the information and the developers know more about the problem domains where the information is generated. That results in new requirements and applications evolving at greater speed.
Relational databases use to fit very good for database-centric applications that do not change too much. The performance relied on the advantage of the indexes and other mechanisms that favour writing less and reading more.
But that did change with the advent of social networks and other apps from this evolution stage. In Facebook, for example, the amount of information written is greater than the one is shown to the friends. They needed another stuff. If implemented with relational databases, most of the time the db engine would spent it updating indexes and the performance would be not as expected.
A quick solution did arise with NoSQL databases, but they did required to plan very good how would the queries made in the moment of designing how to store it. So it was not optimal for an constantly evolving app and internet ecosystem.
Furthermore, integrating information from sparse systems and presenting it with relation started to give shape to new business models. Think about booking systems, for example. New useful information might arise every day. Darcy DiNucci coined this stage of the web as Web 2.0 in its article Fragmented Future.
It results that graph databases fits for both cases:
easy addition of information: The data schema is described in a simple structure and it is data it self. Everything did start to be internally like [nodeA]-relation->[nodeB] represented by tuplets (infoA, relation, infoB) that could be easily added in order to merge and relate info from different systems. This is useful for integrating information of spare systems minimizing the offline time.
flexible querying: Once the information is in the graph, it could be queried as you need it.
For this last point is that a query language is needed.
I think that is a consequence of the evolution of the whole ecosystem of internet apps but for sure the causes are mostly technical.
I mean it was not a functional requirement, it had nothing to do with the design of the business. It has to do with the technological (non-functional) requirements imposed to the IT that needed to support all of this. Mostly the database systems but sure the Web services also.
You can check a whole example developed from the old paradigm to the new one, step by step in the book Programming the Semantic Web which I consider a most-read to understand the paradigm shift. The problem domain is related to a restaurant.
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.