5 ms·

The problem that GraphQL was trying to resolve is real: reasonably-sized REST projects usually ended up inventing their own awkward, ad-hoc mini query languages

The problem that GraphQL was trying to resolve is real: reasonably-sized REST projects usually ended up inventing their own awkward, ad-hoc mini query languages on top of REST. But GraphQL as a solution is not great. It looks nice in the first place, but there is too much hassle to deal with. P.S. I've seen quite a fraction of GraphQL projects actually using Node.js as the backend. If that's the case I would recommend TRPC[0] over GraphQL - it's more seamless and straightforward. [0] https://trpc.io/ https://trpc.io/

francislavoie 4y ago
I use https://www.jsonrpc.org/specification https://www.jsonrpc.org/specification. I hate REST. With JSON-RPC, I can have true 1:1 mapping on both ends to how I write code, and it's transport agnostic. Doesn't rely on any language. I use PHP in the backend, TS in the frontend. There are ways to make it somewhat type safe with tools like https://open-rpc.org/ https://open-rpc.org/ but I tend to just go vanilla with it and write TypeScript types in the frontend for the results on the frontend.
- hatch_q 4y ago
  In all honesty, we do this with REST now. Just define interface with OpenAPI - then create clients, servers in virtually any language you like.
  - francislavoie 4y ago
    The problem with REST for me is that it locks you to HTTP verbs and URIs. And it's not a great mapping for much more than CRUD. I find it really restrictive and annoying. It's specific to HTTP as the transport, so I can't use REST over websockets or some raw TCP server-to-server pipe, etc, without making a kludge of it.
    - dimgl 4y ago
      This is actually really cool! Any chance you can point me to an implementation for JSON-RPC? I'm interested to see the benefits with JSON-RPC over a traditional REST API.
      - francislavoie 4y ago
        The spec explains pretty much everything you need to know. Look for a client and server implementation in your language of choice; essentially all it needs to do is decode the JSON message and validate that it uses the right structure, and handle message IDs for batching, then call your custom message handling logic. Over HTTP, basically you just have a single endpoint which always takes POST requests, and always responds with 200 status, even on errors. If you're using this in a frontend JS application, you'd want a wrapper over fetch() which rejects the promise if the RPC response has an error in the message.
015a 4y ago
I'd argue GraphQL really doesn't even solve that "mini-query-language" problem all that well. But, I'm with you; that's how its sold. Its one of the big things its proponents say. And it fails at it. Let me pick on an example of one of these rest-api-mini-query-language specs: the Microsoft Graph API, which uses OData. It supports: * Count (don't return items; return a count of them) * Expand (graph traversal on related resources) * Filter * Format * Order (sorting) * Search * Select * Skip * SkipToken * Top * A bevy of others Of these; GraphQL solves Select and Expand. That's it. Everything else INEVITABLY becomes a pseudo-odata-mini-query-language on top of GraphQL; the exact same problem REST APIs had! Pagination. Skip/limits. Response reducing/counting/analytics. Filtering. Etc. Of course, a framework has to stop somewhere. Lest you become OData, which isn't all that great to use. So, I'm not proposing that GraphQL should do more; but rather that its proponents need to stop listing this as an advantage of the framework, because its actually a disadvantage. Its only "good" at this relative to literally `npm i express`; the most basic-possible-REST-API. The REST & RPC ecosystems have a wide array of higher level tooling to select from, at every possible level of "nothing" to "everything and the kitchen sink"; GraphQL is startlingly boring in comparison, and proponents who list this as an advantage of GraphQL really aren't doing much more than admitting how little exposure they have in competing frameworks (or, similarly, how poorly APIs were built at whatever company they worked at last).
- obi1kenobi 4y ago
  I made a query language that parses as legal GraphQL using a vanilla parser, but has directives like `@filter, @recurse, @optional` etc. that make it a real query language. Also, instead of returning a giant fully-nested result, it flattens results and emits them row-by-row like a SQL database. This means the query evaluation can be lazy and incremental — if you write a query that has a billion results but only load 20 of them, then only 20 rows' worth of work happens. My company has been using this in production for 6 years now across everything from TB-scale SQL clusters with X00,000 tables/views, to querying our own codebase, configuration, and deployment information to find and prevent bugs. I gave a 10min talk at a conference about this recently, if you'd like to learn more: https://www.hytradboi.com/2022/how-to-query-almost-everythin https://www.hytradboi.com/2022/how-to-query-almost-everythin... Project GitHub: https://github.com/obi1kenobi/trustfall https://github.com/obi1kenobi/trustfall
kristiandupont 4y ago
I recently gave a talk about our experience with tRPC. So far it's looking very promising! https://www.youtube.com/watch?v=k1TCueEhhJo https://www.youtube.com/watch?v=k1TCueEhhJo
tootie 4y ago
Software architecture really needs to acknowledge the human aspect of building platforms. GraphQL is great solution to organizational problem of slow communication and/or misaligned incentives between frontend and backend teams. GraphQL is essentially a self-service approach where API developers can create a flexible, open-ended data access plane that end users can consume as they wish. That incurs a lot of extra technical complexity, but obviates a lot of organizational complexity. That could be a very valid concern if your backend is public or otherwise serves a really diverse group of clients. The most efficient and effective API integration projects I've done is where the API and frontend teams are tightly knit, working off a shared backlog and able to pass a chain of requirements from design, to contract writing, to development on both sides and get really tight alignment. That lets us create very tightly optimized REST endpoints that are very cache-friendly and can deliver precise payloads to optimize both round trips and bandwidth. It's actually easier to build because requirements are really clear, but comes at the cost of doing all that communication to align on requirements.
- dhzhzjsbevs 4y ago
  Pretty much this sums it up. I still don't understand the need for graphql. Then again, it only takes me 5 minutes to add a new endpoint that just dumps back a specific SQL query result. I think a lot of companies make adding endpoints into a big deal, often a whole new file or class with documentation and tests. An SQL query doesn't need tests. I think another part of it is that SQL still scares people. That is, I'd put graphql in the same camp as active record, orms, and other silly attempts at creating a query language to avoiding using a query language.
  - eurasiantiger 4y ago
    >An SQL query doesn't need tests. Have you ever done financial stuff on SQL? Transaction processing or even just CRM/billing? Spend 15 minutes imagining a single query that fetches invoices, combines them with bank transaction data and produces a categorized list of unpaid-but-not-late, unpaid-and-late, not-fully-paid-but-not-late, not-fully-paid-and-late, fully-paid-in-time and paid-too-much invoices for this year’s billing cycle, selected from tables that contain info for all historical years too. You want to have tests for those.
eadmund 4y ago
The major problem with GraphQL is that it tries to replace REST, instead of augmenting it. REST is a damned fine model, and arguably what every web API should use. I guess it wouldn't have been as much fun to augment REST with query language than to invent a new one.
- mikewhy 4y ago
  You can easily augment a rest API with graphql.
- Kaze404 4y ago
  How does GraphQL try to replace REST? You can very easily have a graphql endpoint working in a REST API.
  - eadmund 4y ago
    > You can very easily have a graphql endpoint working in a REST API. The fact that it is an additional endpoint with non-REST semantics is what makes it a replacement rather than an augmentation of REST. In a REST API, endpoints correlate with resources; the resources are queried and updated with HTTP verbs acting on those endpoints. GraphQL introduces a parallel world. What should have been done instead, IMHO, was to design a standard (not necessarily limited to JSON!) way to query and update resources through their endpoints.
    - Kaze404 4y ago
      I don't understand how that makes it a replacement. Breaking conventions of REST for one endpoint doesn't necessarily mean you're replacing it, unless you're using REST as a dogma rather than a tool.
whakim 4y ago
Having recently had to take over a GraphQL + Relay project in the last ~6 months, I agree with this. When things work (e.g., the frontend/backend magically staying in sync) it feels really great. But with the amount of tech you're throwing at the problem I found it difficult to learn (the ecosystem is immature, the documentation often sucks, your problem space grows with GraphQL + GraphQL client of choice + web framework of choice). I found the bugs and opaque performance issues to be harder to track down. I'm sure that with time and mastery these problems will resolve themselves, but I'd much rather spend my "cool stuff budget" on tech that (IMO) provides a significantly greater benefit for the inconveniences caused.
Someone 4y ago
IMO, the main problem with GraphQL is that a query language isn’t much without a query planner. Without a planner, you end up with the backend picking a set of queries that the caller can make (and with it, you probably want to restrict callers, anyways). I don’t see how that’s much different from writing N stored procedures and exposing those. If you give those consistent names, the caller has a clear list of things that can be done. With GraphQL, the API looks more flexible than it is. I think GraphQL‘s main innovation is that it allows the caller to specify what fields to return. That makes it easy to provide f! - 1 variants of queries that return up to f fields, cutting down on traffic significantly in many cases.
- saurik 4y ago
  > That makes it easy to provide f! - 1 variants of queries... I mean, I'd hope you only need 2^f - 1 variants...
  - Someone 4y ago
    Oops. Thanks!

francislavoie 4y ago

I use https://www.jsonrpc.org/specification https://www.jsonrpc.org/specification. I hate REST. With JSON-RPC, I can have true 1:1 mapping on both ends to how I write code, and it's transport agnostic. Doesn't rely on any language. I use PHP in the backend, TS in the frontend. There are ways to make it somewhat type safe with tools like https://open-rpc.org/ https://open-rpc.org/ but I tend to just go vanilla with it and write TypeScript types in the frontend for the results on the frontend.

hatch_q 4y ago
In all honesty, we do this with REST now. Just define interface with OpenAPI - then create clients, servers in virtually any language you like.
- francislavoie 4y ago
  The problem with REST for me is that it locks you to HTTP verbs and URIs. And it's not a great mapping for much more than CRUD. I find it really restrictive and annoying. It's specific to HTTP as the transport, so I can't use REST over websockets or some raw TCP server-to-server pipe, etc, without making a kludge of it.
  - dimgl 4y ago
    This is actually really cool! Any chance you can point me to an implementation for JSON-RPC? I'm interested to see the benefits with JSON-RPC over a traditional REST API.
    - francislavoie 4y ago
      The spec explains pretty much everything you need to know. Look for a client and server implementation in your language of choice; essentially all it needs to do is decode the JSON message and validate that it uses the right structure, and handle message IDs for batching, then call your custom message handling logic. Over HTTP, basically you just have a single endpoint which always takes POST requests, and always responds with 200 status, even on errors. If you're using this in a frontend JS application, you'd want a wrapper over fetch() which rejects the promise if the RPC response has an error in the message.

015a 4y ago

I'd argue GraphQL really doesn't even solve that "mini-query-language" problem all that well. But, I'm with you; that's how its sold. Its one of the big things its proponents say. And it fails at it. Let me pick on an example of one of these rest-api-mini-query-language specs: the Microsoft Graph API, which uses OData. It supports: * Count (don't return items; return a count of them) * Expand (graph traversal on related resources) * Filter * Format * Order (sorting) * Search * Select * Skip * SkipToken * Top * A bevy of others Of these; GraphQL solves Select and Expand. That's it. Everything else INEVITABLY becomes a pseudo-odata-mini-query-language on top of GraphQL; the exact same problem REST APIs had! Pagination. Skip/limits. Response reducing/counting/analytics. Filtering. Etc. Of course, a framework has to stop somewhere. Lest you become OData, which isn't all that great to use. So, I'm not proposing that GraphQL should do more; but rather that its proponents need to stop listing this as an advantage of the framework, because its actually a disadvantage. Its only "good" at this relative to literally `npm i express`; the most basic-possible-REST-API. The REST & RPC ecosystems have a wide array of higher level tooling to select from, at every possible level of "nothing" to "everything and the kitchen sink"; GraphQL is startlingly boring in comparison, and proponents who list this as an advantage of GraphQL really aren't doing much more than admitting how little exposure they have in competing frameworks (or, similarly, how poorly APIs were built at whatever company they worked at last).

obi1kenobi 4y ago
I made a query language that parses as legal GraphQL using a vanilla parser, but has directives like `@filter, @recurse, @optional` etc. that make it a real query language. Also, instead of returning a giant fully-nested result, it flattens results and emits them row-by-row like a SQL database. This means the query evaluation can be lazy and incremental — if you write a query that has a billion results but only load 20 of them, then only 20 rows' worth of work happens. My company has been using this in production for 6 years now across everything from TB-scale SQL clusters with X00,000 tables/views, to querying our own codebase, configuration, and deployment information to find and prevent bugs. I gave a 10min talk at a conference about this recently, if you'd like to learn more: https://www.hytradboi.com/2022/how-to-query-almost-everythin https://www.hytradboi.com/2022/how-to-query-almost-everythin... Project GitHub: https://github.com/obi1kenobi/trustfall https://github.com/obi1kenobi/trustfall

kristiandupont 4y ago

I recently gave a talk about our experience with tRPC. So far it's looking very promising! https://www.youtube.com/watch?v=k1TCueEhhJo https://www.youtube.com/watch?v=k1TCueEhhJo

tootie 4y ago

Software architecture really needs to acknowledge the human aspect of building platforms. GraphQL is great solution to organizational problem of slow communication and/or misaligned incentives between frontend and backend teams. GraphQL is essentially a self-service approach where API developers can create a flexible, open-ended data access plane that end users can consume as they wish. That incurs a lot of extra technical complexity, but obviates a lot of organizational complexity. That could be a very valid concern if your backend is public or otherwise serves a really diverse group of clients. The most efficient and effective API integration projects I've done is where the API and frontend teams are tightly knit, working off a shared backlog and able to pass a chain of requirements from design, to contract writing, to development on both sides and get really tight alignment. That lets us create very tightly optimized REST endpoints that are very cache-friendly and can deliver precise payloads to optimize both round trips and bandwidth. It's actually easier to build because requirements are really clear, but comes at the cost of doing all that communication to align on requirements.

dhzhzjsbevs 4y ago
Pretty much this sums it up. I still don't understand the need for graphql. Then again, it only takes me 5 minutes to add a new endpoint that just dumps back a specific SQL query result. I think a lot of companies make adding endpoints into a big deal, often a whole new file or class with documentation and tests. An SQL query doesn't need tests. I think another part of it is that SQL still scares people. That is, I'd put graphql in the same camp as active record, orms, and other silly attempts at creating a query language to avoiding using a query language.
- eurasiantiger 4y ago
  >An SQL query doesn't need tests. Have you ever done financial stuff on SQL? Transaction processing or even just CRM/billing? Spend 15 minutes imagining a single query that fetches invoices, combines them with bank transaction data and produces a categorized list of unpaid-but-not-late, unpaid-and-late, not-fully-paid-but-not-late, not-fully-paid-and-late, fully-paid-in-time and paid-too-much invoices for this year’s billing cycle, selected from tables that contain info for all historical years too. You want to have tests for those.

eadmund 4y ago

The major problem with GraphQL is that it tries to replace REST, instead of augmenting it. REST is a damned fine model, and arguably what every web API should use. I guess it wouldn't have been as much fun to augment REST with query language than to invent a new one.

mikewhy 4y ago
You can easily augment a rest API with graphql.
Kaze404 4y ago
How does GraphQL try to replace REST? You can very easily have a graphql endpoint working in a REST API.
- eadmund 4y ago
  > You can very easily have a graphql endpoint working in a REST API. The fact that it is an additional endpoint with non-REST semantics is what makes it a replacement rather than an augmentation of REST. In a REST API, endpoints correlate with resources; the resources are queried and updated with HTTP verbs acting on those endpoints. GraphQL introduces a parallel world. What should have been done instead, IMHO, was to design a standard (not necessarily limited to JSON!) way to query and update resources through their endpoints.
  - Kaze404 4y ago
    I don't understand how that makes it a replacement. Breaking conventions of REST for one endpoint doesn't necessarily mean you're replacing it, unless you're using REST as a dogma rather than a tool.

whakim 4y ago

Having recently had to take over a GraphQL + Relay project in the last ~6 months, I agree with this. When things work (e.g., the frontend/backend magically staying in sync) it feels really great. But with the amount of tech you're throwing at the problem I found it difficult to learn (the ecosystem is immature, the documentation often sucks, your problem space grows with GraphQL + GraphQL client of choice + web framework of choice). I found the bugs and opaque performance issues to be harder to track down. I'm sure that with time and mastery these problems will resolve themselves, but I'd much rather spend my "cool stuff budget" on tech that (IMO) provides a significantly greater benefit for the inconveniences caused.

Someone 4y ago

IMO, the main problem with GraphQL is that a query language isn’t much without a query planner. Without a planner, you end up with the backend picking a set of queries that the caller can make (and with it, you probably want to restrict callers, anyways). I don’t see how that’s much different from writing N stored procedures and exposing those. If you give those consistent names, the caller has a clear list of things that can be done. With GraphQL, the API looks more flexible than it is. I think GraphQL‘s main innovation is that it allows the caller to specify what fields to return. That makes it easy to provide f! - 1 variants of queries that return up to f fields, cutting down on traffic significantly in many cases.

saurik 4y ago
> That makes it easy to provide f! - 1 variants of queries... I mean, I'd hope you only need 2^f - 1 variants...
- Someone 4y ago
  Oops. Thanks!