What happens if your company now needs to expose their API (or parts of it) as an open, public API? Many API users (organizations, companies) expect a standard REST API and don't want to learn a new technology or have to install new client libraries just to perform CRUD operations on your data. Good luck trying to educate your enterprise customers.
So you start coding a new REST API just for the public API use case, having to test, maintain and keep parity with the GraphQL version over time? This package allows you to get a RESTful API for free (and customize it per your needs), based on your existing GraphQL.
Another use case is exactly for what you described, when a company wished to replace their REST API with GraphQL:
An old REST API can be migrated to a new GraphQL API gradually, by first building the GraphQL API and using GraphQL2REST to generate a REST API on top of it, seamlessly. That new REST API will have the same interface as the old one, and the new implementation can then be tested, endpoints migrated in stages, until a full migration to the underlying GraphQL API takes place.
All GraphQL servers/implementations are supported, since the module is agnostic about the GraphQL server type - you provide the execute() function yourself.
By default graphql2rest assumes Apollo Link's execute() (with node-fetch), so it supports local and remote GraphQL servers via HTTP connection out of the box. But you can wrap your server's execute function and pass it whatever arguments it expects, so any GraphQL implementation can be used.
We had an internal GraphQL API driving our product and users asked for a public API that will provide that functionality programmatically.
We offered to expose our GraphQL API publicly (or some subset/version of it), but the majority of our customers insisted on getting a REST API.
(They had good reasons to ask for REST: they were used to RESTful APIs in our previous API offerings, it seemed that the market adoption of GraphQL for public APIs is not that wide, etc.)
In any case, we had to offer a REST flavor of the API providing the same functionality we had already implemented in GraphQL, and instead of writing a new REST API (and then testing it, maintaining it, and keeping both parity over time...) or manually wrapping the existing GraphQL operations -- we decided to develop a graphql-to-rest converter that we later open sourced.
So you start coding a new REST API just for the public API use case, having to test, maintain and keep parity with the GraphQL version over time? This package allows you to get a RESTful API for free (and customize it per your needs), based on your existing GraphQL.
Another use case is exactly for what you described, when a company wished to replace their REST API with GraphQL:
An old REST API can be migrated to a new GraphQL API gradually, by first building the GraphQL API and using GraphQL2REST to generate a REST API on top of it, seamlessly. That new REST API will have the same interface as the old one, and the new implementation can then be tested, endpoints migrated in stages, until a full migration to the underlying GraphQL API takes place.