3 ms·

Hi there, thanks for the comment. Author here. No, poor technical user is not the entire premise. What I was trying to convey is to give the reader a chance to

Hi there, thanks for the comment. Author here. No, poor technical user is not the entire premise. What I was trying to convey is to give the reader a chance to reevaluate the decision to send parameters that way, rather than trying to accept it as it is. It is hard for experienced people to think that way because they have become accustomed, but most of the time, in programming, we don't realize simpler solutions are possible. It helps to reevaluate from the eyes of a beginner. Rich Hickey has a great talk on this called Simple Made Easy: http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy > web application The blog post mentions getting an article, but basically the web applications nowadays move complexity to the client and see the server as a single API. Having that as a single URL is the natural derivation of that. Any request queries or mutations are sent to that URL. I have updated the demo link so that it now starts with a real query, rather than an empty page. See an example at: http://bit.ly/1Qa4h00 http://bit.ly/1Qa4h00

pdkl95 11y ago
> we don't realize simpler solutions are possible I'm not seeing a "simpler solution" - your URL is far more complex, and is probably even harder to parse by people that have learned how URLs work. Making non-technical people learn yet another new way to do things isn't helping. Also, at some point, you're just going to have a complicated interface. T > move complexity to the client It's not your computer, so you don't get to decide how the client handles the page. If you want your content to be read, try actually sending it. Note that this is a statement of fact, not an opinion about how I wish computers worked. You do not know what the client is doing when it renders a page (adblocking is a common example), so moving complexity to the client unnecessarily is risky. So far I'm still only seeing a search interface, which is (by definition) purely server side. > sent to that URL Ok, I think I get what you're excited about: you're reinventing #respond_to/#respond_with[1], so the URL can be reused for different mime-types. [1] http://edgeapi.rubyonrails.org/classes/ActionController/Responder.html http://edgeapi.rubyonrails.org/classes/ActionController/Resp... > rather than an empty page. (by the way - curl complains about that URL. Something about bracket? It may be some advanced feature of curl? No matter, wget is fine) $ wget -O /tmp/page.html 'http://graphql-swapi.parseapp.com/?query=%23%20Welc ... %0A}' $ </tmp/page.html sed -ne '/<body>/,/<\/body>/ p' | sed -e '/<script>/,/<\/script>/ d' <body> </body> It's still an empty page.
- ludwigvan 11y ago
  Try this: curl 'http://graphql-swapi.parseapp.com' \ -H 'content-type: application/json' \ --data-binary '{"query":"{ allFilms(first: 3) { films { title, director } }}"}' The query param is just for easy sharing online when you build a query.
  - belovedeagle 11y ago
    > The query param is just for easy sharing online when you build a query. Gee, if only there were a way to encode that data into the URL itself without embedding an almost-JSON document! Someone should invent something like that.
    - trowawee 11y ago
      Get outta here, that's nuts.

pdkl95 11y ago

> we don't realize simpler solutions are possible I'm not seeing a "simpler solution" - your URL is far more complex, and is probably even harder to parse by people that have learned how URLs work. Making non-technical people learn yet another new way to do things isn't helping. Also, at some point, you're just going to have a complicated interface. T > move complexity to the client It's not your computer, so you don't get to decide how the client handles the page. If you want your content to be read, try actually sending it. Note that this is a statement of fact, not an opinion about how I wish computers worked. You do not know what the client is doing when it renders a page (adblocking is a common example), so moving complexity to the client unnecessarily is risky. So far I'm still only seeing a search interface, which is (by definition) purely server side. > sent to that URL Ok, I think I get what you're excited about: you're reinventing #respond_to/#respond_with[1], so the URL can be reused for different mime-types. [1] http://edgeapi.rubyonrails.org/classes/ActionController/Responder.html http://edgeapi.rubyonrails.org/classes/ActionController/Resp... > rather than an empty page. (by the way - curl complains about that URL. Something about bracket? It may be some advanced feature of curl? No matter, wget is fine) $ wget -O /tmp/page.html 'http://graphql-swapi.parseapp.com/?query=%23%20Welc ... %0A}' $ </tmp/page.html sed -ne '/<body>/,/<\/body>/ p' | sed -e '/<script>/,/<\/script>/ d' <body> </body> It's still an empty page.

ludwigvan 11y ago
Try this: curl 'http://graphql-swapi.parseapp.com' \ -H 'content-type: application/json' \ --data-binary '{"query":"{ allFilms(first: 3) { films { title, director } }}"}' The query param is just for easy sharing online when you build a query.
- belovedeagle 11y ago
  > The query param is just for easy sharing online when you build a query. Gee, if only there were a way to encode that data into the URL itself without embedding an almost-JSON document! Someone should invent something like that.
  - trowawee 11y ago
    Get outta here, that's nuts.