5 ms·

Unless GraphQL implementations include some sort of query optimiser, it's very hard to see how they actually do anything, if you're left to constantly supervise

by thom 6y ago

Unless GraphQL implementations include some sort of query optimiser, it's very hard to see how they actually do anything, if you're left to constantly supervise the back end in this way.

raspberry_fool 6y ago
In general I would not recommend bolting on GraphQL to an existing model unless you're willing to invest in either time to build out the backend query optimization or tolerance of suboptimal querying. The ruby graphql ecosystem is also lacking for decent loaders, but such a loader would likely not integrate with ActiveRecord. Also, remember, GraphQL is a language, you're responsible for locating the data on the backend.
tshaddox 6y ago
The primary “thing GraphQL does” is provide a data shape contract between servers and clients, with type safety, introspection, and a fairly human-friendly query syntax.
- jamil7 6y ago
  I don’t disagree but can’t you kinda get a lot of this with swagger / openapi aswell?
- deckard1 6y ago
  > with type safety GraphQL provides one-way (server-bound) run-time type assertions. I constantly see developers that should know better confuse validation with type checking. I've had developers, in earnest, ask how they can use TypeScript on run-time data inputs. I have to break the bad news to them and simply tell them: no, you can't do that. That's not how type systems work. Out of the box, GraphQL provides no validation, that I know of, beyond the elementary data types. Anyone that knows a thing about XSS or SQL-injection can tell you that a string is not always just a string. Anyone using C/C++ that has dealt with stack overflows and code injection can tell you that an integer is not always an integer. Sometimes it's a pointer. Oops. You're going to hand code validations, each and every time. Because no tool knows how many characters your DB is setup to handle for a username, for example. GraphQL and TypeScript won't save you.
  - tshaddox 6y ago
    I understand the distinction you're making, but I think it's fuzzier than you seem to think. Yes, GraphQL responses tend to go over the wire in a format without any type checking (like JSON). But GraphQL tooling and libraries can use GraphQL schemas to ensure that application code that consumes GraphQL responses will never see a value with a type that contradicts the GraphQL schema. GraphQL tooling cannot literally prevent JSON from having a string value where there's supposed to be a number value, but it can ensure that application code never has runtime type errors. Is that "validation rather than type checking"? Sure, I suppose so, but my application code that consumes GraphQL responses will either get some representation of an error, or a representation of a successful response that is guaranteed to have the types I expect. And yes, there are plenty of other data formats and tools that provide the same sort of thing: some representation of a schema, some non-application code that checks runtime data against that schema, and a contract with the application code that each response will be either an error or a type-safe successful response.
cactus2093 6y ago
Building a Firebase-like direct frontend access to your database tables is far from the only use case of GraphQL. Many (probably most) apps inevitably need backend logic that does more than just pass through and format data for the frontend. GraphQL can still have a lot of other benefits in terms of enforcing data structure and eliminating other types of boilerplate.
striking 6y ago
I really wish GraphQL weren't named in a way that seems to cause confusion about what it's for and its relation to SQL. It's not a replacement for SQL. It's a replacement for REST. And the intent is to provide a statically typed, holistic interface and encourage best practices in API design. It's also quite nice because there are clients that plug into it and offer substantial benefits as a result, like Relay. There are lots of ways people write resolution methods for GraphQL, and this article provides a good number of them. You can think of them as query optimization approaches if it helps. But it's not quite like SQL, where in SQL you say whatever you like and it just gets figured out. GraphQL forces an amount of intention and asks schema writers to consider the most concrete use cases possible rather than just enabling super generic ones.
- jtmarmon 6y ago
  I don't think GP is confused. GraphQL lets you write queries for objects. This fundamentally changes how you architect your app and database. In a REST API, you turn known a finite list of known query patterns (endpoints) into DB queries, which you can test, hand-write, and optimize. If you let end users query your object model, it takes far more work to ensure they don't do something very expensive.
  - Kaze404 6y ago
    > If you let end users query your object model, it takes far more work to ensure they don't do something very expensive. How so? There are existing tools that prevent both N+1 problems (Dataloader) and complex, recursive queries (depth and complexity limits).
  - striking 6y ago
    The amount of work it might take is generally proportional to the amount of flexibility you give the user. You don't have to (and in fact are generally discouraged to) offer end users a degree of flexibility that makes your life harder. To be especially clear about this: do not mirror your DB schema in your GQL schema; it's not worth it. But, even should you have to support a complex schema, the fine article showcases a number of great mitigations that cover basically every possible issue. The only issue that I don't think is covered here is that collecting all this data up and sending it all at once can sometimes be slow or even time out, and there's no mechanism really to allow GraphQL to defer the collection of some fields until they're ready. It's coming very soon (in the form of @defer; to the spec, to graphql-js, to Relay, and to others) but it's not quite here yet.
benatkin 6y ago
The discoverability and querying part of GraphQL seems to be a net loss, and the RPC part seems to be a net win. I think REST is going to lose some a big chunk of its popularity, but that it will be to gRPC, not GraphQL.
- valenterry 6y ago
  I found both the discoverability and querying in GraphQL much better compared to Rest. Can you explain what you mean in more detail?
  - benatkin 6y ago
    Discoverability with GraphiQL and Intellisense aims to make it self-documenting. It doesn't work out that well and you wind up needing documentation anyway. Queries over GraphQL often wind up being handled by custom resolvers and being about the same as remote procedure calls. It is kind of neat how it separates the queries from the mutations. Blitz does that, but with GraphQL being optional: https://blitzjs.com/docs/query-resolvers https://blitzjs.com/docs/query-resolvers gRPC just provides an efficient transport and has the client library provide the interface. It works out pretty well for google APIs.
    - valenterry 6y ago
      I agree that more comprehensive documentation is often necessary. But still, having GraphiQL that let's me discover all possible queries with their types and a small explanation for each field is a great win. I like that much better than for example generated swagger documentation. So how exactly is this a net loss? If anything it does not improve the situation - but making it worse?
bdcravens 6y ago
My understanding is that Hasura more or less "compiles" SQL, rather than chaining models together like Rails does.
- thom 6y ago
  Yeah, we use Hasura for some endpoints and it's great for rapid development, but still has a lot of sharp (or indeed dull) edges.
  - tango12 6y ago
    Hey! I'm from Hasura. Would love to hear what's been missing / painful and factor that into the roadmap.
    - thom 6y ago
      A lot of random issues, some I think already fixed, like migrations being run out of order. Remotes being hit even for null foreign keys kills off some queries for us. Remotes not being supported in subscriptions (sort of understandable but still causes inconsistencies in user experience). We've had to be very strict with naming conventions for relationships etc or we find we're constantly dealing with merge conflicts, but that's as much our workflow issue. There's poor support for Postgres enums. That's the stuff I can remember off the top of my head, and none of it's really a killer. Without something like Hasura my interest in GraphQL drops close to zero, to be clear, so it's providing a lot of value.
ilikehurdles 6y ago
While it may be tempting to do so, don't create wide open "flexible" GraphQL queries that you don't know the use cases of yet, supporting arbitrarily deep levels of nesting, aggregation, and parameterization. That's how you paint yourself into a corner, fast. It's much easier to evolve from a very restrictive schema to a more open schema as the use-cases present themselves, than it is to move clients from an open schema to a more restrictive one because your backend is choking trying to support the cardinality of edge cases introduced by it.
- dfee 6y ago
  That’s kinda hard not to support. The second you have a relation modeled bidirectionally in GraphQL, you support infinite nesting (well, there are complexity guards, but alas).

by thom 6y ago

Unless GraphQL implementations include some sort of query optimiser, it's very hard to see how they actually do anything, if you're left to constantly supervise the back end in this way.

raspberry_fool 6y ago

In general I would not recommend bolting on GraphQL to an existing model unless you're willing to invest in either time to build out the backend query optimization or tolerance of suboptimal querying. The ruby graphql ecosystem is also lacking for decent loaders, but such a loader would likely not integrate with ActiveRecord. Also, remember, GraphQL is a language, you're responsible for locating the data on the backend.

tshaddox 6y ago

The primary “thing GraphQL does” is provide a data shape contract between servers and clients, with type safety, introspection, and a fairly human-friendly query syntax.

jamil7 6y ago
I don’t disagree but can’t you kinda get a lot of this with swagger / openapi aswell?
deckard1 6y ago
> with type safety GraphQL provides one-way (server-bound) run-time type assertions. I constantly see developers that should know better confuse validation with type checking. I've had developers, in earnest, ask how they can use TypeScript on run-time data inputs. I have to break the bad news to them and simply tell them: no, you can't do that. That's not how type systems work. Out of the box, GraphQL provides no validation, that I know of, beyond the elementary data types. Anyone that knows a thing about XSS or SQL-injection can tell you that a string is not always just a string. Anyone using C/C++ that has dealt with stack overflows and code injection can tell you that an integer is not always an integer. Sometimes it's a pointer. Oops. You're going to hand code validations, each and every time. Because no tool knows how many characters your DB is setup to handle for a username, for example. GraphQL and TypeScript won't save you.
- tshaddox 6y ago
  I understand the distinction you're making, but I think it's fuzzier than you seem to think. Yes, GraphQL responses tend to go over the wire in a format without any type checking (like JSON). But GraphQL tooling and libraries can use GraphQL schemas to ensure that application code that consumes GraphQL responses will never see a value with a type that contradicts the GraphQL schema. GraphQL tooling cannot literally prevent JSON from having a string value where there's supposed to be a number value, but it can ensure that application code never has runtime type errors. Is that "validation rather than type checking"? Sure, I suppose so, but my application code that consumes GraphQL responses will either get some representation of an error, or a representation of a successful response that is guaranteed to have the types I expect. And yes, there are plenty of other data formats and tools that provide the same sort of thing: some representation of a schema, some non-application code that checks runtime data against that schema, and a contract with the application code that each response will be either an error or a type-safe successful response.

cactus2093 6y ago

Building a Firebase-like direct frontend access to your database tables is far from the only use case of GraphQL. Many (probably most) apps inevitably need backend logic that does more than just pass through and format data for the frontend. GraphQL can still have a lot of other benefits in terms of enforcing data structure and eliminating other types of boilerplate.

striking 6y ago

I really wish GraphQL weren't named in a way that seems to cause confusion about what it's for and its relation to SQL. It's not a replacement for SQL. It's a replacement for REST. And the intent is to provide a statically typed, holistic interface and encourage best practices in API design. It's also quite nice because there are clients that plug into it and offer substantial benefits as a result, like Relay. There are lots of ways people write resolution methods for GraphQL, and this article provides a good number of them. You can think of them as query optimization approaches if it helps. But it's not quite like SQL, where in SQL you say whatever you like and it just gets figured out. GraphQL forces an amount of intention and asks schema writers to consider the most concrete use cases possible rather than just enabling super generic ones.

jtmarmon 6y ago
I don't think GP is confused. GraphQL lets you write queries for objects. This fundamentally changes how you architect your app and database. In a REST API, you turn known a finite list of known query patterns (endpoints) into DB queries, which you can test, hand-write, and optimize. If you let end users query your object model, it takes far more work to ensure they don't do something very expensive.
- Kaze404 6y ago
  > If you let end users query your object model, it takes far more work to ensure they don't do something very expensive. How so? There are existing tools that prevent both N+1 problems (Dataloader) and complex, recursive queries (depth and complexity limits).
- striking 6y ago
  The amount of work it might take is generally proportional to the amount of flexibility you give the user. You don't have to (and in fact are generally discouraged to) offer end users a degree of flexibility that makes your life harder. To be especially clear about this: do not mirror your DB schema in your GQL schema; it's not worth it. But, even should you have to support a complex schema, the fine article showcases a number of great mitigations that cover basically every possible issue. The only issue that I don't think is covered here is that collecting all this data up and sending it all at once can sometimes be slow or even time out, and there's no mechanism really to allow GraphQL to defer the collection of some fields until they're ready. It's coming very soon (in the form of @defer; to the spec, to graphql-js, to Relay, and to others) but it's not quite here yet.

benatkin 6y ago

The discoverability and querying part of GraphQL seems to be a net loss, and the RPC part seems to be a net win. I think REST is going to lose some a big chunk of its popularity, but that it will be to gRPC, not GraphQL.

valenterry 6y ago
I found both the discoverability and querying in GraphQL much better compared to Rest. Can you explain what you mean in more detail?
- benatkin 6y ago
  Discoverability with GraphiQL and Intellisense aims to make it self-documenting. It doesn't work out that well and you wind up needing documentation anyway. Queries over GraphQL often wind up being handled by custom resolvers and being about the same as remote procedure calls. It is kind of neat how it separates the queries from the mutations. Blitz does that, but with GraphQL being optional: https://blitzjs.com/docs/query-resolvers https://blitzjs.com/docs/query-resolvers gRPC just provides an efficient transport and has the client library provide the interface. It works out pretty well for google APIs.
  - valenterry 6y ago
    I agree that more comprehensive documentation is often necessary. But still, having GraphiQL that let's me discover all possible queries with their types and a small explanation for each field is a great win. I like that much better than for example generated swagger documentation. So how exactly is this a net loss? If anything it does not improve the situation - but making it worse?

bdcravens 6y ago

My understanding is that Hasura more or less "compiles" SQL, rather than chaining models together like Rails does.

thom 6y ago
Yeah, we use Hasura for some endpoints and it's great for rapid development, but still has a lot of sharp (or indeed dull) edges.
- tango12 6y ago
  Hey! I'm from Hasura. Would love to hear what's been missing / painful and factor that into the roadmap.
  - thom 6y ago
    A lot of random issues, some I think already fixed, like migrations being run out of order. Remotes being hit even for null foreign keys kills off some queries for us. Remotes not being supported in subscriptions (sort of understandable but still causes inconsistencies in user experience). We've had to be very strict with naming conventions for relationships etc or we find we're constantly dealing with merge conflicts, but that's as much our workflow issue. There's poor support for Postgres enums. That's the stuff I can remember off the top of my head, and none of it's really a killer. Without something like Hasura my interest in GraphQL drops close to zero, to be clear, so it's providing a lot of value.

ilikehurdles 6y ago

While it may be tempting to do so, don't create wide open "flexible" GraphQL queries that you don't know the use cases of yet, supporting arbitrarily deep levels of nesting, aggregation, and parameterization. That's how you paint yourself into a corner, fast. It's much easier to evolve from a very restrictive schema to a more open schema as the use-cases present themselves, than it is to move clients from an open schema to a more restrictive one because your backend is choking trying to support the cardinality of edge cases introduced by it.

dfee 6y ago
That’s kinda hard not to support. The second you have a relation modeled bidirectionally in GraphQL, you support infinite nesting (well, there are complexity guards, but alas).