4 ms·

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

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.

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.