Fork me on GitHub
#graphql
<
2017-08-07
>
oliy11:08:58

Apologies if this is old ground covered before, but is there any desire (or hard reason not) to relax the graphql restriction on hyphens in keys within a Clojure implementation like Lacinia?

oliy11:08:27

I would like to use Lacinia from an existing clojure+Clojurescript project but I don't want to have a load of key renaming just to satisfy what is, to Clojure, an arbitrary restriction

oliy12:08:09

I understand it's there to keep JSON and JavaScript happy, but if they don't exist in my world can I retain my Clojure naming conventions?

hmaurer13:08:53

@oliy this would break tools like GraphIQL, Apollo client, Relay, etc. It seems to me that adopting javascript’s/graphql’s naming conventions in this case is reasonable

hmaurer13:08:26

You wouldn’t want to maintain your own fork of whatever GraphQL-related tools you are using just so they can support clojure naming conventions

hmaurer13:08:08

If you want to maintain Clojure conventions/semantics on the frontend and the backend, you might want to look into Om Next instead

hmaurer13:08:45

@oliy note that you should be able to automate the conversation from and to clojure naming conventions

oliy13:08:30

@hmaurer thanks for your thoughts - I'm brand new to all this so didn't even know some of those things existed. It's a good point and well made

hmaurer13:08:03

Disclaimer: I am new too and haven’t experimented with Om Next at all, so take what I say with a grain of salt! 🙂

oliy13:08:21

I was actually considering something more along the lines of the euroclojure keynote to generate the conversion at compile time, as I know the from and to schemas in advance

oliy13:08:52

Renaming keys at runtime would add back all the CPU overhead I was hoping to reduce by using graphql :)

hmaurer13:08:06

I don’t know what your project is but the cost of converting keys at runtime should be completely marginal

hmaurer13:08:48

Unless your input payloads are incredibly big for some reason, we’re likely talking microseconds here

hmaurer13:08:55

and in the context of a graphql API that shouldn’t matter at all

oliy13:08:16

Inside tens of megabytes of deep(ish)ly nested maps, it does have a measurable cost

hmaurer13:08:20

(disclaimer: I haven’t benchmarked it; just speculating)

hmaurer13:08:02

you are planning to return tens of megabytes from your graphql queries?

oliy13:08:12

The idea of graphql was to reduce those tens of megabytes by an order of magnitude, it may be enough for decent browser performance

hmaurer13:08:00

@oliy may I ask what your application is / what kind of queries you are doing?

oliy13:08:48

It's for traders to view risk across many trading books

oliy13:08:20

So there is a lot of data, and we're trying to cut it back to the minimum required to render a view

hmaurer13:08:44

will your queries return 10+mb chunks of data at once?

hmaurer13:08:52

to render a single view?

oliy13:08:20

Not in graphql world no, I'm hoping it will be much smaller

hmaurer13:08:44

Should be yeah, and in that case I think the conversion to and from javascript naming convention on fields should be cheap

oliy13:08:45

Ok, I'll continue to experiment - thanks for your help

hmaurer13:08:03

You’re welcome. Tag me if you want to discuss; I am working on a Lacinia app too so I might have stumbled upon the same problem you will encounter @oliy

hlship17:08:02

lacinia-pedestal 0.3.0 is now up on Clojars ... eagerly looking forward to feedback.

johnny.martin18:08:51

The Lacinia docs give examples where an enum is used as an query argument type, but I didn't see any examples using a custom object. Does anyone have an example using a custom object, or even better a list of custom objects, as argument type? Until now I've gotten along with only :type String and :type (list String) When trying get an exception complaining argument X of field Y in type `QueryRoot' is not a valid argument type. Perhaps I am not understanding the GraphQL spec correctly, but seems custom object types should be OK. :args {:myStringArg {:type String}} works fine. :args {:badArgType {:type :myObject}} doesn't.

hlship18:08:46

An argument cannot be an object type, it has to be an input object type.

hlship18:08:40

Input objects don't have resolvers, and fields are restricted to: scalars, enums, input objects (and lists thereof).

hlship21:08:20

If you are having problems upgrading to lacinia-pedestal 0.3.0, our apologies. We are seeing some problems upgrading our code to the latest versions. In the future, we will perform an internal soft-release and ensure that lacinia and lacinia-pedestal are being used in production internally before making a public release. Specific problems: - Need a dependency on org.clojure/test.check 0.9.0 - Extraction of data from request has changed, and does not match documentation