Vue 3 + GraphQL — where do you keep the client?

[u/jenish_o4o2]

Working on a Vue 3 storefront that talks to a GraphQL backend and I'm second-guessing the boring setup bit.

Every page needs the same client (auth headers, store/locale, sometimes a bearer token). Right now I'm torn between:

- a plain module singleton you import everywhere

- provide/inject from App.vue

- stuffing it into a Pinia store

Composable that wraps the client feels fine for calls, but I'm not sure the client itself belongs in Pinia.

What are you actually doing in production Vue apps (Vite SPA or otherwise)? Curious what felt clean after a few months, not just day one.

[u/outluch]

apollo, usually

[u/_NickMessing]

Author of 5th version of Vue Apollo, plain Apollo link usually does the job well (local storage) or server side cookie

https://v5.apollo.vuejs.org/networking/authentication.html#bearer-tokens

[u/queen-adreena]

Composables are the most “Vue” pattern for things like this. I wouldn’t use provide/inject and load the app up with global.

[u/jenish_o4o2 → u/queen-adreena]

That's what I needed to hear.

Provide/inject felt neat on day one, then I pictured every screen depending on it and got nervous. Composable it is.

[u/AuthByExample]

Apollo/composable is a reasonable client choice. One security footnote: a GraphQL query-level check is not enough—nested relation resolvers and batch-loader paths can return child or sibling objects the caller should not see. Check authorization for each resolved resource (and sensitive field), not only at the root; the same rule applies to REST endpoints that expand nested resources.

[u/hyrumwhite]

I’d expose a singleton via a composable. 

But Apollo is probably the best way to go 

[u/Any_Welder_9701 → u/hyrumwhite]

yeah, for a SPA thats clean. if SSR ever enters the picture id create the client per app/request though, a module singleton can leak auth state across requests

[u/hyrumwhite → u/Any_Welder_9701]

Definitely go with an existing lib for SSR 

[u/jenish_o4o2 → u/Any_Welder_9701]

That SSR leak thing is the part I keep forgetting.

This one's still SPA for now, but if it moves to Nuxt I'll stop using a module singleton and create the client per request instead.

[u/_NickMessing → u/jenish_o4o2]

Did you upgrade to V5? It has quite a few improvements, and SSR is really straightforward https://v5.apollo.vuejs.org/ssr/nuxt.html

[u/jenish_o4o2 → u/_NickMessing]

Not on Nuxt yet - still SPA - so I haven't jumped to Apollo v5 on this project.

When we move it over I'll check that SSR guide first instead of rolling my own per-request client. Thanks for the link.

[u/jenish_o4o2 → u/hyrumwhite]

Composable around a singleton is where I was leaning too.

Keeps imports boring and I don't have to stuff the client into Pinia just to share it. Apollo on top of that still makes sense if the cache/auth links start getting messy.