Agree

[Austio]

Hey Pier, i agree with what you are saying. We have been integrating apollo into a project and my thought for a while has been that we will ultimately roll our own framework for graphql and vue.

I think the thing with using apollo and vuex is that you are doing double duty (redux and vuex) on all of your requests and you also lose some of the great stuff that apollo does with auto updates on update like actions.

Have you considered working on a library that is essentially taking all the stuff that is generic from apollo and applying it to a vuex backend?

[PierBover]

I totally agree with you. There needs to be an abstraction to remove all the boilerplate.

My first hunch would be to create a library that generates Vuex modules. Those could be easily integrated into a regular Vuex store. From a Vuex perspective that would work.

From a GraphQL perspective I don't know if such thing is possible. I have only been playing around with it for a couple of days. It seems easy to get a generic solution for querying, but what about subscriptions? Do all GraphQL servers send the same mutation messages (CREATED,DELETE,UPDATED) with subscriptions? (those are the ones Graphcool returns)

[onelastjedi]

@PierBover, @Austio, i'm also think about a library that can remove my weird boilerplates too. What about opensorced anything together?

@PierBover, maybe use GraphQL's servers mutation messages as arguments?

[PierBover]

@wearemieta sure let's do it.

What do you have in mind?

[onelastjedi]

I haven't a lot of experience, but i think a good starting point — types in the graph.cool schema. What we see when added a new type? Basic queries and mutations like 'createFile, deleteFile, allFiles', etc. Next we create the actions in the Vuex store with graphQL queries. Very similar actions for the different types, very similar queries. The main purpose for the library is DRY. So, we need anything like 'generic programming' or 'metaprogramming' maybe? @PierBover, do you have a good examples of code with same functionality which we could discuss? And can you quick prototype an API with pseudocode?

[PierBover]

Give me a couple of days and I'll get back to you.

[onelastjedi]

Ok. See you.

[RichAyotte]

I'm starting to see the overlap between Apollo Client and Vuex stores and I have a feeling that it will cause performance issues both in memory and processing in my project. Perhaps for now, something like https://github.com/f/graphql.js combined with Vuex is better since it doesn't have its own store but the idea of automatically creating Vuex modules from GraphQL queries is interesting too. Is that what you're suggesting?

[PierBover]

Is that what you're suggesting?

Yes something along those lines. Do you have any ideas?

[dohomi]

@RichAyotte what kind of issues are you facing? I am using @PierBover approach and didn't crash into any issues.

One question though: I have ~22 schemas, and inside of my admin. On each page I show a list and update/create/delete forms to mutate the schema list.

Should I reset/empty the vuex state list on router page change? worst case would be, that the user will open every 20 pages and this means that all 20 vuex states will be set.

Thoughts?

[PierBover]

@dohomi I'm not sure I follow you, but you don't really need to reset it unless you are dealing with large amounts of data.

If you are using subscriptions it may be a good idea to keep the subscription open depending on your use case.

For example, if you have a list of products and keep the subscription open in the back (even when the user isn't viewing your product list) you will already have the latest updated data. When the user comes back to the products list and there will be no loading time. I used this approach on a number of Firebase projects and it worked great.

[dohomi]

@PierBover there will be ~30-200 items inside of each state. and then it depends on the pagination how many items on each page are assigned additionally.

Do you run the dispatch every time you enter a state or do you skip it if the store.state items are already available?

Currently I unsubscribe on every destroy of a page element. Will try to keep it open as well and see how that performs

[PierBover]

Do you run the dispatch every time you enter a state or do you skip it if the store.state items are already available?

It depends on the use case.

Generally I load all the data from the server and filter in the client. Then the data on the client is updated in the background via subscribes (which only update changes not the whole data). And yes I only subscribe if there is no currently active subscription.

[dohomi]

Ok sounds like my approach I was taking as well. One question though: do you know how to set a store.state that the subscription currently fetches/updates some data? I want to display a progress bar to show that some data is currently changing. I couldn't find it in apollo yet

[dohomi]

Here a gist of my whitelabled apollo module + mixin: https://gist.github.com/dohomi/e101dea40cb4483b1d6e0dd81f9ce788

[RichAyotte]

@dohomi I have not yet run into performance issues but I am anticipating them especially on mobile. I also don't like storing double+ the required data for no reason other than overlap in store functionality; it feels dirty even if the performance hit isn't that significant atm. Ideally, the client only holds a single copy of the required data in Vuex, nothing more.

I'm leaning towards just replacing Apollo Client with GraphQL.js to accomplish this but before I do, are there any cases where Apollo Client would be superior?

[PierBover]

it feels dirty even if the performance hit isn't that significant atm

There won't be much of a performance hit, only the memory consumption for stored objects. Unless you are storing large amounts of data (hundreds of thousands / millions of items) it should be insignificant.

The biggest bottleneck in performance is by far rendering the UI, not handling objects, arrays and such. Even 5 year old devices should be able to store/access an object or an array hundreds of thousands even millions of times per second.

Network IO can be another factor if your use case involves realtime or, again, moving large amounts of data.

I'm leaning towards just replacing Apollo Client with GraphQL.js to accomplish this but before I do, are there any cases where Apollo Client would be superior?

Frankly I have no idea. I barely played a bit with Apollo Client myself.

[onelastjedi]

I absolutely agree with @PierBover. I can't imagine the situation in real world when the client stored data can exceeds machine memory and hit a performance.