5 ms·

GraphiQL: GraphQL’s Killer App?

88 points by dschafer 11y ago

deleted 11y ago
[deleted]
dexwiz 11y ago
I am not sure why editors think a mark up is a good experience. Recently I have seen several editors that have markup on one side, and a formatted/stylized output on the editor. The output only sometimes feeds back to the markup, and usually does not have full functionality. This ends up being slow most of the time, and clicking/dragging/expanding text is not a good experience. They only thing they provide is validation feedback. But you still have worry about closure, indentation, formatting, etc. I usually default to using a light text editor and a shell watching validation. Is everyone so sick of Windows forms that we can only edit text now? No GUI?
DIVx0 11y ago
I am building a GraphQL service to act as a endpoint-to-rule-them-all and GraphiQL has helped me sell the concept very well. It is much easier to talk about how queries work when a developer can just jump right in and start playing with it without having to setup any tooling or whatnot.
olalonde 11y ago
On a related note, http://editor.swagger.io http://editor.swagger.io & http://petstore.swagger.io http://petstore.swagger.io provide a similar UI for exploring REST APIs which have an OpenAPI (formerly known as Swagger) specification.
- moatra 11y ago
  When did the rename happen?
  - olalonde 11y ago
    I'm not sure, just found out myself few days ago. I believe this is the original announcement was in November: http://www.linuxfoundation.org/news-media/announcements/2015/11/new-collaborative-project-extend-swagger-specification-building http://www.linuxfoundation.org/news-media/announcements/2015...
daurnimator 11y ago
Things like postman (https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop?hl=en https://chrome.google.com/webstore/detail/postman/fhbjgbifli...) exist for normal REST APIs. But it's lack of use suggests to me this isn't something people need.
- jesstaa 11y ago
  Interactively querying REST APIS is a massive pain, doing anything useful requires multiple dependent queries, postman doesn't really help with that. Being able to query a graph interactively is actually useful, I've used graphiql to explore the data graph to figure out the query I need for the data requirements of a component before I start writing the actual component itself.
  - davedx 11y ago
    > doing anything useful requires multiple dependent queries That really depends on your API! We have an orchestration layer that exists specifically so our front end does not have to run multiple queries all the time. Most of what our front end does is by running a very small handful of queries. I think orchestration layers are something most growing/larger orgs strive for, in my experience.
    - jesstaa 11y ago
      If it's actually a REST API then it's going to take multiple queries. Certainly you can put an non REST API in front of it to reduce the queries. Every site does it and every site does it in a different way. GraphQL is built to solve this exact problem in a standard way.
      - goldbrick 11y ago
        https://news.ycombinator.com/item?id=9280223 https://news.ycombinator.com/item?id=9280223 What even uses GraphQL, other than Facebook?
- 11y ago
javajosh 11y ago
Am I the only one who designs endpoints to spit back usage instructions if you call them without arguments? This goes a long way toward helping devs use those endpoints, in my experience - and they can use normal tools (in particular, the network pane of Chrome Dev tools). This is not to take away from GraphiQL, but it doesn't seem like that much more than you get with such a convention.
- techdragon 11y ago
  No you're not the only one. But I do fear we may be some sort of "silent minority". I always felt that having human and machine readable instructions was part of trying to achieve "proper" REST, the full HEOTAS or whatever the acronym is. I admire the principle and the outcomes it strives for, but very much dislike the "wankery" that goes on over the topic sometimes.
- davedx 11y ago
  I've not seen this practice very much in my experience; most API's I've worked with go the "automated documentation generation" route and host the docs somewhere separate instead. This does mean you don't need tooling just to find out how to use the API. This is distinct from throwing exceptions when an endpoint is called with e.g. invalid parameters.

88 points by dschafer 11y ago

deleted 11y ago

[deleted]

I am not sure why editors think a mark up is a good experience. Recently I have seen several editors that have markup on one side, and a formatted/stylized output on the editor. The output only sometimes feeds back to the markup, and usually does not have full functionality. This ends up being slow most of the time, and clicking/dragging/expanding text is not a good experience. They only thing they provide is validation feedback. But you still have worry about closure, indentation, formatting, etc. I usually default to using a light text editor and a shell watching validation. Is everyone so sick of Windows forms that we can only edit text now? No GUI?

DIVx0 11y ago

I am building a GraphQL service to act as a endpoint-to-rule-them-all and GraphiQL has helped me sell the concept very well. It is much easier to talk about how queries work when a developer can just jump right in and start playing with it without having to setup any tooling or whatnot.

olalonde 11y ago

On a related note, http://editor.swagger.io http://editor.swagger.io & http://petstore.swagger.io http://petstore.swagger.io provide a similar UI for exploring REST APIs which have an OpenAPI (formerly known as Swagger) specification.

moatra 11y ago
When did the rename happen?
- olalonde 11y ago
  I'm not sure, just found out myself few days ago. I believe this is the original announcement was in November: http://www.linuxfoundation.org/news-media/announcements/2015/11/new-collaborative-project-extend-swagger-specification-building http://www.linuxfoundation.org/news-media/announcements/2015...

daurnimator 11y ago

Things like postman (https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop?hl=en https://chrome.google.com/webstore/detail/postman/fhbjgbifli...) exist for normal REST APIs. But it's lack of use suggests to me this isn't something people need.

jesstaa 11y ago
Interactively querying REST APIS is a massive pain, doing anything useful requires multiple dependent queries, postman doesn't really help with that. Being able to query a graph interactively is actually useful, I've used graphiql to explore the data graph to figure out the query I need for the data requirements of a component before I start writing the actual component itself.
- davedx 11y ago
  > doing anything useful requires multiple dependent queries That really depends on your API! We have an orchestration layer that exists specifically so our front end does not have to run multiple queries all the time. Most of what our front end does is by running a very small handful of queries. I think orchestration layers are something most growing/larger orgs strive for, in my experience.
  - jesstaa 11y ago
    If it's actually a REST API then it's going to take multiple queries. Certainly you can put an non REST API in front of it to reduce the queries. Every site does it and every site does it in a different way. GraphQL is built to solve this exact problem in a standard way.
    - goldbrick 11y ago
      https://news.ycombinator.com/item?id=9280223 https://news.ycombinator.com/item?id=9280223 What even uses GraphQL, other than Facebook?
11y ago

javajosh 11y ago

Am I the only one who designs endpoints to spit back usage instructions if you call them without arguments? This goes a long way toward helping devs use those endpoints, in my experience - and they can use normal tools (in particular, the network pane of Chrome Dev tools). This is not to take away from GraphiQL, but it doesn't seem like that much more than you get with such a convention.

techdragon 11y ago
No you're not the only one. But I do fear we may be some sort of "silent minority". I always felt that having human and machine readable instructions was part of trying to achieve "proper" REST, the full HEOTAS or whatever the acronym is. I admire the principle and the outcomes it strives for, but very much dislike the "wankery" that goes on over the topic sometimes.
davedx 11y ago
I've not seen this practice very much in my experience; most API's I've worked with go the "automated documentation generation" route and host the docs somewhere separate instead. This does mean you don't need tooling just to find out how to use the API. This is distinct from throwing exceptions when an endpoint is called with e.g. invalid parameters.