graphql 2017-07-06 | Slack Archive

boubalou17:07:00

@hlship Does Lacinia enforce the presence of a return type for a mutation? (I was building a simple delete of an entity and was wondering if I have to absolutely provide a return :type in the schema.)

boubalou17:07:54

I might have my answer:

#error {
 :cause Could not process type.
 :data {:type nil}
 :via
 [{:type clojure.lang.Compiler$CompilerException
   :message clojure.lang.ExceptionInfo: Could not identify type of field. {:field {:description "Share a project to another user.", :args {:projectId {:type (non-null ID)}, :email {:type (non-null String)}}, :resolve #object[blueprint.graphql.mutations$project_share 0x37156bfb "blueprint.graphql.mutations$project_share@37156bfb"]}}, compiling:(base_resolver.clj:11:13)
   :at [clojure.lang.Compiler$InvokeExpr eval Compiler.java 3657]}
  {:type clojure.lang.ExceptionInfo
   :message Could not identify type of field.
   :data {:field {:description Share a project to another user., :args {:projectId {:type (non-null ID)}, :email {:type (non-null String)}}, :resolve #object[blueprint.graphql.mutations$project_share 0x37156bfb blueprint.graphql.mutations$project_share@37156bfb]}}
   :at [clojure.core$ex_info invokeStatic core.clj 4617]}
  {:type clojure.lang.ExceptionInfo
   :message Could not process type.
   :data {:type nil}
   :at [clojure.core$ex_info invokeStatic core.clj 4617]}]

hlship18:07:11

Yes, mutations must have a :type. Typically, the :type corresponds to the object just modified; on a delete, you may want some kind of Ok placeholder.

hlship18:07:37

Pending code destined for 0.19.0 beefs up the spec for the schema. Most of the cases discussed here will result in spec exceptions.

hlship21:07:22

I'm starting to look at GraphQL subscriptions w/ Pedestal. I'm modelling it on Apollo: https://github.com/apollographql/subscriptions-transport-ws If I do a good job, the Apollo client will work with lacinia-pedestal.

hlship21:07:14

.. I'm guessing quite a bit, since it's written in TypeScript which I've never learnt. Ah, this helps: https://github.com/apollographql/subscriptions-transport-ws/blob/master/PROTOCOL.md

hmaurer21:07:02

@hlship that would be great. Note that Relay Modern should also be able to support subscriptions of this kind

hlship21:07:16

Just puzzling it all out. It answers my internal question about how the client knows when the subscription completed, rather than hit a network partition or server crash. I'll be putting something provisional together and then probably need to iterate a bit.

hlship21:07:26

I'm hoping that there's a good way to reuse most of the existing Pedestal code, but Pedestal interceptor chain doesn't feel like a perfect fit here.

hmaurer21:07:47

I don’t think there is strict specification for GraphQL subscriptions anyway. For the transport that is. Apollo has their approach, but Relay Modern for example seems completely agnostic.

hlship21:07:30

No, there isn't a strict transport solution. I'll need to look at Relay Modern as well, but I suspect these things layer on each other.

hmaurer21:07:35

Something that you would need to get right imo is authentication / authorisation with subscriptions. e.g. have an easy way to filter out outgoing messages and ensure they are only sent to the right clients

hmaurer21:07:11

This issue gives some insights on how to deal with subscriptions with Relay modern: https://github.com/facebook/relay/issues/1655

hmaurer21:07:15

(I was just looking at it now)

hlship21:07:27

Looks like auth/auth should only happen once, on initial connection. After that, it's a private connection between that client and the server.

hmaurer21:07:29

The doc on the Relay website is pretty poor right now…

hmaurer21:07:33

What model were you thinking of to push new updates to a subscription on the backend?

hlship16:07:26

hmaurer: The implementation in lacinia-pedestal will be based on core.async channels. The API defined by lacinia is based on simple callback functions.

hmaurer16:07:09

@hlship curious to see it when it gets released

hmaurer21:07:58

core.async channels?

2017-07-06

Channels