This is how I view graphql (despite not having used it). It seems better practice to keep the querying done in the backend and keep frontend for display logic more than anything. Seems like graphql will encourage business logic in the frontend (my current workplace has this problem and it is not something that should be encouraged).
Of course, a bad REST API may expect that you do a GET /cars and GET /users and match them in your code, which is once again business logic in the front-end and bad design. There are even many DB-To-Rest libraries that encourage exactly this, unfortunately.
A good GraphQL API could also allow you to query cars and get car.Owner.Name and car.Owner.Address without you explicitly joining (the join still happens in the backend). However, I feel that many people who choose GraphQL are trying to avoid exactly this type of logic on the backend, which would explain the popularity of DB-to-GraphQL libraries.
On the server side, assuming you have a simple CRUD service in front of a DB, you can probably use a generic GraphQL-to-DB query language library and call it a day. If you have to expose a REST API, you need to understand what's stored in the DB and create some queries, make sure they are performant etc.
Now, if you have a complex service with heterogenous data sources that you want to present homogenously, then both REST and GraphQL will be much more difficult. But even then, with GraphQL you can leave most of the hard work of figuring out how to join efficiently on the client, while with REST it's your responsibility to ensure that the requests execute in a decent amount of time.
In my own company, we use GraphQL for internal communication between a few microservices because we need the flexibility, but we expose a REST API to users, because no one wants to learn how to write queries instead of doing a simple GET on an endpoint we already expose.