[lipanski]

> Give me all users whose phone number starts with 555

There's no magic there, it's left up to you whether you expose such functionality and you are in full control of all fields that make up your API. Most of the time your APIs will reflect your database associations `{ users { posts { comments } } }` which should be indexed anyway. Custom queries on top of that, like a search filter, can be indexed/optimized individually. Resources can be paginated quite easily and you can also enforce a maximum depth when requesting associations, so that you don't end up with requests too large to deliver.

The main problem with GraphQL comes from the many different ways you can use it, which makes caching or eager loading difficult.

[barumi]

> Most of the time your APIs will reflect your database associations `{ users { posts { comments } } }` which should be indexed anyway.

That's not exposing database associations. At most that's exposing aspects of the domain model which are also reflected in the persistence model.

[cratermoon]

But how often does your persistence model really reflect the domain model that accurately? In going from domain to relational at least, you pick up a lot of details that are key to relational modeling but are irrelevant to the domain model, as in the indexing here.

As best I can tell from my limited experience, GraphQL is just exposing the bones of your relational schema without giving it much domain behavior. It's the software equivalent of offering a grocery store full of ingredients when all the hungry person wants is a sandwich.

[Kiro]

What do you mean?

[rrook]

(Not OP)

The example `{ users { posts { comments } } }` reflects that in the abstract modeling of a message board, this relationship exists. The representation of this relationship will change depending on the database implementation; a document db may store the data explicitly in the hierarchical form, while a relational db would store them with a series of joins.

[cs-szazz]

I see, thanks for the explanation! I think a lot of my coworkers think of GraphQL as some magic where it lets the client query for arbitrary things and avoid us having to add query parameters where appropriate, so I never got the whole picture. It sounds like the main benefit over REST isn't so much the queries themselves, but being able to control what data you get back, which is more in line with the article.

[pzduniak]

You can still have that magic, I've done that in a couple projects and it's certainly possible. Unfortunately implementing something "good enough" might get super expensive depending on your data model and security constraints.

[mleo]

You can use tools that will automatically generate GraphQL schema and operations from a database or it should be you design the schema & operations and control how the queries and mutations operate. The former is where some of the original concerns may come from, but the latter isn’t different from REST design.

[cs-szazz]

The former would be something like Hasura right? As a backend dev, I get nervous when I see a tagline like "Instant GraphQL APIs for you data", because I worry about the schema and operations that are exposed.

[slow_donkey]

Yes it'd be like Hasura.

There's also libraries (usually in-house) that let you query for every relation off that specific table. You can imagine how it works just match up the fks and expose in the graphql schema. That gives you control of what not to expose as well.

[elitan]

You need to set permissions manually for every GraphQL operation to be exposed with Hasura.

I think backend devs should be more worried about loosing 75% of their work when it comes to Hasura.