The two places where I think GraphQL really shines is:

1. Frontend and backend team is kind of separated. Can make it easier for them to work more decoupled (for example frontend can skip fetching one field no longer needed without having to wait for the backend team to remove it and backend can add new fields without having to wait for frontend).

2. You fetch similar data in many places but in different formats. So you might need all fields in one place and in other places you just need some of the fields. Instead of overfetching or having lots of extra endpoints graphql makes it easier since you can fetch what you need all from the same endpoint.

Big negative for me is that graphql is harder to cache and a bit more complex to setup (both frontend and backend) compared to REST. So if it is a simple app (in the sense that it doesn’t fetch a lot of different stuff everywhere) I go for REST but if it is a complex project I might go for graphql.

Yeah, hard agree here. Nowadays you can compose a good OpenAPI file and you get an awesome interactive UI with which you can browse your REST API. Not to mention that your openapi.yml (or openapi.json) can be used to automatically generate clients for your API as well.

GraphQL I’ve mostly seen defended by frontend teams that find it easier to work with because they are its consumers. For the backenders it’s definitely extra work.

One thing I’ll absolutely give GraphQL props for however is – good detailed data schema. We need more of that, like literally everywhere.

Definitely harder to cache. I would almost never use graphql personally. I think automatic documentation generation and client generation + rest + a little json API could cover 90% of uses cases.