With GraphQL, you model your business domain as a graph by defining a schema; within your schema, you define different types of nodes and how they connect/relate to one another." Through schemas, GraphQL has greatly improved the development experience as compared to REST, enabling applications to be shipped faster then ever.
However, mainly due to the limitations from a schema model, GraphQL has faced several issues that, after several years of trying, nobody has been able to solve on a conclusive manner. Among them, its security is suboptimal, since it enables malicious actors to execute Denial of Service attacks on the database server; it cannot be cached on the server, since it mainly operates through POST requests, adding complexity and processing cost to the application on the client-side; a type definition must live on a single location, making it difficult for team members to collaborate (as evidenced by the deprecation of schema stitching and the difficulty of implementing the data model in the specific way demanded by the federation approach), more often than not leading to a monolith architecture; it can become tedious to set it up on the server, since each schema must list down all of its objects' properties, leading to an overabundance of code; and executing a query with many levels of depth can become very slow, since its time complexity to resolve queries can be exponential.
Luckily, there is an alternative approach to using a schema model for representing an information graph, which does not suffer any of its disadvantages: Components! A component hierarchy can mirror the data structure from a graph, enabling us to obtain the benefits from GraphQL, while at the same time losing none of the advantages from a simple REST architecture. Picture yourself accessing the great development experience of GraphQL, but with the added server-side performance and security from REST, minus the inconvenience of having to set-up thousands of properties on the schema, and allowing the team to split the creation of the data model without any overlapping of tasks or need to set-up special tooling.
A data API based on components is the greatest kept secret... until this presentation demonstrates all about it. Join me for an enlightening journey into the power of components!
About Leonardo Losoviz
Leonardo Losoviz is a freelance open source developer, creator of PoP (an API + component-model + framework for building sites on PHP), regular contributor to Smashing Magazine, and occasional conference speaker. He spends his days coding for the web on whatever project goes his way, learning new technologies, and writing down what he has learnt to share his experience with others, on his own blog leoloso.com, on Smashing Magazine, conferences and meetups.
Nomad JavaScript
Meetings