Почему бы значение 'href' не указывать абсолютной ссылкой? Таким образом можно абстрагироваться от синглтон-домена и мы легко можем заменить домен в случае разнесения функциональности по разным доменам-субдоменам.
А можем и не заменить.
Количество вопросов, поднятых в книге, обычно хватает на двенадцать-пятнадцать произведений желтого чтива. Если вы заметили в книге только вампиров в космосе, то понятно почему она вам не понравилась.
Для того, чтобы те службы, которые запущены хрен знает где, были доступны на локалхосте. Другими словами описанным механизмом можно запустить приложение в докере даже если оно и не думало запускаться в докере и не читает настройки подключения к различным сервисам из переменных окружения, а тупо пытается подключиться к локахосту. Хотя, быть может, я не настолько знаком с технологией NAT, чтобы понять ваш вопрос до конца :)
Дела с несколькими серверами обстоят точно так же как с докером, так и без докера. Вы же не жалуетесь на мультисерверность архитектуры в обычном случае? У вас всегда есть возможность запустить контейнер с выставленным портом в наружу и задача станет похожей на задачу управления несколькими серверами.
Другое дело, что есть инструменты, которые позволяют создавать свою абстракцию в виде облака серверов, но это уже совсем другая история, которая выходит за рамки этой статьи.
Не понимаю сути вашего комментария. Вы хотите сказать, что все, что не управляется шефом-ансиблем-паппетом, то не стоит внимания? Или у вас есть какое-нибудь конструктивное замечание?
С таким конфигурационным файлом вы знаете все конфигурационные переменные, и все еще в состоянии настраивать приложение не вмешиваясь в исходный код оного. Так сказать, и волки и овцы.
Три вопроса:
Клиенту все еще нужно догадываться, что запрос на
add-recipeнужно делать постом а не путом или патчем? Почему бы не указывать метод явно? Например:Почему бы значение 'href' не указывать абсолютной ссылкой? Таким образом можно абстрагироваться от синглтон-домена и мы легко можем заменить домен в случае разнесения функциональности по разным доменам-субдоменам.
А можем и не заменить.
Спасибо.
Другое дело, что есть инструменты, которые позволяют создавать свою абстракцию в виде облака серверов, но это уже совсем другая история, которая выходит за рамки этой статьи.
Создайте конфигурационный файл, который будет читать переменные окружения и создавать «более-менее самодокументированый» файл. С блекджеком.
Вот вам достаточно говорящий пример `settings.yml` с erb-шаблонизатором:
С таким конфигурационным файлом вы знаете все конфигурационные переменные, и все еще в состоянии настраивать приложение не вмешиваясь в исходный код оного. Так сказать, и волки и овцы.