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.
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.
https://medium.com/swlh/graphql-api-or-rest-api-why-not-have...
You should it if you:
1. Already have a GraphQL API, but your users want REST
2. Want to develop a new GraphQL API and get REST on top of it, for free
3. Want to benefit from GraphQL internally while exposing REST externally as a public API
4. Like your RESTful API to be truly RESTful, on top of a possibly completely different native GraphQL implementation