OpenAPI-to-GraphQL version 1.0.0 released
We are happy to announce the release of version 1.0.0 of our open-source library OpenAPI-to-GraphQL which allows you to use your existing REST API portfolio…
We are happy to announce the release of version 1.0.0 of our open source library OpenAPI-to-GraphQL (originally published as “OASGraph” back in September 2018). OpenAPI-to-GraphQL allows you to leverage your existing REST API portfolio to build easy-to-use GraphQL interfaces.
OpenAPI-to-GraphQL, as its name suggests, generates GraphQL wrappers for existing Web APIs described in the OpenAPI specification or Swagger. Thus, it makes it extremely easy and fast to generate GraphQL APIs, but also provides advanced configuration options to fine-tune them if need be.
In contrast to other libraries, OpenAPI-to-GraphQL relies on data definitions to generate easy-to-use GraphQL interfaces, it sanitizes and de-sanitizes parts of APIs incompatible with GraphQL, and makes makes use of OpenAPI 3.0.0 features like
links to generate more usable GraphQL interfaces.
On the one hand, OpenAPI-to-GraphQL can be used as a command line interface (CLI), to instantly get started. On the other hand, it can be used as a library, allowing to integrate it with your backend code. See this video for an introductory demonstration.
The new version
Since its original release, we have received feedback, issues, and pull requests from users both within IBM and externally. Collectively, they helped our library to be more broadly applicable, provide more features, and be more robust. Some highlights of the new version 1.0.0 include:
- Multi-OAS support allows to create a single GraphQL interface that is backed by multiple existing APIs. Inter-OAS links mean that the OpenAPI specifications can be used to define data links between these APIs.
- A new option allows you to provide custom resolver functions, giving you full control to implement custom logic required to resolve parts of GraphQL queries (for example, to deal with unique authentication requirements, to access other systems apart from an API, to implement caching etc.).
- Improved error handling through error extensions and more consistent warnings make it easier to understand if something goes wrong.
- Improvements to the code base and development process (e.g., now enforcing consistent code style using Prettier), to make it easier for others to contribute to OpenAPI-to-GraphQL.
Erik Wittern is a research staff member at the Thomas J. Watson Research Center who studies both the provision and consumption of web APIs from a developer’s perspective.