> > It doesn't support map/tables/dictionaries. This is actually huge. I get that there might be some pattern where you don't want to allow this but for the majority of situations working with json api's you'll end up with a {[key: string] : T} somewhere
> unions
Then you need to know the keys in advance
> embedded types, and custom resolvers
That is "kind of" cheating. I think OP meant a builtin type.
> OR better api design
Sometimes possible but not always.
It's a valid criticism. Emulating another http endpoint in graphql should be super simpel in the best case, but sometimes it is not.
Another example where that is true is union inputs - you can define and return a union of types, but you cannot accept the exact same union in a mutation. Very very unfortunate.
> unions
Then you need to know the keys in advance
> embedded types, and custom resolvers
That is "kind of" cheating. I think OP meant a builtin type.
> OR better api design
Sometimes possible but not always.
It's a valid criticism. Emulating another http endpoint in graphql should be super simpel in the best case, but sometimes it is not.
Another example where that is true is union inputs - you can define and return a union of types, but you cannot accept the exact same union in a mutation. Very very unfortunate.