'Is it a bad idea to mix graphql and rest in the same api gateway?
We have multiple microservices with graphql API gateways, let's say A, B and C. We also have a REST API gateway, purely for file downloads, These files can be downloaded from A, B or C, and the REST API is used to access these services for file downloads. We are using AWS and so this is being served up from AWS API gateway.
I want to move all our graphql APIs into one API gateway. This is easy enough. However, I am toying with the idea to move the rest endpoints into the same apigateway where the graphql endpoints live. This is possible, and I know how to do it, I was wondering if there are any distinct drawbacks against such an approach. After this move, our API gateway will look like this.
127.0.0.1/exchangerates <- graphl
127.0.0.1/exchangerates/file/111 <- rest endpoint in the same API gateway and living in the same path as the graphql exchangerates path.
In the gateway, the graphql entrypoint is the root to the REST endpoint
POST exchangerates
GET exchangerates/file/{id}
I want to do this because it makes it easier to understand the APIgateways as it groups all the microservices under one root endpoint, end you have one API gateway behind which many microservices are living.
Would there be any distinct drawbacks to this approach?
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|
