Fork me on GitHub
#graphql
<
2020-01-29
>
Jakub Holý (HolyJak)11:01:58

Hello folks, what library do people use as a GraphQL client? Lacinia is only the server-side, no?

gklijs14:01:20

Yes, lacinia is server only. You can use re-graph it should support even Clojure now. Another common client for the JVM is the android one https://github.com/apollographql/apollo-android?files=1.

👍 4
isak15:01:26

I don't see the need for a client, just using normal http calls

orestis16:01:42

We’re doing plain http calls — but I have it on my roadmap to see what Apollo offers, mostly to get a “global store” of sorts. If that seems too big, I have a rough plan to see if I can use Keechma’s EntityDB for the global store, and leverage Transit to get CLJS objects.

orestis16:01:19

We’re also currently writing a macro of sorts to validate queries (at CLJS compile time) against our Lacinia schema. Still tinkering with it though.

myguidingstar18:01:03

People familiar with Fulcro web framework can use Pathom to translate (Clojure-native) EQL to graphql and have the data fetch at the same time. See Pathom documentation Graphql section for details

gklijs09:01:48

For testing subscription I created my 'own' client, it's practically just taken from re-graph, but clojure only and different api https://github.com/openweb-nl/kafka-graphql-examples/blob/master/test/src/nl/openweb/test/graphql_client.clj.

lispers-anonymous15:01:46

I've been working on a cljs graphql client that draws a lot of ideas from apollo. The caching from apollo is really nice and it's mainly what I'm trying to replicate using reagent atoms and cursors. Is that something you think you'd be interested in using?

orestis16:01:32

Yes, mostly caching and normalizing of data. Though caching scares me - they didn’t have a way to evict items from cache until the (unreleased) version 3

☝️ 4
orestis16:01:48

I’m not using reagent but exploring the idea (in my head) to model something using an agent-like abstraction

lispers-anonymous17:01:21

The advantage of using reagent atoms for the cache is it can still be updated outside the normal query/mutation APIs. So it looks something like

(let [my-favorite-atom] (query gql-client data-for-query)
  (fn []
     [:div (-> @my-favorite-atom :data)
       [:input {:type button
                :value "evict stuff from cache"
                :on-click #(reset! my-favorite-atom nil)}]]))
That would evict that particular query from the cache in the way I currently have things set up. Any other components that use the same query would also be cleared because they share an atom. A similar approach could be used to clear the entire cache if you wanted to do that. Just reset the atom and it's all taken care of.

orestis17:01:12

Is the caching per-query or per-entity? That’s the normalizing that I was referring to. Keechma’s entity DB is what I’d like to look into.

lispers-anonymous17:01:36

I just started working on this last weekend and implemented a cache entry per query. But the entire cache is just a giant clojure map. and cursors can be used to create a "window" into the cache at any point, including individual entities in say a list of users. So if you had a query that returned a list of users, the query would provide the component with a single r/atom with all those users. Then if you wanted to create a component for each user entity, a cursor could be created for each of them and passed into those component functions. As something like a subscription or mutation updates each user entity individually in the cache (I've not implemented that), then those user components would be updated. Apollo provides support for this as well with readFragment I believe https://www.apollographql.com/docs/react/api/apollo-client/#ApolloClient.readFragment So the client I'm working on could do something similar to provide what looks like a cache per-entity.

lispers-anonymous17:01:27

An thanks for asking that. This have given me a lot of ideas and things to think about

souenzzo19:02:03

#fulcro with #pathom remote can do "graphql client"

👍 4