4 ms·
One critique I haven't seen about GraphQL is that it's less human-readable. I know that "GraphQL is unapologetically driven by the requirements of views and the
by faitswulff 8y ago
One critique I haven't seen about GraphQL is that it's less human-readable. I know that "GraphQL is unapologetically driven by the requirements of views and the front‐end engineers that write them"[0], but if everything switched to GraphQL endpoints, I'd miss having URLs you could change by hand :/
[0]: https://facebook.github.io/graphql/October2016/#sec-Overview https://facebook.github.io/graphql/October2016/#sec-Overview
- masklinn 8y ago> I'd miss having URLs you could change by hand :/ URLs you can change by hand in API calls? When I'm at that level, I can just as easily edit the call body. > One critique I haven't seen about GraphQL is that it's less human-readable. My experience is the opposite, reading a complete graphql query is way easier than reading a mix of URL, query parameters and entity body, even more so when I need multiple such queries to replace a single graphql query. And the query tells me exactly what's in the result, to boot, so it acts as documentation for the data-extraction code.
- phaedryx 8y agoAgreed. I love being able to say "this is the data I want and the shape I want it in" and being able to get exactly that back.
- faitswulff 8y ago> URLs you can change by hand in API calls? No, that's not what I meant. I meant that RESTful APIs relate the URL to the data in a way that isn't true in GraphQL APIs. Take reddit, for instance. I can clearly see a username in the url: https://www.reddit.com/user/masklinn https://www.reddit.com/user/masklinn Swapping one out behaves as I'd expect: https://www.reddit.com/user/faitswulff https://www.reddit.com/user/faitswulff And tacking on a format type to the end exposes the content in the manner I'd expect: https://www.reddit.com/user/masklinn.json https://www.reddit.com/user/masklinn.json The conflation of route and content is frustrating for developing single page apps, but it maps better to my understanding of disk files and folders, thus making the URL more human readable and easier to toggle and change by hand. If everything was an SPA, you'd have to interact with the data through the frontend, which speaks to some singular GraphQL endpoint, hence my mentioning that GraphQL itself mentions that it is "unapologetic" about its front-end orientation.
- jazoom 8y agoDid you think about masklinn's comment for 5 minutes before replying?
- faitswulff 8y agoI came back to edit the snark out.
- jazoom 8y agoThat's why pencils have erasers. :-)
- jazoom 8y agoI can only assume that the people downvoting this comment didn't see the comment I replied to before it was edited. The "5 minutes" thing was a direct reference.
- masklinn 8y ago> No, that's not what I meant. I meant that RESTful APIs relate the URL to the data in a way that isn't true in GraphQL APIs. So 1. you're talking about something completely unrelated to TFA and 2. you're talking nonsense. > Take reddit, for instance. I can clearly see a username in the url: https://www.reddit.com/user/masklinn https://www.reddit.com/user/masklinn That's a UI component, and an explicit decision of the system's designers. It, again, has nothing do do with APIs. Hell, it doesn't even have anything to do with RESTful systems, https://www.reddit.com/lfskfsh8432kdb60 https://www.reddit.com/lfskfsh8432kdb60 would be just as RESTful. > The conflation of route and content is frustrating for developing single page apps, but it maps better to my understanding of disk files and folders, thus making the URL more human readable and easier to toggle and change by hand. Cool, so use that for situations where direct human interactions is expected or convenient, what's the issue? > If everything was an SPA, you'd have to interact with the data through the frontend Which you already do, the URL is part of the frontend. And using SPAs does not preclude providing nice (and user-friendly) URLs e.g. with https://developer.mozilla.org/en-US/docs/Web/API/History https://developer.mozilla.org/en-US/docs/Web/API/History