RFC: Async Client fetchOptions support

Summary

We use Keycloak as a service-to-service authentication layer, and want to use URQL on server. Grabbing a (JWT) access token means reaching out to it over the network, and tokens have a low TTL with a refresh token. The way we could resolve this with current implementation is “hacky”, in pseudo-code:

let token;

const client = createClient({
  url: 'http://bla.bla',
  fetchOptions: () => ({
    headers: {
      Authorization: `Bearer ${token}`
    }
  }),
});

// here's where it gets awks

getToken().then(t => {
  const jwt = decode(t)
  token = jwt.access_token
  setTimeout(() => {
	t = null;
    getToken();
  }, jwt.expiration_date).unref() // just to sketch, it's not how it works obvsly.
});

This kind of works (I know it can be made to work correctly), but there’s a real chance that if this server is under high load that some requests miss their token while a new one is being requested. Making this code work just gets more and more awkward…

Proposed Solution

I understand this has potential performance implications, but what if fetchOptions’s function form has this signature instead of the existing one?

fetchOptions: RequestInit | () => RequestInit | () => Promise<RequestInit>

This would quite elegantly solve our problem:

const client = createClient({
  url: 'http://bla.bla',
  fetchOptions: async () => ({
    headers: {
      Authorization: `Bearer ${await getOrFetchToken()}`
    }
  })
})

Requirements

• Should not break existing behavior
• Existing behavior should take as little of a performance hit as possible.

[kitten]

Closed since #939 is merged. Let’s see how that goes for now! 🙌

[JoviDeCroock]

Hey,

I like the idea since it solves cases for react-native,… as well, if only the fetchExchange has to worry about this we should be fine.

Just a sidenote: at this moment in time we advise this to be solved in an exchange https://formidable.com/open-source/urql/docs/common-questions/#how-do-we-achieve-asynchronous-fetchoptions