своего кода другой микросервис?
Нет. Но как в хранимке делать и мокать потом в тесте обращение к другим сервисам - возникает
А дай пример того как хранимка обращается к внешнему сервису. Конкретно у тебя.
А у тебя ещё и хранимка в другой сервис ходит, а не только в базу?
Вот хранимка, ходящая в другой сервис - это криминал уже...
У меня вообще хранимок нет. Но если бизнес-логику делать на хранимках, то это вполне себе реальный кейс
Ну тогда функция подключения к внешнему сервису в отдельный пакет и махинации с search_path. Чем тебе не мок?
В хранимках надо делать ту бизнес-логику, которая, максимум, касается только данных в базе. Все остальное - это уже однозначно работа для бэкенда на нормальном языке
Тогда какой смысл бизнес-логику так размазывать? Часть будет в коде, часть в базе...
Геморрой же полный
Потому что в некоторых случаях имеет смысл представить БД другим микросервисам не кишками наружу, а в виде микросервиса-хранилища. Например, когда тебе надо, чтобы доступ к данным получали несколько сервисов. Можно оформить интерфейс к данным в виде сервиса-обертки на полноценном языке, а можно в виде хранимок, и пустить другие сервисы прям базе (разрешив работать только через интерфейс хранимок, разумеется).
Если так, то да. Но, опять-таки, если учитывать, что в хранимке нельзя делать обращение к внешним сервисам, то это всё годится лишь для совсем каких-то простейших случаев, где запросы строго в одну БД и больше ничего нет.
Ясное дело, что это не универсальный рецепт, и он применим только при определенной архитектуре, спроектированной под определенные требования. Но бывают такие ситуации, когда тебе нужно сделать микросервис-хранилище, чтобы в нем держать весь стейт, не размазывая его по куче микросервисов, у каждого из которых по своей базе, имея при этом головняк с консистентностью данных и связей между ними.
Обсуждают сегодня