12 ms·

I do think that using graphql will solve a lot of problems for people but it's super surprising how many people absolutely hate it.

by roflyear 10mo ago

dcre 10mo ago
GraphQL is just a typed schema (good) with a server capable of serving any subset of the entire schema at a time (pain in the ass).
- jlouis 10mo ago
  No. It's a way to transmit a program from client to server. It then executes that program on the server side.
  - dcre 10mo ago
    That sounds even worse!
    - jlouis 10mo ago
      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.
      - DenisM 10mo ago
        No one exposes SQL to clients though. I think where Gql differs from sql is it’s at a higher level. SQL bleeds performance and data layout (e.g. normalizing, limits), GraphQL does not. It’s not clear if it’s high enough to abstract knowledge from storage. In the end it’s tension between enabling client to wander around productively vs being a bull in a china shop.
- wrs 10mo ago
  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 10mo ago
    Oh, we have that too! But we call it HTTP endpoints.
    - johnfn 10mo ago
      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 10mo ago
        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/Range_requests https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Ran...
        867-5309 10mo ago
        also handy for bypassing bandwidth restrictions: capped at 100kbps? launch 1000 workers to grab chunks then assemble the survivors
koakuma-chan 10mo ago
I wish people at least stopped using JavaScript and stopped writing requests to back-end by hand.

I do think that using graphql will solve a lot of problems for people but it's super surprising how many people absolutely hate it.

dcre 10mo ago

GraphQL is just a typed schema (good) with a server capable of serving any subset of the entire schema at a time (pain in the ass).

jlouis 10mo ago
No. It's a way to transmit a program from client to server. It then executes that program on the server side.
- dcre 10mo ago
  That sounds even worse!
  - jlouis 10mo ago
    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.
    - DenisM 10mo ago
      No one exposes SQL to clients though. I think where Gql differs from sql is it’s at a higher level. SQL bleeds performance and data layout (e.g. normalizing, limits), GraphQL does not. It’s not clear if it’s high enough to abstract knowledge from storage. In the end it’s tension between enabling client to wander around productively vs being a bull in a china shop.
wrs 10mo ago
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 10mo ago
  Oh, we have that too! But we call it HTTP endpoints.
  - johnfn 10mo ago
    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 10mo ago
      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/Range_requests https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Ran...
      - 867-5309 10mo ago
        also handy for bypassing bandwidth restrictions: capped at 100kbps? launch 1000 workers to grab chunks then assemble the survivors

koakuma-chan 10mo ago

I wish people at least stopped using JavaScript and stopped writing requests to back-end by hand.