3 ms·
You do realize there's no reason a rest endpoint can't support doing this. My endpoints take a 'fields' parameter... and those fields can themselves be seriali
by ehutch79 6y ago
You do realize there's no reason a rest endpoint can't support doing this.
My endpoints take a 'fields' parameter... and those fields can themselves be serialized objects.
- jiofih 6y agoVery lazy thinking. It doesn’t have types, do introspection, batching, granular caching, access control... I suggest reading the GraphQL introduction post for a start: https://engineering.fb.com/2015/09/14/core-data/graphql-a-data-query-language/ https://engineering.fb.com/2015/09/14/core-data/graphql-a-da...
- verdverm 6y agoThese things have overhead and access control is more difficult to reason about and implement with resolvers and nested query resolving.
- jiofih 6y agoThat may be true, but has no bearing on the fact that being able to add a “fields” param is not by any measure an alternative to what GraphQL provides.
- atom_arranger 6y agoThe problem with this is the “my endpoint” part. This functionality is automatically part of every GraphQL API, and it is consistent. The same issue applies to types and documentation, you can do it with REST, but it’s inconsistently done.