4 ms·

Hate to complain about GraphQL in general and not specifically this guide but I ran into to major issues with it and really wanted to like it but ultimately gav

Hate to complain about GraphQL in general and not specifically this guide but I ran into to major issues with it and really wanted to like it but ultimately gave up on it until they fix some core issues. I don't see how I can implement complex object hierarchies that are not rigid. Only list is supported as an unbounded data type and for some reason there is no unbounded map/dictionary data type even with simple restrictions like requiring string key type. There is not even good advice on what key/value pair naming convention should be for all languages. The other is that there is very poor support for more general include/exclude/where filters. The idea being arbitrary complex join/filter clauses to function like sql statement with multiple joins and where clauses. Have to rely on implementation specific conventions like what sequelize does to get that but not for arbitrary object graphs. Solve some of this and it might actually become as powerful as it is frequently claimed to be.

maktouch 8y ago
Hmm, our API is pretty big and we never had an issue where GraphQL couldn't solve it (https://player.me/api/graphiql https://player.me/api/graphiql) > I don't see how I can implement complex object hierarchies that are not rigid. I'm not sure I understand what you're trying to do, but did you try the JSON scalar type? https://github.com/taion/graphql-type-json https://github.com/taion/graphql-type-json With that, it just returns JSON but you can't pick and choose what keys gets returned. We never had to use that though. We prefer to use interfaces or unions.
- tfigment 8y ago
  My understanding is the json type stuff is a language specific workaround and not part of the standard. I have .NET, go, node.js, and others and while I could make any one of those languages work with specific changes they would not necessarily inter-operate for free or per the standard. I would hate to build heavily on workarounds that I feel should be in-built. At some point we just reinventing the wheel but in a more fragile way. I dont believe the arbitrary json was in the .NET version I was using which is what would expose data to be consumed via node.js (and other .net clients). Frankly it was easier to just implement a simple rest api that did exactly what was expected. What I sort of what is to be able to craft a query against a large set of objects like a customer/location/asset hierarchy and filter on different levels like sql query without it being in a database. I might have 10 different orthogonal dimensions with foreign keys than can be returned and filtered against. I'm trying to avoid pulling the complete object hierarchy only for it to filter out some of the data after the fact and then finally return the expected json format. Accessing some objects might be very expensive so being able to filter data as part of the query request rather than afterwords would speed things up. These actions are usually quite hard to do in libraries I've used. Maybe if you only use javascript/node.js, I don't know its not what I've need to start with. I may have misinterpreted what GraphQL was for if it is not for querying nearly arbitrary object graphs and returning json that the client wants returned.
  - maktouch 8y ago
    > My understanding is the json type stuff is a language specific workaround and not part of the standard. The standard is made to be extended (https://www.apollographql.com/docs/graphql-tools/scalars.html https://www.apollographql.com/docs/graphql-tools/scalars.htm...) For example, you should start with making your own DateTime scalar. > What I sort of what is to be able to craft a query against a large set of objects like a customer/location/asset hierarchy and filter on different levels like sql query without it being in a database. You can totally do this without raw json scalar. Actually, it would be better without it. If you could go more in-depth details, I could make you a PoC.
    - abritinthebay 8y ago
      Not the OP but I would appreciate the PoC anyhow - as I’m sure others would.
    - tfigment 8y ago
      Problem is not every language will implement DateTime the same and I had same problem with protobuf and thrift. I stuck to ISO 8601 format string for standardizing time. I could circumvent the type system via arbitrary json type but I'd rather not do so but I use dictionary in .net a lot and would like those to be more available. In .net, Dictionary objects become KeyValuePair arrays in GraphQL but then assume objects of that form while python I think that would be a tuple. These are general language serialization interop problems and the more the standard implementations help here the better. If I want to go Customer/Physical Site/Asset Level 1/Asset level 2 versus Physical Location/Customer/Asset Level 2/Asset Level 1 as a general navigation through the data objects as a query then I have to have both of those paths available in the schema or custom queries. I'm sure I'm not explaining my issue properly but I find its related to how the graph traversal works. As number of dimensions expand this gets harder. We looked at some of the sequelize generated queries via a node implementation and was generally concerned about the ORM queries used. You can get by maybe with code generation or dynamic schemas but starting to lose ease of use and some performance if you dump the whole schema that way. I'm sure I can workaround each of these but as a whole nothing really coalesced to something simpler to build and maintain overall. GraphQL as a standard is still useful I think for simple schemas that are broad and not deep is perhaps what I'm trying to say.
hn_throwaway_99 8y ago
I'm a huge fan of GraphQL, and when I see negative feedback that lists some of the points you make, I can't help but think that you are using GraphQL in a way for which it was not designed. The most common issue I see is when folks list "what about arbitrary complex join/filter clauses to function like sql statement with multiple joins and where clauses" which, in my use of GraphQL, is literally never something I would want. GraphQL is not SQL or designed to be an arbitrary data access layer. One of the driving principles of GraphQL, taken straight from the spec, is: "Product‐centric: GraphQL is unapologetically driven by the requirements of views and the front‐end engineers that write them. GraphQL starts with their way of thinking and requirements and builds the language and runtime necessary to enable that." IMO GraphQL is designed to start with the UI, and develop models that conform to the needs of the UI, not to start with the data and develop arbitrary joining and fetching strategies for that data.
- gldalmaso 8y ago
  Maybe I'm just not that well versed in GraphQL, but reading your comment left me confused. What would the UI data requirements have to be? Aren't they often arbitrary data fetching driven by the user? Aren't the requirements of views what data the user wants to see and handle? Depending on what user chooses, the fetching of data will have to go deeper and deeper into the data store. I seem to remember, perhaps mistakenly, that GraphQL came as a solution to fetch arbitrary data structures that the view needed instead of having to mix and match multiple RESTful endpoints.
  - andrewingram 8y ago
    Do your users construct their own UI? Or do they use a set of features provided by whomever built the app/website? The arbitrary data fetching is to allow rapid feature development, bypassing the need to explicitly code up per-feature endpoints. Instead the responsibility is passed to front-end developers to compose per-feature queries.
  - willtim 8y ago
    I suspect that GraphQL corresponds more to Erik Meijer's "coSQL" formalism (see A Co-Relational Model of Data for Large Shared Data Banks). The advantages with respect to SQL would be an open-world assumption (easier distribution, no normalisation), the disadvantage would be the lack of arbitrary joins (which requires normalisation and indexes).
hokumguru 8y ago
http://prisma.io http://prisma.io solves that second problem quite well. It implements and handles the issues of complex queries for you with minimal effort
wereHamster 8y ago
If you want an unbounded dictionary, define your own scalar type.

maktouch 8y ago

Hmm, our API is pretty big and we never had an issue where GraphQL couldn't solve it (https://player.me/api/graphiql https://player.me/api/graphiql) > I don't see how I can implement complex object hierarchies that are not rigid. I'm not sure I understand what you're trying to do, but did you try the JSON scalar type? https://github.com/taion/graphql-type-json https://github.com/taion/graphql-type-json With that, it just returns JSON but you can't pick and choose what keys gets returned. We never had to use that though. We prefer to use interfaces or unions.

tfigment 8y ago
My understanding is the json type stuff is a language specific workaround and not part of the standard. I have .NET, go, node.js, and others and while I could make any one of those languages work with specific changes they would not necessarily inter-operate for free or per the standard. I would hate to build heavily on workarounds that I feel should be in-built. At some point we just reinventing the wheel but in a more fragile way. I dont believe the arbitrary json was in the .NET version I was using which is what would expose data to be consumed via node.js (and other .net clients). Frankly it was easier to just implement a simple rest api that did exactly what was expected. What I sort of what is to be able to craft a query against a large set of objects like a customer/location/asset hierarchy and filter on different levels like sql query without it being in a database. I might have 10 different orthogonal dimensions with foreign keys than can be returned and filtered against. I'm trying to avoid pulling the complete object hierarchy only for it to filter out some of the data after the fact and then finally return the expected json format. Accessing some objects might be very expensive so being able to filter data as part of the query request rather than afterwords would speed things up. These actions are usually quite hard to do in libraries I've used. Maybe if you only use javascript/node.js, I don't know its not what I've need to start with. I may have misinterpreted what GraphQL was for if it is not for querying nearly arbitrary object graphs and returning json that the client wants returned.
- maktouch 8y ago
  > My understanding is the json type stuff is a language specific workaround and not part of the standard. The standard is made to be extended (https://www.apollographql.com/docs/graphql-tools/scalars.html https://www.apollographql.com/docs/graphql-tools/scalars.htm...) For example, you should start with making your own DateTime scalar. > What I sort of what is to be able to craft a query against a large set of objects like a customer/location/asset hierarchy and filter on different levels like sql query without it being in a database. You can totally do this without raw json scalar. Actually, it would be better without it. If you could go more in-depth details, I could make you a PoC.
  - abritinthebay 8y ago
    Not the OP but I would appreciate the PoC anyhow - as I’m sure others would.
  - tfigment 8y ago
    Problem is not every language will implement DateTime the same and I had same problem with protobuf and thrift. I stuck to ISO 8601 format string for standardizing time. I could circumvent the type system via arbitrary json type but I'd rather not do so but I use dictionary in .net a lot and would like those to be more available. In .net, Dictionary objects become KeyValuePair arrays in GraphQL but then assume objects of that form while python I think that would be a tuple. These are general language serialization interop problems and the more the standard implementations help here the better. If I want to go Customer/Physical Site/Asset Level 1/Asset level 2 versus Physical Location/Customer/Asset Level 2/Asset Level 1 as a general navigation through the data objects as a query then I have to have both of those paths available in the schema or custom queries. I'm sure I'm not explaining my issue properly but I find its related to how the graph traversal works. As number of dimensions expand this gets harder. We looked at some of the sequelize generated queries via a node implementation and was generally concerned about the ORM queries used. You can get by maybe with code generation or dynamic schemas but starting to lose ease of use and some performance if you dump the whole schema that way. I'm sure I can workaround each of these but as a whole nothing really coalesced to something simpler to build and maintain overall. GraphQL as a standard is still useful I think for simple schemas that are broad and not deep is perhaps what I'm trying to say.

hn_throwaway_99 8y ago

I'm a huge fan of GraphQL, and when I see negative feedback that lists some of the points you make, I can't help but think that you are using GraphQL in a way for which it was not designed. The most common issue I see is when folks list "what about arbitrary complex join/filter clauses to function like sql statement with multiple joins and where clauses" which, in my use of GraphQL, is literally never something I would want. GraphQL is not SQL or designed to be an arbitrary data access layer. One of the driving principles of GraphQL, taken straight from the spec, is: "Product‐centric: GraphQL is unapologetically driven by the requirements of views and the front‐end engineers that write them. GraphQL starts with their way of thinking and requirements and builds the language and runtime necessary to enable that." IMO GraphQL is designed to start with the UI, and develop models that conform to the needs of the UI, not to start with the data and develop arbitrary joining and fetching strategies for that data.

gldalmaso 8y ago
Maybe I'm just not that well versed in GraphQL, but reading your comment left me confused. What would the UI data requirements have to be? Aren't they often arbitrary data fetching driven by the user? Aren't the requirements of views what data the user wants to see and handle? Depending on what user chooses, the fetching of data will have to go deeper and deeper into the data store. I seem to remember, perhaps mistakenly, that GraphQL came as a solution to fetch arbitrary data structures that the view needed instead of having to mix and match multiple RESTful endpoints.
- andrewingram 8y ago
  Do your users construct their own UI? Or do they use a set of features provided by whomever built the app/website? The arbitrary data fetching is to allow rapid feature development, bypassing the need to explicitly code up per-feature endpoints. Instead the responsibility is passed to front-end developers to compose per-feature queries.
- willtim 8y ago
  I suspect that GraphQL corresponds more to Erik Meijer's "coSQL" formalism (see A Co-Relational Model of Data for Large Shared Data Banks). The advantages with respect to SQL would be an open-world assumption (easier distribution, no normalisation), the disadvantage would be the lack of arbitrary joins (which requires normalisation and indexes).

hokumguru 8y ago

http://prisma.io http://prisma.io solves that second problem quite well. It implements and handles the issues of complex queries for you with minimal effort

wereHamster 8y ago

If you want an unbounded dictionary, define your own scalar type.