R
Там потом из параметров вытаскивается кому этот ответ предназначен
Size: a a a
2020 March 06
A
Ну на хуку делаете отдельного актора, и общаетесь с этим актором))
R
То есть запрос слать самому а ответ с хука получать от актора?
R
Leaky abstraction
R
А так я и запрос посылаю через актора, и ответ с хука получаю как
let response = service_addr.send(Request).awaitR
Хотя
response может вернуться и через несколько минутA
То есть запрос слать самому а ответ с хука получать от актора?
Скорее я имел ввиду, что вы при старте актикса создаете одного актора, который отвечает за общение хуки, и вся логика касатлеьно хука находится в нем. Вам нужно дернуть хук - запросили у актора результат хуки, а уже сам этот актор разрулит когда и кому что ответить
R
Ну у меня почти так же и есть. Только этот актор и запрос по HTTP на внешку шлет, и он же ответ с хука сует куда надо
R
Так его и мокнуть проще.
A
Ну да, но тогда не понимаю зачем фасад?)
R
Это он и есть
A
Ааа... просто в вашем описании помимо хука вы что-то еще делаете
R
Так и есть. Шлю запрос и жду ответа на хук (колбэк)
R
А в акторе с бизнес-логикой остается просто
let resp = service.send(req).await где service это актор-фасад который я описываюA
А, я понял, вы вместо того, чтобы при реквесте сделать последовательность футур, например одна делает http запрос на внешнее апи, вторая футура ждет ответ от актора отправляющего хуки, а после резолва всех футур отдавать response, сделали это все в одном акторе
R
Именно, что б абстрагировать логику работы с внешним сервисом
R
Ну внутри того актора все футурами обмазано, конечно
A
Ну тогда не понимаю, чем вас смущает send?)))
R
Ну вроде номр. Но вдруг так не идеоматично и есть подводные камни такого подхода
R
Просто семантически получается, что
addr.send(request) и addr.do_send((request, ctx.address()) изоморфны