@hlship: we’ve been playing with lacinia and it’s been really great so far… One thing I’d really like to do is support content negotiation formats other than JSON… In particular EDN but also others too (depending on the query). Is this currently possible with lacinia-pedestal?

@rickmoynihan irrc lacinia-pedestal uses a multimethod to extract the query

so yes it should be

@hmaurer: is that for the request or the response? I meant the response, I should’ve been clearer.

@rickmoynihan ah! that was for the request

hang on

might be able to just assoc a new response interceptor over the existing one after constructing the server, but before starting it… not that familiar with pedestal though…

@rickmoynihan that’s the interceptor which converts the response to json: https://github.com/walmartlabs/lacinia-pedestal/blob/master/src/com/walmartlabs/lacinia/pedestal.clj#L92

yeah was thinking I could just dissoc that and add my own, that does some content-neg on the accept header, returning either json or EDN

though I wonder if that would be a nice addition to lacinia-pedestal…

@hlship was talking about adding the ability to easily customise interceptors

I'm not sure where that went

I want to implement kebab case schema support for lacinia, it should not be very hard, but I want to make it working only when explicit flag to compile function provided, it's really needed for adding graphql to our project. Any suggestions from users/maintainers of lacinia?

@andrewtropin why do you want to do this? GraphQL does not support kebab case, so I assume it’s only for aestetic reasons?

it shouldn’t be necessary to implement this in lacinia

I don’t particularly care about having kebab case, but I wish graphql had support for namespaces

I think it would be good for interop if graphql would let you identify that a particular endpoint supported the schemas that your client requires. And that schemas could be shared, and think namespaces are basically a way to do that.

for example the __ prefix seems like a bit of a hack in lieu of having proper namespace support.

@hmaurer We already have a huge codebase with REST api and kebab-cased names is all over the code. I want to do following: add graphql endpoint, keep all internals kebabish, add kebabed lacinia schema, but provide camelCase responses and accept camelCase request based on accept and content type headers. It will make all downstream apps like graphiql still working, but also allows us not to change existing codebase too much.

@andrewtropin you can do it by converting back and forth between kebab case and camelCase in resolvers

Yes, I can, but it's necessary to do it in each resolver, which seems like copy-pasting, takes out params destructuring and other little, but annoying things.

you can abstract it away in a function

you could even automatically wrap each resolver in a function that does this conversation

if that’s what you would like

(I have the very problem you describe in my current project, and solved it in a similar way)

in my case I need to convert between graphql field names and namespaced keywords

Thought about it, but it looks a little hacky, also will decrease perfomance.

whether it’s implement in lacinia or in your code doesn’t matter much performance-wise

and even then, I wouldn’t be worried about performance on this kind of operation unless you have huuuge input/outputs

the time it takes to convert the keys of a small map to kebab case should be negligible compared to everything else happening in your app

e.g. network delays on your API

There is some truth in your words : ) Anyway, It will be much simpler to have all internals in kebab case and only change case between delivering response then transforming data back and forth in many places (even automatically). Isn't it?

I’m not sure; I quite like that the Lacinia schema is close to GraphQL’s conventions

for example, in my case I not only want to do conversion to kebab-case, but I also want to namespace fields

this does not translate to GraphQL (it does not support namespaces)

I feel those things are best left to be implemented in userland, leaving Lacinia as an unopinionated implementation of GraphQL

if you want to push those conversions as far out of your way as possible. write a function on the resolvers map (right before passing it to lacinia.util/attach-resolvers)

you could wrap each resolver in a function which does the conversion on args and on the output

then you won’t have to worry about it anywhere else in your app

for the output, another option would be to override the default field resolver

by default, Lacinia will resolve fields by doing something like (get object field-name)

http://lacinia.readthedocs.io/en/latest/resolve/overview.html#default-field-resolver

you can override this

to do something like (get object (->kebab-case field-name))

this won’t solve your input problem, but it will solve the output problem neatly

https://github.com/walmartlabs/lacinia/blob/master/src/com/walmartlabs/lacinia/schema.clj#L1096

for example:

(defn keyword-field-resolver
  [field-name]
  (fn [_ _ obj] (get obj (->kebab-case field-name)))
)

(lacinia/compile schema {:default-field-resolver keyword-field-resolver})

@andrewtropin ^

@hmaurer Thanks a lot for those tips. Will think about such a way.

@hmaurer: how are you handling namespaces? Do you just name your fields like myapp_somenamespace_fieldname and map them to myapp.somenamespace/fieldname by convention?

and do you do the same with enums etc?

@hmaurer: sounds like you’re taking a similar approach to graphql as we are, i.e. dynamically generating schemas based on existing data

the other approach to namespacing that occured to me would be to nest your stuff inside a field e.g.

{
   my_namespace {
      foo
      bar
      baz
   }
}