vue-apollo and vuex interaction best practices

[alidcast]

Hi @Akryum!

Apollo's cache and vuex's store seem to have some overlap in terms of usage, so how would you recommend using vue-apollo and vuex together?

The usual approach with REST would be to have a folder that holds the api service and a folder that holds the state store (this is how Gitlab does it), and then have it all come together inside the main component; another approach is to have the api service/calls integrated into vuex actions.

My first instinct was to use the vanilla apollo plugin and follow one of the above approaches. But then I realized that graphql is a different paradigm - the component queries and mutates its own data - hence why you tightly integrated query fetching inside components. So it'd be great to have the creator of the plugin weigh in on best practices.

Thanks

// This is to related issue #7, so I'll cc people who might be interested in this discussion @PierBover @SebT @RichAyotte @smolinari

[gijo-varghese]

@alidcastano I'll tell you from my experience (I'm building a chat application, something like Slack)...

I was also a big fan for Vuex when using REST. But after using Apollo client, I no longer needs Vuex. Vuex is some sort of Flux/Redux implementation. It's already built in Apollo client.

All data I need is inside the Apollo cache, and I access it directly. You have full access to that cache so that you can insert, update and do everything with it.

So after playing with Apollo client cache I really think there is no need for Vuex (in my case). But in some cases, I still need a simple centralized store to save some information like selected_user_id. For that, I use Vue-stash

Again, it's from my experience. Maybe it doesn't fit for you. What are you building?

Waiting for expert opinions...

[Akryum]

Side note: one of Apollo Client 2.0 good news is that we can write a vuex implementation of the apollo cache. That may open nice possibilities like getting apollo data directly in getters.
Side side note: the default in-memory cache is no longer using Redux (so you don't have Redux + Vuex anymore in your app).

[SebT]

Yeah I'm eager to use apollo-client 2.0, it has so really nice features.

To answer your question from my experience @alidcastano, there is no problem with using vuex + apollo. It just depends on how you use them.

If your application uses a REST api, the Gitlab approach is very nice. You query your API, and store data in any format you wish in your store for further use in your application, vuex is not only used as a local app state manager but can also be used as a cache manager.

Apollo is made to interact with your graph API. You send a query, the result is normalized by stored in apollo's redux store, is a similar way the Gitlab approach uses vuex for.

So apollo (vue-apollo for easier integration) is the tool of choice to interact with your API data, locally and remotely. But you still need a tool to manage your local application state. Sure, components have state and you can pass is down to children components. But sometimes you need transversal data. The is where vuex comes in.

For instance you can have a currently selected item id (that comes from apollo) stored in vuex, so that you can request this item via apollo in different components. By default, if a query was already fetched, apollo will use the redux store instead of re-querying it, so don't hesitate to do the same query multiple times.

TL;DR: Use vue-apollo to interact with your graph API. Use vuex to manage your local app global state. But you shouldn't duplicate data between vuex and apollo.

[alidcast]

@gijo-varghese What's interesting is that Facebook created the Flux pattern and they also created Graphql... But yea I had a similar feeling that most aspects of Vuex are not necessary given that Apollo 2.0 comes with its own cache/store implementation.

As @SebTSo mentioned, Grapql can manage component local and remote state, but you still need a way to manage application state - which is where Vuex getters (or vue stash) could come in. 👍

I'll go ahead and close this issue since the gist of the question has been answered but feel free to still add to the discussion. Thanks again guys.

[SebT]

@alidcastano: The flux pattern and graphql are made to work together. The apollo client implements the flux pattern (because it uses redux, which is derived from flux).

The only question I have now is what would be the best way to do keep everything in sync

Actually, you shouldn't imo. Apollo should be the only one handling data from API. And vuex/vue-stash shoud only manage your local data (dumb example: a click counter).

But sometimes you need to reference API data with vuex. Let's say your app is in logged mode. You often need to access the current user's name for instance. You can store the userId in vuex, but every time you need to access the name, you should to an apollo query in your component.

The confusion is caused by th fact that 2 state managment tools are present in the same app. Apollo 2 will be much more intuitive because you'll be able to use vuex for local state and API data.

EDIT: Maybe you meant "in sync" with your API data, not in sync between vuex & apollo. That makes my answer unrelevant.

But if that's what you meant, you can specify a fetchPolicy for each request so that a network request is done everytime.

[lobosan]

A fullstack example with real world cases would be super helpful or even a video tutorial in Udemy. Otherwise it feels like Vue is falling behind React which has a more mature ecosystem and examples in terms of GraphQL. Ideally there should be an official implementation of Apollo that replaces Vuex

[Akryum]

@lobosan Did you take a look at https://github.com/Akryum/devfest-nantes-2017 ?

[beebase]

@Akryum

Side note: one of Apollo Client 2.0 good news is that we can write a vuex implementation of the apollo cache. That may open nice possibilities like getting apollo data directly in getters.

Wouldn't it make sense to drop vuex altogether and put stuff like local session state in apollo client as well?

[SebT]

@beebase nope. Apollo's job is to interact with a server via the graphql queries (or mutations & subcriptions). It stores that data locally in your app so that you don't have to query the server every time you need some data. To do so, it uses a state management library (redux in apollo-client 1.x) to manage a representation of the data in your app's memory.

Most people using vue-apollo already use vuex in their application to manage their app state (usually non-persisted state). So it makes sense to drop redux & tell apollo to store its data in vuex instead. Because you're already using it for your app local state, you don't need 2 state management libraries.

[Akryum]

Using apollo as a client-side state management system is becoming more and more popular, thanks to https://github.com/apollographql/apollo-link-state

[beebase]

@SebT

So it makes sense to drop redux & tell apollo to store its data in vuex instead.

Do you mean like apollo directly writing into vuex state, or apollo triggering vuex actions, that write to vuex state?

Either way, with apollo 2.0, you can make local state persistent, control interaction with server, control caching, and it has the same reactivity in components like vuex has.
So I don't see why I would still use vuex.

The only thing that's a bit funky, is writing queries inside components as opposed to vuex. It feels like you might end up with duplicate code and I wonder how maintainable this is in very large apps.
I guess you could build vue query components (factories) to avoid repetitive graphql. But then again, this might lead to over-fetching again 😕

[Akryum]

@beebase Write .gql files 😄

[beebase]

@Akryum yes I am, but at the same time that probably only makes sense for queries/mutations being repeated in multiple components?