Fork me on GitHub

Hello guys and gals!! Could you help me please... I don't know, maybe graphql does not support this..but is it possible to have a non-null list of arguments of a type? for instance: { :type some-type :args { :arg-name-1 {:type some-type} :arg-name-2 {:type some-type}}} ...the idea is to make a client to use AT LEAST ONE of the above mentioned arguments. Is it possible to make something like: { :args (non-null { :arg-name-1 {:type some-type} :arg-name-2 {:type some-type}}) } or { :args (non-null (list [ :arg-name-1 {:type some-type}] [ :arg-name-2 {:type some-type}])} ?? both of the variants are not valid, but I think you understand what I mean.. ... MANY thanks!!


@arturaliiev I don't believe that's supported out of the box in graphql spec but have you seen ?


@rboyd, I will check. Thank you!!!

🚀 1

what are folks using for a cljs consumer? for a cljsrn app I wrapped apollo-client, but maybe I'm missing out looking at district0x/graphql-query and oliyh/re-graph. can anyone recommend these (or others)?


oliyh/re-graph was real easy to setup, especially with subscriptions.

👍 1

We're finally getting to the point where we're seeing Lacinia releases w/o corresponding lacinia-pedestal releases.


@hlship could I ask how you, or your library clients, are generating mock services through schema defined in lacinia? Currently, generating mocks for a 1000+ line schema is non trivial with test-check and my experience with lacinia-gen is buggy and unusable. Any advise appreciated!


I'm not sure I understand the question; we don't generate mocks for the services. Generally, our tests stand up our system, and we mock the back-end data, but pass everything through the Lacinia layer as it will in production.


When you mock the backend data, do you write generators based on the schema, or is it a-la-carte hardcoded mock? Asking because one of the hallmarks of graphql is to automatically generate mock objects with generators for queries and mutations. Apollo does this. However, in practice this is not easy without knowing the internal of lacinia. seems to solve the problem using test-check based generators, but it's buggy and doesn't work as intended. Happy to get your recommendation.


Generally speaking, we start with data obtained from one of our back end systems and mock the access layer (database or web service). The data we get from our internal systems is not under our team's control, so we tend to work from samples provided from the teams that manage that data. Mocking wouldn't make sense because we don't define the data, and the data we do need is typically a tiny slice of a gigantic ball of mud (of data) that comes from other teams.


That sounds familiar. It looks like, then, your team is not exploring generators from lacinia schema with test-check.