Hacker News Reader

Comment by maktouch | Hacker News Reader

> 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.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.

View on HN

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.

If you made a custom scalar, wouldn’t you have control how it’s deployed across the different languages you choose to implement it? Truly curious. I haven’t attempted to work with a broad range of languages for my own services.

I'm starting to understand what you mean.

You are right - GraphQL, even though it has the word "graph" in it, is pretty weak at complex graph traversal. Actually, I don't think it was made for complex graph traversal in mind.

https://docs.dgraph.io/master/query-language/ uses graphql, but they really modified the language to make it work for complex graph traversal, to a point where the simplicity of it is gone.

> I stuck to ISO 8601 format string for standardizing time.

In my App, I have scalar called ISO8601String, which is a custom scalar representing a date-time. The server outputs the correct serialized value, and clients are expected to deserialize as per the documentation.

It's not automatic though. Every client app has to implement the custom scalar serialize/deserialize logic or else it isn't conforming to the schema that the server declares.

GraphQL isn't a global schema standard, inclusive of implementation details. It's specific to your application's servers/clients.

Someone else is free to have a scalar called ISO8601String, which demands totally different serialization.

Implementing a client/server pretty much requires reading the documentation of the schema. You can make a Map restrict itself to only string keys, but that conformance of that will have to be a custom type implemented by your server to reject noncomforming objects.

Not the OP but I would appreciate the PoC anyhow - as I’m sure others would.

Reply on news.ycombinator.com