[martijnwalraven]

I'm one of the developers of the Apollo iOS client, so I'm definitely interested in hearing your feedback. I know we're missing some features compared to the JavaScript client, but both the Android and iOS clients seem fairly stable and are used in production. I'm especially intrigued by the need for a 'custom mutex and other painful tricks'. Maybe this isn't the venue for detailed discussion, but please open an issue on one of the repos or post a message on #android or #ios on the Apollo Slack so we can dive into this further!

[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?