Fork me on GitHub

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?


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


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?


@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


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


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


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


@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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


to render a single view?


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


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


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


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


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


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.


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


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


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