5 ms·

The author of the paper forgets, that asking the API to only return specific attributes of an object(tree) instead all of them, can also be achieved with Rest.

The author of the paper forgets, that asking the API to only return specific attributes of an object(tree) instead all of them, can also be achieved with Rest. e.g. /api/v1/getUser?id=1234&return=name,zipCode,workplace.address,workplace.zipCode Not sure if that has changed in the meanwhile, but when I tried GraphQL for the first time it was obvious for me, that every service call has to be implemented by hand. Depending on what functionality is required, implementations of service calls can get quite complicated. As someone coming from Java where we have ORM frameworks and tools like Spring, I was surprised that Facebook didn't come up with something better. But hey it's Facebook. A company where the CEO thinks it's cool maintaining a huge codebase mostly written in PHP and C(++).

munk-a 7y ago
Eeeeh, I hit the question of if I should take an approach like that recently and I think that writing out a custom format like that makes your code brittle and is generally poor at scaling across endpoints. We were actually considering one of the graphQl look-a-likes to step directly into a pre-rolled format for declaring the fields expected in the response rather than roll our own format. You absolutely can define reports as graphQl entities (and really, table -> entity mapping should never be 1to1) and just let users leverage the field filtering component of the transit format. Lastly, PHP is pretty sweet now a days you should give it a try!
atombender 7y ago
You'll end up inventing your own ad-hoc GraphQL that way. For example, GraphQL supports this, trivially: query User { user(id: "123") { id name topPosts(limit: 10) { id, title } drafts: comments(published: false) { id, body } friends { id photo(size: "100x100") { url, width, height } } newestPosts(since: "3days", categories: ["news", "chat"]) { id, title forum { id, name } creator { id, photo(size: "100x100") { url, width, height } } } } latestNews(limit: 10) { title, url } } All one query. Selecting a subset of attributes is a small part of GraphQL. (gRPC also allows you filter fields, but doesn't have structured querying.) GraphQL is a protocol and a schema language, not an ORM. It's a way to provide a common interface on top of any implementation. For example, in the above query, users could be in the backend's own database, whereas "friends" could be something stored in a completely different backend. The GraphQL server could trivially act as a façade that federated/aggregated the results of both. I would argue that GraphQL fulfills the objectives (or at least desired features) of REST much better than what has been delivered thus far. For example, REST's hypermedia aspect ("HATEOAS") has not been widely adopted — because discoverability is poor and there's no standard protocol for introspecting a schema. But look around and you can easily find a dozen different GraphQL clients (my personal favourite being Prisma's GraphQL Playground [1]) that can be pointed at any GraphQL-compliant server to run queries and browse the schema. Those that criticize GraphQL generally don't seem to realize how simple it is, and how close it's still to the REST style of consuming and producing JSON. [1] https://github.com/prisma/graphql-playground https://github.com/prisma/graphql-playground
- jayd16 7y ago
  I'd argue that the growing popularity of Swagger/OpenAPI is close enough to HATEOAS as we want to get.
  - trumpeta 7y ago
    Swagger/OpenAPI is very fragmented, it builds on JSON Schemas by adding some properties and removing others, then on top of that the AWS API Gateway again removes some options and adds others. Its a total mess trying to navigate which features I can and can not use.

munk-a 7y ago

Eeeeh, I hit the question of if I should take an approach like that recently and I think that writing out a custom format like that makes your code brittle and is generally poor at scaling across endpoints. We were actually considering one of the graphQl look-a-likes to step directly into a pre-rolled format for declaring the fields expected in the response rather than roll our own format. You absolutely can define reports as graphQl entities (and really, table -> entity mapping should never be 1to1) and just let users leverage the field filtering component of the transit format. Lastly, PHP is pretty sweet now a days you should give it a try!

atombender 7y ago

You'll end up inventing your own ad-hoc GraphQL that way. For example, GraphQL supports this, trivially: query User { user(id: "123") { id name topPosts(limit: 10) { id, title } drafts: comments(published: false) { id, body } friends { id photo(size: "100x100") { url, width, height } } newestPosts(since: "3days", categories: ["news", "chat"]) { id, title forum { id, name } creator { id, photo(size: "100x100") { url, width, height } } } } latestNews(limit: 10) { title, url } } All one query. Selecting a subset of attributes is a small part of GraphQL. (gRPC also allows you filter fields, but doesn't have structured querying.) GraphQL is a protocol and a schema language, not an ORM. It's a way to provide a common interface on top of any implementation. For example, in the above query, users could be in the backend's own database, whereas "friends" could be something stored in a completely different backend. The GraphQL server could trivially act as a façade that federated/aggregated the results of both. I would argue that GraphQL fulfills the objectives (or at least desired features) of REST much better than what has been delivered thus far. For example, REST's hypermedia aspect ("HATEOAS") has not been widely adopted — because discoverability is poor and there's no standard protocol for introspecting a schema. But look around and you can easily find a dozen different GraphQL clients (my personal favourite being Prisma's GraphQL Playground [1]) that can be pointed at any GraphQL-compliant server to run queries and browse the schema. Those that criticize GraphQL generally don't seem to realize how simple it is, and how close it's still to the REST style of consuming and producing JSON. [1] https://github.com/prisma/graphql-playground https://github.com/prisma/graphql-playground

jayd16 7y ago
I'd argue that the growing popularity of Swagger/OpenAPI is close enough to HATEOAS as we want to get.
- trumpeta 7y ago
  Swagger/OpenAPI is very fragmented, it builds on JSON Schemas by adding some properties and removing others, then on top of that the AWS API Gateway again removes some options and adds others. Its a total mess trying to navigate which features I can and can not use.