Вот у меня сущность приложения (indigo.App) довольно тупая, и принимает роутер только когда жмакают app.Serve(). Поэтому, на сколько портов индигу не вешай, роутер будет один и тот же использоваться. Из-за этого и появился virtual.Router, который берёт запрос, и перенаправляет его в соответствующий роутер. Но мне вот какая мысль пришла: это ведь можно и более элегантно реализовать!

Вот я навешиваю аппу на разные порты через App.Bind(addr). Я могу сюда же роутер и прокидывать! Всё равно на каждом порту свой листенер (каждый в своей горутине), тогда ещё и косты на виртуальный роутинг сводятся к нулю (сейчас там перебор массива на каждый запрос, в надежде, что доменов будет немного - если меньше 7, тогда норм). Но и прокидывать в прям каждый App.Bind() роутер отдельно не хочется (например, аргумент пришлось бы дублировать в ситуациях, когда я хочу навесить аппу на хттп и хттпс). Есть вариант - если в бинде не указан роутер, будет использован роутер, указанный в предыдущем бинде. Либо дефолтный (который будет передаваться так, как передается и сейчас - через App.Serve(r)). Сохраняется обратная совместимость, но общий Developer Experience ухудшается - какая-то магия, везде вариадики.

Но, сука, фича-то сладкая, так и манит гадина. Я сейчас и так тот единственный переданный роутер в аппу передаю каждому листенеру по отдельности, а листенер у меня - замыкание, поэтому, возможно, можно будет добавить какую-нибудь заглушку а-ля App.Bind(":8081", Virtual(TCP, r2)), где r2 - это роутер для какого-нибудь другого домена от переданного в последующий App.Serve(r). Не без дизайнерских проблем, но и с TLS тоже зафурыкает.

Но меня всё равно не покидает чувство, словно это можно разрешить более элегантным способом.