I'm not against using DB objects as an API in small doses, but in defense of GQL what about:
Client side caching
Subscriptions
Authorization & Authentication - stuck with w/e rdbms provides you here rather than being able to choose your A&A solution.
Deeply nested data - duplicate data or you do multiple queries
Business logic in DB - complex backwards compatibility views, CASE statements scattered all over the place, ugly ass row level permissions. All good to say it's avoidable or maybe you don't care, but I prefer not to deal with it at all (dealt with db objects as API for several years, wasn't...parra pa pa paaa lovin' it, so to say)
Client side caching
Subscriptions
Authorization & Authentication - stuck with w/e rdbms provides you here rather than being able to choose your A&A solution.
Deeply nested data - duplicate data or you do multiple queries
Business logic in DB - complex backwards compatibility views, CASE statements scattered all over the place, ugly ass row level permissions. All good to say it's avoidable or maybe you don't care, but I prefer not to deal with it at all (dealt with db objects as API for several years, wasn't...parra pa pa paaa lovin' it, so to say)