Comments 7
Познавательно, только считаю что тема вложений не раскрыта. Зачастую из БД требуется отправлять как раз вложения.
На самом деле, вложения тоже сделал (для отправки счетов), в репозитории есть код для них. Даже больше, есть ещё плагины шаблонизатор mustach и преобразование из HTML и URL в PDF и PS.
Скажу только одно: не делайте так. Не ходите из базы ни в какие внешние сервисы. Вы же внутри транзакции, и растягиваете её время весьма существенно. А транзакция тормозит всё самим фактом своего существования.
Чем это лучше посылки письма чем-нибудь внешним? Да ни чем. Зачем-то расширение ставится - а это лишний код, в котором могут быть баги. Зачем-то растягиваем время транзакции на неопределённое время. Зачем-то трогается не контролируемая среда (другой сервис), по ответам от которого могут возникать ошибки у нас.
И ведь если вдруг письмо ушло, а транзакция потом откатилась, то ведь письмо уже не вернёшь. Это не двух-фазная транзакция. Так что, ни какого выигрыша нет в сравнении с внешним скриптом на питоне.
Блин, это ведь уже даже не "бизнес-логика в базе данных", а уже "инфраструктура в базе данных".
Так а зачем тогда себя ограничивать? Зачем нам нужен внешний почтовый сервер? Давайте запихнём почтовик внутрь сервера.
Вон, supabase же идёт почему-то в этом направлении...
К тому же, в принципе, можно сделать, чтобы работало вне транзации, но при этом в базе %), только для этого надо сначала придумать какое-то удобное API. Сейчас ограничение работы только внутри транзакции - всего лишь из-за удобного API плагинов.
Делали аналогичную задачу в другой СУБД для отправки писем и СМС. В транзакции письмо укладывалось в очередь сообщений и всё. Далее по расписанию процедура занималась отправкой. Преимущества:
Так еще можно проверять доп.условия, например, всё, что сгенерировалось ночью - отлежится до утра, чтобы не будить клиентов. А сотрудникам сообщения могут сразу отправляться.
Письмо клиенту может отлежаться, например, 5 минут. В этот период исходные данные могут измениться (например, визит отменится или перенесется на другое время) и можно успеть удалить или изменить сообщения
И еще...
В Oracle, например, есть пакеты, которые позволяют упорядочить код, плюс много готовых пакетов для работы с tcp, почтой и т.п. Таким образом, значительную часть логики можно держать в базе без головной боли. А в Postgres "из коробки" такой возможности нет (если вы, опять же, не подключите pl/sql), поэтому, держать много кода в pg/sql лично мне неудобно. И есть смысл унести код в backend, вместе с процедурой отправки сообщений
Для отправки писем мы используем Apache Artemis. Вся информация, включая вложения вытаскивается из базы в одной, очень быстрой транзакции и отправляется в очередь на Артемисе. В хедере сообщения прописывается время отправки. И сервис, который слушает эту очередь получает сообщение тогда, когда нужно отправить письмо. Можно настроить и двухфазный коммит если есть необходимость.
Рецепты PostgreSQL: отправка писем с отчётом о доставке