I tend to write publicly facing APIs so this conversation is colored a little by that. An internal API or Microservice is a different story.
I don't think it is either of. I use both. In the same API. The two are largely compatible.
All REST APIs can be modeled in RPC style APIs and that's no different with GraphQL.
I've done APIs where I have a GraphQL facade in front of REST and REST Facades infront of GraphQL by having all my REST endpoints be two lines
1. Graph QL query
2. Format result as REST
That first like maps to a graphQL query and the second one can be standardized for all your REST endpoints.
I tend to like REST in-front of GraphQL better since it allows for some performance optimizations when you know ahead of time all the data you need to grab.
And since GraphQL can be mapped to classes you could also just skip the GraphQL query compile and use the classes directly from your REST with only a few more lines of code.
Overall I like GraphQL a lot because it allows the frontend to make less round trips to the server and makes it easier to exclude data you don't want (which helps when data is large). Json:API tries to solve some of this with includes, related, and fields but it doesn't quite allow as much expressiveness as GraphQL.
For read and search operations I typically rate limit per machine based on probability that machine gets hit using machine signature. And as a secondary (more leniant metric, just IP).
I don't centrally track rates unless a signature comes close to 1/N the limit where N is the number of nodes. At which point I will talk to the other nodes Peer to Peer.
Can still be abused but works pretty well most of the time. It also doesn't work if you have a number of nodes that is approximating your rate limit because if you do, you hit 1/N on request #1.
For that reason I tend to choose pretty lenient rate limits (call it one request a second with bursts in a 5 minute window)
For write I use OAuth2 with bearer tokens being a JWT token with a short expiry. I only need to maintain a blacklist of invalidated tokens for the length of the expiry. Rate limiting would work the same way as reads.
I don't think it is either of. I use both. In the same API. The two are largely compatible.
All REST APIs can be modeled in RPC style APIs and that's no different with GraphQL.
I've done APIs where I have a GraphQL facade in front of REST and REST Facades infront of GraphQL by having all my REST endpoints be two lines
1. Graph QL query
2. Format result as REST
That first like maps to a graphQL query and the second one can be standardized for all your REST endpoints.
I tend to like REST in-front of GraphQL better since it allows for some performance optimizations when you know ahead of time all the data you need to grab.
And since GraphQL can be mapped to classes you could also just skip the GraphQL query compile and use the classes directly from your REST with only a few more lines of code.
Overall I like GraphQL a lot because it allows the frontend to make less round trips to the server and makes it easier to exclude data you don't want (which helps when data is large). Json:API tries to solve some of this with includes, related, and fields but it doesn't quite allow as much expressiveness as GraphQL.