Closed nathanchase closed 1 year ago
Hi @nathanchase. Actually, for the perspective of API and Service worker (PWA module) it doesn't matter what http client you use. You can use axios, http, native fetch or ohmyfetch and all would be cached in the same way by the service worker.
Hi @nathanchase. Actually, for the perspective of API and Service worker (PWA module) it doesn't matter what http client you use. You can use axios, http, native fetch or ohmyfetch and all would be cached in the same way by the service worker.
I was under the impression axios calls would not be cached, because "the serviceworker can only intercept and cache http requests sent via the fetch api"?
https://github.com/axios/axios/issues/1219 https://github.com/axios/axios/issues/484
Either way, it would be very helpful to a lot of developers to have some sort of understanding as to potential best uses of ohmyfetch in comparison to other http clients. For the uninitiated, it's hard to know what to choose.
In fact, XHR requests will be also caught by fetch when the service worker (workbox cache) is registered but (issues you linked) you cannot use axios
in the service worker script itself (nor any other XHR-based HTTP client), and fetch is the modern choice for any new project while there might be still reasons to prefer Axios because of its specific features.
The goal of this project is not to provide a full HTTP client (like axios, ky and nuxt/http) but exactly as mentioned in the documentation: A DX enhancement over native fetch which is assumed users are already familiar between using ohmyfetch.
BTW I can fully relate to your frustration to choose one HTTP client for Nuxt apps and that there are many solutions. At the moment I would recommend nuxt/http module but soon with nuxt 3 and bridge, there will be a new built-in composable (useFetch
) based on ohmyfetch and we start to deprecate Axios and HTTP modules and there would be one ohmyfetch-based way to do it.
I would recommend nuxt/http module but soon with nuxt 3 and bridge, there will be a new built-in composable (
useFetch
) based on ohmyfetch and we start to deprecate Axios and HTTP modules and there would be one ohmyfetch-based way to do it.
Thanks very much @pi0 for that insight! I currently use axios since @nuxtjs/auth-next requires it, as well as using axios's adapter enhancers for LRU caching, retries, and advanced logging (adding timestamps, request/response durations, status for SSR calls).
If the path forward for future projects is a useFetch
composable, I'd implore all involved to consider first-party support for these types of enhancements (auth, caching, API retries, logging) - particularly as it relates to their use with SSR in Nuxt 3.
I look forward to Bridge and Nuxt 3!
BTW I can fully relate to your frustration to choose one HTTP client for Nuxt apps and that there are many solutions. At the moment I would recommend nuxt/http module but soon with nuxt 3 and bridge, there will be a new built-in composable (
useFetch
) based on ohmyfetch and we start to deprecate Axios and HTTP modules and there would be one ohmyfetch-based way to do it.
Are JWT tokens going to be supported seamlessly in useFetch and useAsynFetch? Or is that something we should use @nuxtjs/auth for? And will it be ported to use ohmyfetch (currently requires @nuxtjs/axios)?
Time goes by! I think majority of ecosystem are nowadays migrated to fetch native implementation. closing old issue for maintenance but still would be happy to rediscuss or if you like to make a PR to add migration guide from axios to the docs 👍🏼
As I'm finding the need for caching axios API calls and seeing that that Service Workers can't access those calls, I am wondering if using ohmyfetch for API calls (and integrating it with workbox runtimeCaching) is a better solution moving forward.
As part of migrations from Vue 2 / Nuxt 2, it would be extremely helpful to know how/why/when to use ohmyfetch instead of axios, and the process by which one might cache calls made using runtimeCaching.