Vuex state management vs Apollo

General Prog (Archived)
, , ,
1

Hello,

New to Vue, but loving the ecosystem and the helper methods that are bundled in. Especially the ...mapGetters(['getters']);

i would like your opinion(community) why should i use Vue Apollo as a state management when I have Vuex store?

Also read this articles but for me it seems like the design of a rocket and if I have multiple components this will be very hard to manage.

Can i still use Vuex somehow?

Is there a more simplified way to use vue apollo then in the article?

Thanks in advanced

1 Like
2

The following is my personal opinion and experience, not an objective judgement on Apollo state management. Therefore, other people might legitimately have different experience and preferences. That said, the article states:

Now imagine an application fetching data from a GraphQL endpoint with Apollo client. By default, Apollo will store this data to Apollo cache. But what if we have some local application state, stored in Vuex? If we copy data from Apollo cache to Vuex, we’re doubling our data. If we leave data from the API in Apollo and local data in Vuex, there will be two sources of truth.

I disagree that having both the Apollo cache and the Vuex (or Redux, or any other state store) represents a problem. As much as I like Apollo for interacting with a GraphQL API, I find it gets quickly complex to use it for application state management. I think it makes more sense to separate application state from the query cache.

I prefer to consider the Apollo cache just a cache for the API request. I then manage application state separately. That usually leads to a more modular application, with loosely coupled components.

With a REST API, it is be totally fine to let the browser cache responses according to the cache headers, and also store in the application state whatever data is appropriate. I feel the same about the Apollo cache: I use it to speed up queries (when appropriate), but not as an application state store.

So, in short, I agree with you that the design proposed by the article is overly complex and tightly coupled. You can use both Apollo and Vuex if that feels better, and that is what I would suggest doing.

6 Likes
3

Hi normally I use Apollo cache when I don’t need to save data for future manipulation, as example some view data like user profile or comments. And disable cache with fetchPolicy: 'no-cache' when using Vuex and data should be shared with other components or just manipulated later like for example some session preferences. But it always depends what you need to do with data.

1 Like
4

Hi,

But if I have several components to display the comments should I cached them, aren’t they dynamic and change frequently?

Let’s say we have a display comments for each user in profile also display the comments on post?

5

Thank you for shading some light on this matter because i find it very frustrating to learn vue store then apollo comes along and says:

I can handle that better

But in reality they don’t offer a better solution just a more complicated and frustrating one.

I wonder how you can test an application like that(rhetoric question)?!

I will still keep this thread open and close it if no one wants to add something more:

experiences, ideas

1 Like
6

Ok, got it good question. So when you need for example in comment add likes or maybe answer, first you send a mutation and normally after getting an answer I would change DOM element. With apollo you can update your cache on mutation so you don’t need to handle logic of store apollo docs
I used vuex mostly to manipulate internal to frontend data like form, search and so on, but sometimes I need to save data from query and used it in another view or component. Like for example prices and details of some item.

1 Like
7

Thank you for explaining this @FelisOrion

Also have some uncertainty with what you mean by this:

What do you mean by this if you don’t mind, I can’t understand to what you are referring to in this part?

What DOM element?

8

Yes, so once you got your data from query you probably want to show them in template. So in vue your data is binding apollo query

data: function() {
    return {
      allTasks: {}
    };
	},
  apollo: {
		allTasks: {
      query: gql `
        { 
          allTasks {
              idtask
          }
        }`
  }

Then to show them in template you just iterate list of items for example, witch will create element of DOM. If you are going to modify them with mutation, you probably what to modify also element of DOM corresponding of your item. So in vue you just update data binding like this.allTasks[3] = newData so then element in your template also will update.
Sorry for my english, not native speaker. I hope you understand what I mean.

1 Like
9

@FelisOrion Don’t worry i understand what you are trying to say. I am also not a native speaker.

Now i get it you were referring to the v-for in the template and how apollo automatically renews the cache at each change so no more store.

Apollo watches the chnages and modifies the data on the fly.

Thanks for writing this example now I understand better at what you were referring too when you said replace the DOM element.

1 Like
10

Thank you everyone, really appreciated the inputs,ideas and also uses cases of Vuex(store) and Apollo(state).

Learned a lot from what you shared.

I am closing this thread

11

I’ve worked quite a bit in Vuex and Apollo. In my opinion, they are not mutually exclusive, but I would NOT use Apollo beyond the GraphQL API interaction.

I tend to wrap my GraphQL calls (via Apollo) in Vuex actions / mutations. Responses get assigned to the Vuex store state (sometimes with some sanitization / formatting). I do the same for Axios (REST) calls, and even retrieving data from local storage. I also use Vuex for computed properties, leveraging Vue’s reactivity (nothing to do with GraphQL).

Then there’s SSR, which is a whole other ball of wax…

Basically, that article is well and good as a POC, but not very realistic for a real-world application (IMO).

2 Likes
12

After I experimented a bit i also agree that Vuex can be used for csrf sessions and form data(maybe more). Also it is nice to know that Apollo state will update the cache on the graphql side.

So the best solution as you stated @bjunc, both have there place and use.

Thanks for adding you opinion and exprience.

PS: using only nuxt from now on google is not indexing spa’s anymore, confirmed on their blog.

13

Google was never really great at indexing content rendered by JS in the browser anyway (eg. SPA). Nuxt is a nice solution. We’re currently using it on Edgewise. Elixir / Phoenix API, with a Nuxt presentation layer.

https://edgewiserealty.com

Although, I look forward to the day that I feel comfortable swapping out Nuxt for LiveView :slight_smile:

2 Likes
14

The website was loaded very fast and the overall experience was nice, thanks for showing me a production website using the stack.

Also congrats to the dev team for the site.

1 Like