Как стать автором
Обновить

Комментарии 7

Познавательно, только считаю что тема вложений не раскрыта. Зачастую из БД требуется отправлять как раз вложения.

На самом деле, вложения тоже сделал (для отправки счетов), в репозитории есть код для них. Даже больше, есть ещё плагины шаблонизатор mustach и преобразование из HTML и URL в PDF и PS.

Скажу только одно: не делайте так. Не ходите из базы ни в какие внешние сервисы. Вы же внутри транзакции, и растягиваете её время весьма существенно. А транзакция тормозит всё самим фактом своего существования.

Чем это лучше посылки письма чем-нибудь внешним? Да ни чем. Зачем-то расширение ставится - а это лишний код, в котором могут быть баги. Зачем-то растягиваем время транзакции на неопределённое время. Зачем-то трогается не контролируемая среда (другой сервис), по ответам от которого могут возникать ошибки у нас.

И ведь если вдруг письмо ушло, а транзакция потом откатилась, то ведь письмо уже не вернёшь. Это не двух-фазная транзакция. Так что, ни какого выигрыша нет в сравнении с внешним скриптом на питоне.

Блин, это ведь уже даже не "бизнес-логика в базе данных", а уже "инфраструктура в базе данных".

Так а зачем тогда себя ограничивать? Зачем нам нужен внешний почтовый сервер? Давайте запихнём почтовик внутрь сервера.

Вон, supabase же идёт почему-то в этом направлении...

К тому же, в принципе, можно сделать, чтобы работало вне транзации, но при этом в базе %), только для этого надо сначала придумать какое-то удобное API. Сейчас ограничение работы только внутри транзакции - всего лишь из-за удобного API плагинов.

Делали аналогичную задачу в другой СУБД для отправки писем и СМС. В транзакции письмо укладывалось в очередь сообщений и всё. Далее по расписанию процедура занималась отправкой. Преимущества:

  • Так еще можно проверять доп.условия, например, всё, что сгенерировалось ночью - отлежится до утра, чтобы не будить клиентов. А сотрудникам сообщения могут сразу отправляться.

  • Письмо клиенту может отлежаться, например, 5 минут. В этот период исходные данные могут измениться (например, визит отменится или перенесется на другое время) и можно успеть удалить или изменить сообщения

И еще...

В Oracle, например, есть пакеты, которые позволяют упорядочить код, плюс много готовых пакетов для работы с tcp, почтой и т.п. Таким образом, значительную часть логики можно держать в базе без головной боли. А в Postgres "из коробки" такой возможности нет (если вы, опять же, не подключите pl/sql), поэтому, держать много кода в pg/sql лично мне неудобно. И есть смысл унести код в backend, вместе с процедурой отправки сообщений

Для отправки писем мы используем Apache Artemis. Вся информация, включая вложения вытаскивается из базы в одной, очень быстрой транзакции и отправляется в очередь на Артемисе. В хедере сообщения прописывается время отправки. И сервис, который слушает эту очередь получает сообщение тогда, когда нужно отправить письмо. Можно настроить и двухфазный коммит если есть необходимость.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории