GraphQL Will Make Service APIs Obsolete
In the last year or so, I’ve been watching the emergence of a new paradigm in application development, one that is shifting the way that we not only process data but is also changing the view of what an application is.
This change necessitates a critical idea: the notion that you can represent any information as a graph of relationships. This idea goes a long way back – Database pioneer Ted Codd, alluded to graph-based data systems in the 1970s, though he felt (likely for legitimate reasons) that the technology of the time was insufficient to be able to do much with the notion.
In the early 2000s, Tim Berners-Lee explored this notion more fully with RDF and the Semantic Web, which made use of an assertion-based language as a way of building inferential knowledge graphs. This technology waxed and waned and waxed again throughout the next twenty years, but even as such systems have become part of enterprise data implementations, the relatively static nature of these relationships hampered adoption.
In the mid-2010s, Facebook released a new language called GraphQL, making it open source. GraphQL was intended to primarily to deal with the various social graphs that were at the heart of the social media giant’s products, but it also provided a generalized way of both discovering and retrieving data through a set of abstract interfaces.
Discovery has long been a problem with Service APIs, primarily because it put the onus of how data would be structured on the provider, often with complex parameterizations. and poorly defined output sets. What’s more, any query often necessitated multiple steps to retrieve hierarchical data, reducing performance and necessitating deeply nested asynchronous calls (which ultimately…
Continue reading: http://www.datasciencecentral.com/xn/detail/6448529:BlogPost:1067294