Не читал оригинальный issue, но если это предполагается только для интерфейсов, то там (если не брать default implementation) только сигнатуры и есть. То есть нужно было разрешить в интерфейсах писать static методы и, вроде бы, этого хватило
Т.е. пришёл юзер на урл X, аппхост отправил этот запрос в сервис А, сделал какую-то часть логики, затем ему потребовалось, допустим, получить информацию о пользователе, которая хранится в сервисе Б. А сервису Б ещё нужно подгрузить ещё какую-то информацию из сервиса В.
В статье есть пример графа взаимодействий, на котором особо ничего не видно. + есть схематичный пример (в разделе с узкими местами), но там вложенности нет. Поэтому неясность остаётся :)
клиент пришел по урлу Х
Ещё я тут понял, что это и есть маршрутизация на основе урла (скорее всего префикса или шаблона), о которой я выше писал. Будет прям то, что я имел ввиду, если при вложенности идёт обращение обратно к аппхосту.
Расскажите на примере, как выглядит взаимодействие со стороны рядового сервиса А, который хочет отправить запрос в сервис Б, а затем в В.
Условно, сервис посылает запрос на http://apphost (допустим, набор реплик получен через service discovery или любым другим способом), где apphost — какая-то реплика AppHost. Каким образом сервис А скажет, что он отправляет запрос в сервис Б/В? Заголовок? Префикс пути? Что-то ещё?
Не читал оригинальный issue, но если это предполагается только для интерфейсов, то там (если не брать default implementation) только сигнатуры и есть. То есть нужно было разрешить в интерфейсах писать static методы и, вроде бы, этого хватило
По сути получается некий аналог ФП в мире микросервисов, понял, спасибо :)
Как тогда обстоит дело с вложенностью?
Т.е. пришёл юзер на урл X, аппхост отправил этот запрос в сервис А, сделал какую-то часть логики, затем ему потребовалось, допустим, получить информацию о пользователе, которая хранится в сервисе Б. А сервису Б ещё нужно подгрузить ещё какую-то информацию из сервиса В.
В статье есть пример графа взаимодействий, на котором особо ничего не видно. + есть схематичный пример (в разделе с узкими местами), но там вложенности нет. Поэтому неясность остаётся :)
Ещё я тут понял, что это и есть маршрутизация на основе урла (скорее всего префикса или шаблона), о которой я выше писал. Будет прям то, что я имел ввиду, если при вложенности идёт обращение обратно к аппхосту.
Расскажите на примере, как выглядит взаимодействие со стороны рядового сервиса А, который хочет отправить запрос в сервис Б, а затем в В.
Условно, сервис посылает запрос на
http://apphost(допустим, набор реплик получен через service discovery или любым другим способом), гдеapphost— какая-то реплика AppHost. Каким образом сервис А скажет, что он отправляет запрос в сервис Б/В? Заголовок? Префикс пути? Что-то ещё?То есть бот сам ничего и не покупает.
И скорее всего есть возможность отмены заявки / её редактирования каким-либо путём (допустим, фразой «Ой, там должно быть...»).
А насчёт Лондона в Канаде — так и нужно писать «Еду в командировку в канадский Лондон», ибо без уточнения и обычный человек скорее всего не поймёт =)