I was going to open a PR to add credentials
as an option to the HttpLink
and/or ApolloFetch
api, but wanted to open a ticket to discuss first.
Currently it appears the only way to add credentials in HttpLink
is through a custom ApolloFetch
provided by the fetch
option, either with a middleware or a custom constructOptions
.
That works fine, though it feels like the wrong place to need to add this. Since credentials are part of the top-level api for the global fetch
, it seems it should be made a bit more first-class and be provided as an option to either HttpLink
, ApolloFetch
, or both particularly since it's usually tied to the uri, and not specific to the request.
new HttpLink({uri: 'https://www.example.com/graphql', credentials: 'include'})
or
new HttpLink({
fetch: createApolloFetch({
uri: 'https://www.example.com/graphql',
credentials: 'include'
})
})
Also, wanted to get any thoughts on adding headers
as another new top-level option on either of these classes, for specifying default headers that should remain consistent across any requests - merged with a the standard headers provided by ApolloFetch
unless they're later modified by a middleware.
new HttpLink({
uri: 'https://www.example.com/graphql',
credentials: 'include',
headers: {
'X-Example-Header': config.VERSION
}
})
or
new HttpLink({
fetch: createApolloFetch({
uri: 'https://www.example.com/graphql',
credentials: 'include',
headers: {
'X-Example-Header': config.VERSION
}
})
})
Hmm, this is definitely one thing that was easier in the previous network interface implementation. I think it should probably be possible to do everything with just HttpLink
IMO, but curious what @jbaxleyiii thinks.
Also, @jaydenseric what do you think?
Just asked James, we like the first example:
new HttpLink({
uri: 'https://www.example.com/graphql',
credentials: 'include',
headers: {
'X-Example-Header': config.VERSION
}
})
I think that would include modifications to apollo fetch as well, right?
Cool
I think that would include modifications to apollo fetch as well, right?
Correct, they'd pass through from HttpLink
/BatchHttpLink
to apollo fetch and presumably be merged into the options object here.
@tgriesser that would be awesome - do you have time to work on a PR for that?
Yep, I'll get something over in a bit
Thanks!
Also, @jaydenseric what do you think?
I don't fully appreciate the consequences of this proposal as the way all these new packages link together still hasn't clicked for me yet, even though I'm productively using them.
Unless I'm confused, is it a good idea this high up in the API to bake in support for fetch
API options such as credentials: 'include'
when a custom fetch function might use something other than fetch
internally, such as XHR?
As an side note, auth header examples are pretty different looking between apollo-link
and apollo-fetch
:
Is apollo-link
really intended to be used directly when building apps anyway?
this is definitely one thing that was easier in the previous network interface implementation.
IMO it has been as easy, or easier (WIP documentation aside) than before to set everything up. A real-world batched client setup with auth headers and uploads for a SSR Next.js app (see example without auth here for context):
import { ApolloClient } from 'react-apollo'
import BatchHttpLink from 'apollo-link-batch-http'
import { createApolloFetchUpload } from 'apollo-fetch-upload'
function createApolloClient({ initialState, getViewerToken }) {
const apolloUploadFetch = createApolloFetchUpload({
uri: `${process.env.API_URI}/graphql`
})
apolloUploadFetch.batchUse(({ options }, next) => {
const viewerToken = getViewerToken()
if (viewerToken) {
if (!options.headers) options.headers = {}
options.headers.authorization = `Bearer ${viewerToken}`
}
next()
})
return new ApolloClient({
ssrMode: !process.browser,
initialState,
networkInterface: new BatchHttpLink({ fetch: apolloUploadFetch })
})
}
For auth related fetch headers I used to have them fixed for SSR and as middleware for the client, in case the viewer situation changes between operations in a group of batched requests. For simplicity I just use middleware for both now since it doesn't seem to really slow SSR.
Is apollo-link really intended to be used directly when building apps anyway?
I'd claim that the code sample above qualifies as "using it directly", since you still have to deal with the configuration API.
I think you've got a good point about custom fetch functions that might have different APIs than window.fetch
.
Would it be fair to say that the idea of building this into apollo-fetch
is less controversial? What's our confidence level that having a credentials: include
option on apollo-fetch
would be a good idea?
I might not fully understand the challenge here, but perhaps credentials
could be used at the Link level _or_ the fetch level where fetch defined credentials override Link defined credentials. It seems like the design approach has been to provide helpful defaults in a Link in addition to providing convenient ways to set fetch behavior.
Until this lands on an established pattern, I'll be taking this approach which seems independent of any changes made Link-wise.
const fetch = createApolloFetchUpload({
uri: '/graphql'
});
fetch.batchUse(({ options }, next) => {
options.credentials = 'same-origin';
next();
});
I also noticed the docs have been getting updated recently. Does anyone know the current API design direction for this issue?
I think we should allow credentials and headers to the constructor for the http-link https://github.com/apollographql/apollo-link/tree/master/packages/apollo-link-http#options.
I'll assign and do this!
Supported via https://github.com/apollographql/apollo-link/pull/144!
@jbaxleyiii Since credentials
is configurable on apollo-link-http
, but it is not available on apollo-link-batch-http
.
any news on credentials
being available for apollo-link-batch-http
?
Would be great to have it on apollo-link-batch-http
, we had to disable batching in production and are seeing a huge increase in dyno usage.
@moimael until there's an API on apollo-link-batch-http
the workaround is using the solution described here: https://github.com/apollographql/apollo-link/issues/44#issuecomment-334324307
@tgriesser, @stubailo, any news on solving this?
Can you open a new issue specifically for the batch link?
@stubailo done. See #343
Most helpful comment
@jbaxleyiii Since
credentials
is configurable onapollo-link-http
, but it is not available onapollo-link-batch-http
.