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.

A REST API can also give only the fields you need if coded accordingly. My REST APIs will accept this https://apibaas.io/endpoint for a response with all the fields, this https://apibaas.io/endpoint?fields=a,b,c,d for a response with only the specified fields, or https://apibaas.io/endpoint?except_fields=e.

A REST API can also aggregate results from several entities if you want, you just need to code accordingly.

Developers just need to have an open mindset and not blindly follow the herd. Also, follow API design first approach and use the tools at your disposal to design the API with OpenAPI specs. After you are happy with your API design give it to your consumers and address their feedback in the specification before you start to code the implementation, and repeat this as many times as needed until the API specification is beneficial for both the developers implementing it and the ones consuming it. During this API design first process you will discover many issues with your initial idea to solve the business requirements, thus saving you from discovering them after having already some thousands lines of code written.

In a REST API you have OpenAPI specs that when done properly (follow always design first approach) will allow you to:

• auto generate client SDKS (client API generation)
• auto generate mock servers (frontend team can work in isolation of the backend team)
• create automated tests for contract acceptance between client and server
• automate validation of incoming requests against the specification. This is huge from a security point of view. If the request isn’t in the format allowed in the specification you can refuse it, thus making it a lot harder for attackers to run fuzzing tools against your API in order to breach and exploit it.
• automate user input validation.