| |
| ▲ | wrs a day ago | parent | next [-] | | It doesn’t actually require that second part. Every time I’ve used it in a production system, we had an approved list of query shapes that were accepted. If the client wanted to use a new kind of query, it was performance tested and sometimes needed to be optimized before approval for use. If you open it up for any possible query, then give that to uncontrolled clients, it’s a recipe for disaster. | | |
| ▲ | kaoD a day ago | parent | next [-] | | Oh, we have that too! But we call it HTTP endpoints. | | |
| ▲ | wrs a day ago | parent | next [-] | | GQL is an HTTP endpoint. The question is, how are you schematizing, documenting, validating, code-generating, monitoring, etc. the request and response on your HTTP endpoints? (OpenAPI is another good choice.) | |
| ▲ | johnfn a day ago | parent | prev [-] | | Really? Hmm... where in the HTTP spec does it allow for returning an arbitrary subset of any specific request, rather than the whole thing? And where does it ensure all the results are keyed by id so that you can actually build and update a sensible cache around all of it rather than the mess that totally free-form HTTP responses lead to? Oh weird HTTP doesn't have any of that stuff? Maybe we should make a new spec, something which does allow for these patterns and behaviors? And it might be confusing if we use the exact same name as HTTP, since the usage patterns are different and it enables new abilities. If only we could think of such a name... | | |
| ▲ | eli a day ago | parent | next [-] | | An HTTP Range request asks the server to send parts of a resource back to a client. Range requests are useful for various clients, including media players that support random access, data tools that require only part of a large file, and download managers that let users pause and resume a download. https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Ran... | | |
| ▲ | johnfn a day ago | parent | next [-] | | HTTP Range doesn't have anything to do with allowing a client to select a subset of fields. | | |
| ▲ | eli a day ago | parent [-] | | The Range header isn't for requesting a subset of a resource from the server? | | |
| ▲ | johnfn 20 hours ago | parent [-] | | Let's say your REST endpoint returned an object with keys foo, bar, baz and quuz. How would you use HTTP Range to only select foo and baz? |
|
| |
| ▲ | 867-5309 a day ago | parent | prev [-] | | also handy for bypassing bandwidth restrictions: capped at 100kbps? launch 1000 workers to grab chunks then assemble the survivors | | |
| |
| ▲ | tlarkworthy a day ago | parent | prev [-] | | Etag and cache control headers? |
|
| |
| ▲ | awesome_dude a day ago | parent | prev | next [-] | | Without wishing to take part in a pile on - I am wondering why you're using graphql if you are kneecapping it and restricting it to set queries. | | |
| ▲ | wrs a day ago | parent | next [-] | | Because it solves all sorts of other problems, like having a well-defined way to specify the schema of queries and results, and lots of tools built around that. I would be surprised to see many (or any) GQL endpoints in systems with significant complexity and scale that allow completely arbitrary requests. | | |
| ▲ | lkbm a day ago | parent | next [-] | | Shopify's GraphQL API limits you in complexity (essentially max number of fields returned), but it's basically arbitrary shapes. | |
| ▲ | mattmanser a day ago | parent | prev [-] | | OpenAPI does the same thing for http requests, with tooling around it. With typed languages you can auto-generate OpenAPI schemas from your code. | | |
| ▲ | wrs a day ago | parent [-] | | Yep, OpenAPI is also a good choice nowadays. That’s typically used with the assumption you’ve chosen a supported subset of queries. With GQL you have to add that on top. |
|
| |
| ▲ | kspacewalk2 a day ago | parent | prev | next [-] | | Probably for one of the reasons graphql was created in the first place - accomplish a set of fairly complex operations using one rather than a multitude of API calls. The set can be "everything" or it can be "this well-defined subset". | | |
| ▲ | awesome_dude a day ago | parent [-] | | You could be right, but that's really just "Our API makes multiple calls to itself in the background" I could be wrong but I thought GraphQL's point of difference from a blind proxy was that it was flexible. | | |
| ▲ | wrs a day ago | parent [-] | | It is flexible, but you don’t have to let it be infinitely flexible. There’s no practical use case for that. (Well, until LLMs, perhaps!) | | |
| ▲ | awesome_dude a day ago | parent [-] | | I guess that I'm reading your initial post a little more strictly than you're meaning | | |
| ▲ | mcpeepants a day ago | parent [-] | | I think they mean something like (or what I think of as) “RPC calls, but with the flexibility to select a granular subset of the result based on one or more schemas”. This is how I’ve used graphql in the past at least. |
|
|
|
| |
| ▲ | troupo a day ago | parent | prev [-] | | > I am wondering why you're using graphql if you are kneecapping it and restricting it to set queries. Because you never want to expose unbounded unlimited dynamic queries in production. You do want a very small subset that you can monitor, debug, and optimize. |
| |
| ▲ | a day ago | parent | prev [-] | | [deleted] |
| |
| ▲ | jlouis a day ago | parent | prev [-] | | No. It's a way to transmit a program from client to server. It then executes that program on the server side. | | |
| ▲ | dcre a day ago | parent [-] | | That sounds even worse! | | |
| ▲ | jlouis 13 hours ago | parent [-] | | It's not. The fragments you can execute are limited if you do it right. A client isn't allowed to just execute anything it wants, because the valid operations are pre-determined. The client sends a reference which executes a specific pre-planned fragment of code. In development, you let clients roam free, so you have access to the API in a full manner. Deployments then lock-down the API. If you just let a client execute anything it wants in production, you get into performance-trouble very easily once a given client decides to be adventurous. GraphQL is an execution semantics. It's very close to a lambda calculus, but I don't think that was by design. I think that came about by accident. A client is really sending a small fragment of code to the server, which the server then executes. The closest thing you have is probably SQL queries: the client sends a query to the server, which the server then executes. It's fundamental to the idea of GraphQL as well. You want to put power into the hands of the client, because that's what allows a top-down approach to UX design. If you always have to manipulate the server-side whenever a client wants to change call structure, you've lost. |
|
|
|
