Hasura announced today that it has extended its GraphQL engine to allow joining of data generated from multiple sources.
Hasura CEO Tanmai Gopal said GraphQL joins allows you to join data from different GraphQL services which can then be accessed through a single GraphQL application programming interface (API). Extending the federation capabilities enabled by the Hasura GraphQL engine eliminates the need for custom code that would otherwise be needed to join this data, he added.
The Hasura engine automatically generates a GraphQL schema from a data source which can then be used to accelerate API development. GraphQL Joins extends this federation capability to now include multiple GraphQLs and, optionally, other data sources accessible through, for example, legacy REST APIs, Gopal said. This capability will make it easier for a wider range of developers to build apps that aggregate data across multiple sources, he added.
The core of the Hasura engine is based on open-source software which the company says has now been downloaded more than 500 million times. Hasura provides a cloud service based on this core engine. This approach eliminates the backend complexity that IT teams encounter when adding GraphQL APIs to an application environment that already has a range of APIs that internal IT teams need to support, noted Gopal. .
GraphQL was originally created by Facebook, and it’s still unclear to what extent GraphQL APIs will supplant REST APIs. Developers tend to prefer GraphQL APIs because they offer more granular control over what data is accessed. The challenge is that the number of backend services that expose GraphQL APIs is still relatively limited. Most IT teams won’t replace REST APIs with GraphQL-based APIs overnight, but the percentage of new applications that rely on GraphQL APIs will steadily increase. DevOps teams looking for easier ways to provide developers with access to backend services through a GraphQL API can use the Hasura engine to automate this process.
Overall, the number of APIs used in computing environments is growing rapidly as more and more microservices-based applications are deployed. Each microservice generates its own API. Over time, IT teams will find themselves managing a range of API types to support multiple enterprise digital transformation initiatives that an organization may have launched concurrently. In addition to building APIs, many of these organizations now consume data through APIs exposed by another organization. Over time, the level of interdependence between APIs and applications will serve to make application environments much more complex. The good news is that APIs make it easy to upgrade or even replace backend services without disrupting application services.
However, it is not always clear who within IT organizations will manage these APIs. They are often created by developers who then turn to IT operations teams to maintain them. Before long, it’s not uncommon for IT teams to find themselves managing hundreds, if not thousands, of REST APIs and web services, and soon this could include many APIs built using GraphQL.