@nilan I’m beginning to make something bigger than the typical examples with Graph.cool. I can see a lot of boilerplates around the handling of the data (like

update

,

subscribe

, etc...), things that seems to be repeated all the time. Before I try to create my own boilerplate codes around these routines, might there be some already existing library to handle these annoying tasks?

@eliezedeck +1 for your offer to create a Graphcool SDK, that deals with all of that. 😉 Please share! 😄

Well, this sort of thing should already exist somewhere though. Hence the question 😉

The most you can get are the GraphQL client libraries I guess...

I'm not sure I understand what you're asking, can you elaborate?

A wrapper around the existing GraphQL client libraries that is more suited to the specific implementation details of Graphcool

Thanks @agartha, those, along things like making for instance a specific Query + Subscription seem like a single entity that will do the right thing upong DELETED, CREATED, etc..., as well as automatic handling of optimistic UI, etc... But what I’m really looking for is to make Query + Subscriptions become like a seemless Live-query of some sort. Of course, it will be opinionated, but that’s fine. Also, something that would make handling the data, in or out, faster. I find myself doing a lot of boilerplates just to handle data.

So more like a helper library, @eliezedeck ?

Yes

Maybe you can find some helpful libraries/tools/examples here: https://github.com/chentsulin/awesome-graphql

I’m using VueJS which relieves me from a lot of boilerplates. Things like that should already exist, because I do not believe in writing the long codes that I see in Apollo or Graph.cool examples.

do you think the way the examples here are setup can be improved? https://github.com/graphcool-examples/vue-graphql

@nilan I thinks so! I mean, I’m not a pro in either Vue or GraphQL, but to me, it looks likes the old days of PHP: you had to write all sorts of operations. For example, the Query and the Subscription should be closer together. Avoiding the

refetch

, after all, it’s already using a subscription, and combining the

update

handler of both the Query + Subscription. I agree that it was written with the intent to make newcomers understand everything that is going-on instead of presenting a magic API. But for big production software, these should and can be reduces with some helpers. Unfortunately, such thing doesn’t seem to exist yet.