4 ms·

GraphQL is the King, R-I-P Rest

16 points by gina650 10y ago

deleted 10y ago
[deleted]
niftich 10y ago
I wrote about GraphQL on here before [1]. I don't share the author's enthusiasm that it's "awesome" that "the schema is all backed by arbitrary code" -- I think this is a bad trade-off, because you still have to have some custom data-munging layer between your GraphQL acceptor and your backend datasources, just like you had to do to, but with different code, to implement a REST service. However, once canned ORMs or datastores that natively understand GraphQL (like dgraph) become available, the ecosystem will definitely enable rapid integration -- provided we keep in mind the lessons learned about user-supplied queries from the early SQL-on-the-web days. [1] https://hn.algolia.com/?query=niftich%20graphql&sort=byDate&type=comment https://hn.algolia.com/?query=niftich%20graphql&sort=byDate&...
- segphault 10y ago
  >I don't share the author's enthusiasm that it's "awesome" that "the schema is all backed by arbitrary code" -- I think this is a bad trade-off Yup, and it also forces you to sacrifice programming language portability. Kind of important in a microservice scenario where you might want to have multiple distinct services written in different languages that support the same set of GraphQL types. People don't seem to realize that there is a whole separate dedicated schema language for GraphQL that will eventually replace the mediocre embedded DSLs. The only reason the current implementations all use the embedded DSLs is because implementing a parser for the custom schema language is non-trivial. There are a lot of things that I really like about GraphQL, but I think it would have been saner if they had aimed for a way to express the schemas and queries in something like JSON that everybody already speaks.
atmartins 10y ago
What about permissions? What if the logged in user is only allowed to see certain fields? Do I make a table that describes every possible field and which roles can access it? How do I know what's available to query, without reading docs? What about hypermedia? Do I have to gain knowledge about a large system's data structure to query it?
- rkv 10y ago
  >What about permissions? What if the logged in user is only allowed to see certain fields? Do I make a table that describes every possible field and which roles can access it? GraphQL is permission agnostic which allows you to develop your own methods. But there are a lot of nice implementations floating around [1]. >How do I know what's available to query, without reading docs? Introspection[2]. 1. https://github.com/joonhocho/graphql-rule https://github.com/joonhocho/graphql-rule 2. http://graphql.org/learn/introspection http://graphql.org/learn/introspection
  - atmartins 10y ago
    I appreciate the answer. It looks like I do want to create a rule for each property. Why? Why not create meaningful objects and not micro-manage individual properties? In case I want to update my front end query in the future? Shouldn't I just make my objects more granular, rather than this extreme of managing individual properties? I'm genuinely interested from an architectural standpoint what the real gain is here, it really seems like there are major portions of a useful api that are not discussed when I've looked in to GraphQL.
gina650 10y ago
As mentioned in the first talk at the GraphQL summit (350+ attendees) Github dumped REST for GraphQL http://thenewstack.io/github-dumps-rest-graphql-api/ http://thenewstack.io/github-dumps-rest-graphql-api/ Rise of GrapQL https://www.youtube.com/watch?v=bPlOGKPLtqM&list=PLpi1lPB6opQzSSOQU8JQLExuP1JUXPtmA https://www.youtube.com/watch?v=bPlOGKPLtqM&list=PLpi1lPB6op...
dzmitry_lahoda 10y ago
Very similar. Typed. Get only requested properties. Request graph shape you want. https://www.elastic.co/guide/en/elasticsearch/guide/current/_buckets_inside_buckets.html https://www.elastic.co/guide/en/elasticsearch/guide/current/... https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping.html#_example_mapping https://www.elastic.co/guide/en/elasticsearch/reference/curr... https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-source-filtering.html https://www.elastic.co/guide/en/elasticsearch/reference/curr... And I thought ElasticSearch API is REST. And it is JSON.

16 points by gina650 10y ago

deleted 10y ago

[deleted]

I wrote about GraphQL on here before [1]. I don't share the author's enthusiasm that it's "awesome" that "the schema is all backed by arbitrary code" -- I think this is a bad trade-off, because you still have to have some custom data-munging layer between your GraphQL acceptor and your backend datasources, just like you had to do to, but with different code, to implement a REST service. However, once canned ORMs or datastores that natively understand GraphQL (like dgraph) become available, the ecosystem will definitely enable rapid integration -- provided we keep in mind the lessons learned about user-supplied queries from the early SQL-on-the-web days. [1] https://hn.algolia.com/?query=niftich%20graphql&sort=byDate&type=comment https://hn.algolia.com/?query=niftich%20graphql&sort=byDate&...

segphault 10y ago
>I don't share the author's enthusiasm that it's "awesome" that "the schema is all backed by arbitrary code" -- I think this is a bad trade-off Yup, and it also forces you to sacrifice programming language portability. Kind of important in a microservice scenario where you might want to have multiple distinct services written in different languages that support the same set of GraphQL types. People don't seem to realize that there is a whole separate dedicated schema language for GraphQL that will eventually replace the mediocre embedded DSLs. The only reason the current implementations all use the embedded DSLs is because implementing a parser for the custom schema language is non-trivial. There are a lot of things that I really like about GraphQL, but I think it would have been saner if they had aimed for a way to express the schemas and queries in something like JSON that everybody already speaks.

atmartins 10y ago

What about permissions? What if the logged in user is only allowed to see certain fields? Do I make a table that describes every possible field and which roles can access it? How do I know what's available to query, without reading docs? What about hypermedia? Do I have to gain knowledge about a large system's data structure to query it?

rkv 10y ago
>What about permissions? What if the logged in user is only allowed to see certain fields? Do I make a table that describes every possible field and which roles can access it? GraphQL is permission agnostic which allows you to develop your own methods. But there are a lot of nice implementations floating around [1]. >How do I know what's available to query, without reading docs? Introspection[2]. 1. https://github.com/joonhocho/graphql-rule https://github.com/joonhocho/graphql-rule 2. http://graphql.org/learn/introspection http://graphql.org/learn/introspection
- atmartins 10y ago
  I appreciate the answer. It looks like I do want to create a rule for each property. Why? Why not create meaningful objects and not micro-manage individual properties? In case I want to update my front end query in the future? Shouldn't I just make my objects more granular, rather than this extreme of managing individual properties? I'm genuinely interested from an architectural standpoint what the real gain is here, it really seems like there are major portions of a useful api that are not discussed when I've looked in to GraphQL.

gina650 10y ago

As mentioned in the first talk at the GraphQL summit (350+ attendees) Github dumped REST for GraphQL http://thenewstack.io/github-dumps-rest-graphql-api/ http://thenewstack.io/github-dumps-rest-graphql-api/ Rise of GrapQL https://www.youtube.com/watch?v=bPlOGKPLtqM&list=PLpi1lPB6opQzSSOQU8JQLExuP1JUXPtmA https://www.youtube.com/watch?v=bPlOGKPLtqM&list=PLpi1lPB6op...

dzmitry_lahoda 10y ago

Very similar. Typed. Get only requested properties. Request graph shape you want. https://www.elastic.co/guide/en/elasticsearch/guide/current/_buckets_inside_buckets.html https://www.elastic.co/guide/en/elasticsearch/guide/current/... https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping.html#_example_mapping https://www.elastic.co/guide/en/elasticsearch/reference/curr... https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-source-filtering.html https://www.elastic.co/guide/en/elasticsearch/reference/curr... And I thought ElasticSearch API is REST. And it is JSON.