Allow setting the fetch implementation in the sdk #19458
Replies: 7 comments 3 replies
-
I will begin working on this even if not accepted as I need it for my project. If not accepted I will use this with |
Beta Was this translation helpful? Give feedback.
-
I did consider this at some point but opted not to implement that because it is already possible using the globalThis object. Any specific reason you dont want to use the or sveltekit specific:
export const load = (event) => {
globalThis.fetch = event.fetch;
const directus = createDirectus('http://localhost:8055').with(rest());
}; Or even like so when wanting to preserve the original fetch (which i dont think is technically needed within this SSR context if it's properly isolated per request, but i could be missing something ofc): export const load = (event) => {
const origFetch = globalThis.fetch;
globalThis.fetch = event.fetch;
const directus = createDirectus('http://localhost:8055').with(rest();
globalThis.fetch = origFetch;
}; This would be the way to polyfill (or overwrite) any of the APIs used by the SDK that are either missing in the JS runtime or just need to be overwritten for reasons. |
Beta Was this translation helpful? Give feedback.
-
I thought the same at first but I don't really feel safe to overwrite a shared global on the server which is used to make (potentially) authenticated calls and whose result is returned in HTML. Maybe the single threaded nature of node makes this not a problem but I feel a bit uneasy about that. Apart from that, I would like to create a directus client scoped to the current request. In sveltekit this is done with sequenceDiagram
participant req1 as SvelteKit Request 1
participant req2 as SvelteKit Request 2
participant api as Directus API
note over req1: begin handling request
activate req1
req1-->>req1: globalThis.fetch = event.fetch
req1->>+api: first call (1.1)
note over req2: begin handling request
activate req2
req2-->>req2: globalThis.fetch = event.fetch
req2->>+api: call (2)
api-->>-req2: response
api-->>-req1: response
req1->>+api: second call (1.2 with wrong globalThis.fetch)
api-->>-req1: response
deactivate req1
note over req1: end handling request
req2-->req2: unrelated stuff that takes time
deactivate req2
note over req2: end handling request
This would mean:
|
Beta Was this translation helpful? Give feedback.
-
I would like to give my opinion on this, but I would also like to bring a bigger picture on the topic. I wouldn't focus on a per-framework basis, but on something that most of them do already (and usually highly optimize on their own). The good old What I see as the problemCurrently the SDK forces the use of plain This is because, for sake of optimization and improvements, each framework could bring its own And this is the point: why force the framework where the SDK is being used at to use a I love the idea of having a default The solutions I see
Who would benefit from this?Ofc Take in consideration framework-specific tools (that potentially are implemented differently one from the other) like Payload Caching (huge for preventing multiple API requests), State Managements, Rendering Modes and so on. Making the creation of custom composable built on-top of the SDK incredibly easy, that could potentially never be created just because devs couldn't use their Personal notesI've come to realize this issue when discussing the rewrite of the nuxt-directus module with @Intevel, @casualmatt and @rijkvanzanten. |
Beta Was this translation helpful? Give feedback.
-
This feature request has been accepted and is queued to be implemented! You can follow along with the progress here: #19592 |
Beta Was this translation helpful? Give feedback.
-
This feature request was implemented here #19606 merged and shipped 😄 |
Beta Was this translation helpful? Give feedback.
-
Hello, has anyone managed to make it work with sveltekit? export async function load(event) {
const client = createDirectus('https://mydirectus', {
globals: {
fetch: event.fetch,
}
}).with(rest())
const result = await client.request(readSingleton('site_info'));
...
} I get the following error
|
Beta Was this translation helpful? Give feedback.
-
Summary
I want to specify a custom
fetch
implementation, when calling.with(auth())
,.with(rest())
or.with(graphql())
. Basically everything which ultimately calls therequest
utility function.Basic Example
or sveltekit specific:
Motivation
My main motivation is using the sdk with server-side rendering in sveltekit but I guess it will also be beneficial for environments without global fetch like old node versions.
Sveltekit gives us a wrapped fetch function. During SSR responses from calls of the wrapper are inlined in the html and can be replayed on the client without doing the request again.
Detailed Design
The composables
auth
andrest
already accept optional config arguments.graphql
will be expanded to also accept an optional argumentGraphqlConfig
.All of these types extend:
The
request
utility will take aconfig?: RequestConfig
and use the fetch if provided and else the global fetch:Each composable calls
request
with the new config argument.Requirements List
Must Have:
Drawbacks
Alternatives
Allowing to replace the whole
request
utility. This would be more or less the same config wise (or each extension would need a reference to the client class which could hold the customrequest
function).Seems more flexible but also more verbose for the developers.
Adoption Strategy
not needed as this is non-breaking
Unresolved Questions
No response
Beta Was this translation helpful? Give feedback.
All reactions