In a recent InfoQ podcast, Matt Debergalis, founder and CTO at Apollo, discussed the motivations for GraphQL and the Apollo Data Graph platform. Key topics explored included data modelling in an enterprise context, and how incrementally adopting GraphQL can help with decoupling the evolution of frontend and backend systems.
Debergalis argued that the challenges of defining client-side-friendly data models, building maintainable and composable backend APIs, and moving data from the cloud to a client application contributes to making modern software development difficult and time consuming.
[...] every time you want to build a new screen in your app, you end up having to go write a new API on the backend to serve the needs of that screen. And it's all boilerplate, it's all plumbing, none of it's reusable, particularly, and you end up closely entangling your backend and your application when you do that.
GraphQL is an open-source data query and manipulation language for APIs, and a runtime for fulfilling queries with existing data. GraphQL lets application developers describe the data they need and bring that data into the screens that they are building for their users.
The Apollo Data Graph platform is a middleware layer that provides a way of decoupling the core business APIs from the client-side consumption patterns. Apollo can implement cross-cutting concerns, such as transaction management, which mitigates the need to implement this in (potentially multiple) client-side applications.
Apollo is the industry standard implementation of GraphQL. That includes GraphQL clients for all the major platforms, JavaScript, Android, iOS. It includes a GraphQL server that's built in TypeScript, and it includes a set of services, a registry for GraphQL schemas and tooling and workflows that let you collaborate around a GraphQL layer as a team.
Other related platforms and frameworks included Hasura, an “open source engine that connects to databases and microservices and auto-generates a production-ready GraphQL backend”, and Relay, a GraphQL client for React that was built by the Facebook Engineering team.
Apollo makes it possible to build a “data graph”: a series of graphs that are composed from an organisation’s data for use within client-side applications. A data graph is especially valuable in larger enterprises because it is here that many (money making) systems with existing APIs need to be combined to meet new business requirements.
What we do at Apollo is we make it possible to build what we call a data graph. And a data graph is especially valuable in a larger enterprise because it's in those organizations where you have existing systems with existing APIs, whether those are REST or SOAP or in a more modern setting, you might see GRPC or Thrift.
Debergalis suggested that GraphQL can be adopted in an incremental fashion. He recommended engineers just build the simplest possible graph that matches the needs of the first application, the first screen, or the first component that is required to transition over to the graph. And then they should let that graph evolve into a richer model that covers the wider context, decomposing and loosely-coupling graphs where appropriate.