Have you ever experienced this? You are developing a Shopware 6 project and need to rapidly iterate some JavaScript. So you're using bin/watch-administration.sh and you're seeing all API requests slowing to a crawl - from a couple of milliseconds to multiple seconds. And you're probably wondering why that happens.
Well, so did I! I took some time today to analyse (and hopefully fix) this phenomenon. And the results might surprise you. It's DNS (or rather name resolution). Because of course it is.
Background
Shopware 6 uses a NodeJS-based proxy system for their administration watcher. This takes any non-asset requests and passes them through to the configured APP_URL. So in theory, it should be about the same speed as a "native" request to Shopware.
So how could it be so slow, then? I've been using using custom .local domains on macOS (via /etc/hosts) for my development environments.
Björn nudged me in the right direction by first asking why I was still using .local, and indeed, using another domain (e.g. something.test) or 127.0.0.1 directly solved the issue!
But wait, it does not stop there. macOS does not like multiple 127.0.0.1 entries in /etc/hosts, so someone on Stack Overflow back in 2012 proposed just adding everything in one line:
127.0.0.1 localhost my.shop.test other.shop.test third.shop.testAnd this also works.
The fun does not stop here: This only seems to affect entries with the same TLD. If you add just one other entry (like something.test) as a separate line with all other lines being .local, that one will be fast again. There are multiple levels of weird behaviour here.
Please note, that this may not be a problem for non-macOS systems, so your mileage may vary.
tl;dr: Solution
Put all your entries for 127.0.0.1 in /etc/hosts on one line. Or skip that part of DNS resolution in macOS completely, with plain IPs or something like DNSmasq.
And... that's it. Proxied requests are now as quick as native requests in my local environments.