2 ms·
> You'll also lose a lot of control over your queries which was a big reason for me to move from Django/Rails/etc. style tools to trying out GraphQL. For restr
by aocvr 9y ago
> You'll also lose a lot of control over your queries which was a big reason for me to move from Django/Rails/etc. style tools to trying out GraphQL.
For restricting queries, an option is using persisted queries (e.g. https://dev-blog.apollodata.com/persisted-graphql-queries-with-apollo-client-119fd7e6bba5 https://dev-blog.apollodata.com/persisted-graphql-queries-wi...).
The idea is nice, having full control in development while locking down allowed queries in production.
You'd still have to deal with the problems you mentioned in development, some of which are indeed a little ugly (at least currently).
- elnygren 9y agoActually, my point was about losing control over queries when using JoinMonster (say, you wanna do something fancy like Postgres' to_json, array_agg that JoinMonster doesn't support). However, I totally understand the confusion in my sentence and actually this thing you're talking about is also useful to me :)