[maxdo]

I want to reproduce simple use case : header authorization , parallel requests , if token stoped , I want stop all requests that are behind in the queue, refresh my token, do requests again. Unfortunately your architecture limits us to JS style of development when failed request is ok, user will refresh the page. On mobile it's not the case. You close all the related tickets on github. So we build our own solution with mutex and other crap to make it somehow working in that way just because we already invested on backend in graphql. If not , I'd better avoid apollo and graphql.

[martijnwalraven]

I wouldn't call that an architectural limitation, but you're right the default network transport in Apollo iOS doesn't currently support your use case. You can plug in your own network transport implementation however, or integrate with something like AlamoFire for example. I'd definitely like to make this easier and document it better, but I don't think it's a good reason to avoid Apollo or GraphQL altogether. I'm not sure which issue I closed before, but please reopen it if you want to discuss this further and make the client work for you!

[maxdo]

You simply can't do it on android and it's huge degradation for any project that cares about quality

[omegavesko]

>Unfortunately your architecture limits us to JS style of development when failed request is ok, user will refresh the page.

On what planet is this "the JS style of development"? SPAs don't want to force the user to refresh the page for no good reason for the exact same reason that you don't want the user to close your app because their token has expired. The idea really isn't significantly different.

[raarts]

I don't understand the problem, why can't parallel graphQL queries be resent individually when the token is denied?