I’ve been using GraphQL for about 2 years now. I’ve been using relational dbs for a long, long time. What I don’t understand is the intended way to use the two together. The summary of my problem is essentially how GQL allows you to ask for what you want, and how that is supposed to translate to your API & DB operations.
Suppose you have a set of user tables. Let’s imagine there are many, many tables.
| User |
id | firstname | lastname | age
-----------------------------------
1 | Billy | Bones | 23
| UserAddress |
id | userid | country | street | postal
-----------------------------------------
1 | 1 | USA | 123 str| 90120
| UserAccount |
id | userid | email | password | date
-----------------------------------------
1 | 1 | [email protected] | 12345 | 1614...
Now you have a GQL resolver
class UserResolver {
// Query
getUser(id){
return database.getUser(id)
}
// Field resolver
address(userId){
return database.getUserAddress(userId)
}
// Field resolver
account(userId){
return database.getUserAccount(userId)
}
// More field resolvers...
}
I love this design because you can ask for what you want. But ultimately, for database and even just API performance, it would be terrible. What you’d really want is for getUser to return a left join on all user tables, then use GQL naturally to select what fields you want, right? But what if in 90% of cases, all your frontend or consumers ever care about is the user’s first and last name? I’m struggling to understand how to maintain usability with GQL and performance with SQL (or even non sql).
This is an extremely simplified example. There would be cases where on more complex objects and tables, the joins may be more involved and the data requested from a consumer may be spread across a few tables. It’s so easy to just write one REST point dedicated to that query, but here it feels like we are trying to support "everything" which would be so easy with field resolvers that just make new DB requests, but somehow be performant at the same time.
