Комментарии 4
И всё-таки, акторы то тут зачем? Принимаем сообщения от страйпа в общую очередь, а после обработки наверняка записываем результат в общую БД..
Акторы тут в очередной раз выглядят как пятое колесо, или я что-то упускаю?
Идея в том, что с помощью Акки можно создавать другие асинхронные очереди, как в случае с чекаут сессией. По сути общая очередь (Гейтвей актор) лишь распределяет сообщения по другим очередям, где сообщения также обрабатываются асинхронно и независимо от главной очереди. Конечно, можно обойтись и без Акки, но мне в моем юзкейсе было удобно приспособить акторы. Акторы - это в первую очередь структура данных.
Вы тесно интегрировали сущность стороннего сервиса "подписки" в свое приложение. ОК
А как расширять свое приложение, делать подписки на других платежных платформах?
На самом деле никакой тесной интеграции нет. Связь разрывается как только мы кладем StripeMessage объекты в асинхронную очередь (передаем актору). StripeMessage это объект самого приложения и связан с платежным провайдером только названием. Интеграция с любым другим вендором может быть организована похожим образом или текущая имплементация - генерализирована
Асинхронная обработка Stripe событий с помощью Scala