Hell no. Having used both graphql and rest apis, graphql is NOT a silver bullet. It has many downsides (harder to debug from the browser, terrible error handling, more complicated to build security rules around certain days points, etc), and only one big advantage: neer infinite customizability of requests by the client code.
If you are making a public API with a wide range of consumers and possible use cases, graphql is a good choice to consider. If you're creating an API that's only being used by your apps, or has limited use cases, stick with traditional REST. They are different tools for different jobs.
Hell no. Having used both graphql and rest apis, graphql is NOT a silver bullet. It has many downsides (harder to debug from the browser, terrible error handling, more complicated to build security rules around certain days points, etc), and only one big advantage: neer infinite customizability of requests by the client code.
If you are making a public API with a wide range of consumers and possible use cases, graphql is a good choice to consider. If you're creating an API that's only being used by your apps, or has limited use cases, stick with traditional REST. They are different tools for different jobs.
yes, that's why I mentioned use cases for Graphql and said that Graphql is not always the best solution.