-
Oct
23Cancellable apollo-client queries
Posted in : apollo-client and typescript
If you ever had to work with a GraphQL API featuring a few slow queries, you’ll probably understand the need to be able to cancel
apollo-client
queries. I’m usingapollo-client
3.2.5, the latest at the time of writing. Sinceapollo-client
usesfetch
, my first attempt to cancel a query was usingabortController
:interface CancellablePromise<T> extends Promise<T> { cancel: () => void } export function cancellableQuery(options: QueryOptions<any, any>): CancellablePromise<ApolloQueryResult<any>> { const abortController = new AbortController() let promise = apolloClient.query({ ...options, context: { fetchOptions: {signal: abortController.signal} } }) as CancellablePromise<ApolloQueryResult<any>> promise.cancel = () => abortController.abort() return promise }
It partially works: the request is cancelled, and the promise doesn’t complete. However there’s a big issue: subsequent calls of the same query with the same variables don’t work anymore, no attempt is being made. You can follow this pull request since it might one day be resolved: handle external fetch abort.
Not discouraged, I tried another method using
watchQuery
and theunsubscribe
method:interface CancellablePromise<T> extends Promise<T> { cancel: () => void } export function cancellableQuery(options: QueryOptions<any, any>): CancellablePromise<ApolloQueryResult<any>> { const observable = apolloClient.watchQuery(options) let subscription: ZenObservable.Subscription let promise = new Promise((resolve, reject) => { subscription = observable.subscribe( (res) => resolve(res), () => reject() ) }) as CancellablePromise<ApolloQueryResult<any>> promise.cancel = () => subscription.unsubscribe() return promise }
The logic behind it is that the call to
unsubscribe
should cancel the request when the browser supports it. However, that just doesn’t happen for me using Google Chrome (version 86.0.4240.111), the promise doesn’t complete however the request isn’t cancelled and subsequent calls of the same query with the same variables don’t work. It seems like I’m not the only one to have noticed, you can track the progress on this issue in the hope that it get fixed at some point: Unsubscribing from a query does not abort network requests.You can find a few more opened issues related to cancelling apollo-client requests:
- Unmounting Query component no longer cancels network request in v2.6.0 & v3 beta
- updateQuery merging different data when changing query while fetchMore is not yet finished
- Cancel fetchMore network requests
After searching more about it, I found out about queryDeduplication, it’s apparently the reason why subsequent calls to cancelled queries don’t work anymore: the request is still considered to be “in-flight” and thus no further attempt is being made. Thus our code can become:
interface CancellablePromise<T> extends Promise<T> { cancel: () => void } export function cancellableQuery(options: QueryOptions<any, any>): CancellablePromise<ApolloQueryResult<any>> { const abortController = new AbortController() let promise = apolloClient.query({ ...options, context: { fetchOptions: {signal: abortController.signal}, queryDeduplication: false } }) as CancellablePromise<ApolloQueryResult<any>> promise.cancel = () => abortController.abort() return promise }
This time it finally works: the request is cancelled, the promise doesn’t complete, the next call of the same query with the same variables can complete successfully and subsequent calls will be retrieved from cache.
It’s also possible to combine
watchQuery
,abortController
andqueryDeduplication
disabled:export function cancellableQuery(options: QueryOptions<any, any>): CancellablePromise<ApolloQueryResult<any>> { const abortController = new AbortController() const observable = apolloClient.watchQuery({ ...options, context: { fetchOptions: { signal: abortController.signal }, queryDeduplication: false } }) let subscription: ZenObservable.Subscription let promise = new Promise((resolve, reject) => { subscription = observable.subscribe( (res) => resolve(res), () => reject() ) }) as CancellablePromise<ApolloQueryResult<any>> promise.cancel = () => { abortController.abort() subscription.unsubscribe() } return promise }
The result is the same as the previous version, with no further benefit that I could see. Finally, I also tried to change the
fetchPolicy
tonetwork-only
but as far as I could see it only prevents the completed queries from being retrieved from cache, which isn’t something which I need. -
Mar
12Better network performance in Docker/Test Kitchen with Virtualbox on Mac
Posted in : virtualbox, docker, test-kitchen, and mac
If you’ve experienced really slow downloads from within VirtualBox on Mac, chances are you’re using the default NIC for your NAT interface.
I’ve seen docker’s pull taking ages when a layer size is more than a couple MB and chef installer taking more than 10mn to download the package…
Here’s how to fix it in docker-machine and test-kitchen.
For docker-machine
Check what’s your
docker-machine
VM’s name:docker-machine ls
it will give you something like the following (could be different depending of your config):
NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS default - virtualbox Running tcp://192.168.99.100:2376 v1.12.5
if it’s
Running
, then stop it first:docker-machine stop default
then change the NIC to use the
PCnet-FAST III (Am79C973)
instead of the defaultIntel PRO/1000 MT Desktop (82540EM)
:VBoxManage modifyvm "default" --nictype1 "Am79C973"
And finally start it, it will now use the new NIC with “hopefully” improved speed:
docker-machine start default
For test-kitchen
Update your
kitchen.yml
orkitchen.local.yml
to have your vagrant driver include thecustomize
config below:driver: name: vagrant customize: nictype1: "Am79C973"
Enjoy using all your available bandwidth!!
-
Nov
18Senlima - Knight Animation
Posted in : senlima, game, preview, unity, 3d, animation, and knight
This article has been moved over our dedicated Openhood Games blog.
-
Nov
17Senlima - Upcoming Game Preview
Posted in : senlima, game, preview, unity, and 3d
This article has been moved over our dedicated Openhood Games blog.
-
Jun
28NGinx Useful Tips
Posted in : nginx and sysadmin
During an epic debugging session with an NGinx configuration for a project, I discovered some useful, but not so common (at least to me) configuration.
Debug
NGinx do not provide so much help (by default) when it comes to debugging internal redirect, proxying and other rewrite rules. But it comes with a handy
debug
module which allows you to get a lot more info.You have to enable it at compile time:
./configure --with-debug
And then in your configuration you can set:
http { # At the http level activate debug log for eveything error_log /path/to/my/detailed_error_log debug; server { # At the server level activate debug log only for this server error_log /path/to/my/detailed_error_log debug; } server { # At the server level without the debug keywords it disable debug for this server error_log /path/to/my/error_log; } }
You can even debug only some connections:
error_log /path/to/my/detailed_error_log debug; events { debug_connection 10.0.0.1; debug_connection 10.0.1.0/24; }
Source: NGinx Debugging Log
Proxying
NGinx is well known for its proxy/reverse-proxy/caching-proxy capabilities, but you’d better know how some things works to not waste your time on some odd behaviors.
When proxying to remote host by
URL
s, be aware that NGinx use its own internal resolver for DNS name. This means in some cases it can’t resolve domains unless you specify whichDNS
to use.Let’s take an example:
server { # Let's match everything which starts with /remote_download/ location ~* ^/remote_download/(.*) { # but only when coming from internal request (proxy, rewrite, ...) internal; # Set the URI using the matched location set $remote_download_uri $1; # Set the host to use in request proxied (useful if remote is using vhost # but you're using its IP address to reach it in the proxy_pass config) set $remote_download_host download.mydomain.tld; # Set the url we want to proxy to # Using IP address of server, be sure to set the $remote_download_host set $remote_download_url https://10.0.0.1/$remote_download_uri; # Or using the full domain # set $remote_download_url https://$remote_download_host/$remote_download_uri; # Set Host header for vhost to work proxy_set_header Host $download_host; # This clears the Authorization proxy_set_header Authorization ''; # If your remote server needs some auth you can set it there # Basic auth would be something like # proxy_set_header Authorization 'Basic kjslkjsalkdjaslasdoiejldfkj='; # Disable local file caching, when serving file proxy_max_temp_file_size 0; # Finally send query to remote and response back to client proxy_pass $download_url; } try_files $uri @fallback; location @fallback { proxy_pass http://my_backend; } }
Example adapted from Nginx-Fu: X-Accel-Redirect From Remote Servers
This example is fully working because we used an
IP address
for$remote_download_url
, but if we were using the domain (eg: download.mydomain.tld), any request would fail with a502 Bad Gateway
error.This is due to the way NGinx default resolver works. It’s smart enough to resolve the domains in
proxy_pass
directives as long as they are statics (it can get them at boot time) and they are in /etc/hosts. But as we are constructing the URL here, it does not try to resolve it. Fortunately you can specify which DNS server it should use in such cases by setting:http { # Globally resolver 127.0.0.1; # Local DNS server { # By server resolver 8.8.8.8; # Google DNS location /demo { # Or even at location level resolver 208.67.222.222; # OpenDNS } } }