We are currently using nginx as a reverse proxy for API mutations and GraphQL as a unified API service for all API access and fetch, where GQL has good support for caching, sorting, pagination, and querying. Is it recommended to use NGINX for all of the above purposes, and when API aggregation is not the case, not use GQL.
Or for sorting, querying, pagination, caching - is GQL always a better choice, even if there is no API aggregation involved?
It depends of your architecture, but my use is pretty simple up to now. My reverse proxy using nginx only skips the hit of the location /graphql to our application server through an upstream location that handles it, but at the future it'll probably be another app or a microservice. If you want something to load balance, probably it's better to use something like traefik.
Nginx is very low level and particularly difficult to debug (the documentation is really extensive and not so readable, and debugging when configured wrong is a pain), it will give you headaches for sure ! Keep nginx as minimal as possible and use it only for bare server configuration (handling SSL, domain names, reversed proxy, and load balancing). Nginx is also very fast to serve static assets. Nginx was originally created to serve static / templated WEB Servers and never as a REST API Handler. For "sorting, querying, pagination, caching" i'd stay with GQL because it's super easy to debug, it's readable, and mostly it was created to be simple and to handle REST API.
Thanks for the response, I agree with the same idea and it validated with your thought as well. Somehow it is also intuitive not to use Nginx for "sorting, querying, pagination, caching" .