Когда (не) стоит использовать shared database и обойтись без API Gateway?
Заказчик предлагает использовать расшаренную БД под предлогом того, что на разработку с API Gateway мы потратим больше времени и возможны ошибки/проблемы с безопасностью.
За все данные отвечает главное приложение, но со стороны юзера может изменять *не все данные. И только вспомогательное (допустим, оно для админов) может изменять те самые *данные.
Предлагается делать изменение напрямую в базе, в чем я не вижу ни одного преимущества. Синхронизация моделей (в sequelize.js), администрирование БД с целью создания нужных юзеров и предоставления им прав - это не весь список, но достаточно для усложнения разработки.
Какие аргументы предоставить против такого решения? Сталкивались ли вы с таким на практике, и какие преимущества/недостатки в этом проявились?
Очень много боли от того что хочет от вас заказчик. Сочувствую. Хочется сразу узнать - про какой вы API Gateway говорите ибо есть несколько решений на рынке (надеюсь вы не все с нуля там делаете)
Вообще shared database это плохой дизайн. Да, он работает поначалу, а потом боль. Пользователи вообще должны быть в отдельной системе (Identity Server и все дела).
Раз вы делаете API Gateway то надо понимать что клиентскую часть очень хорошо сделать именно в рамках взаимодействия с API. Когда у вас несколько точек обращения к одним и тем же данным напрямую из базы это увеличивает сложность поддержки и ни разу не линейно. Особенно если и документации не будет.
Деплоить решение станет со временем невозможно - вы сделали небольшое изменение в одной системе, а оно потянуло его везде. Куда лучше сделать различные кэши со стороны всех приложений, использовать пресловутый GraphQL для агрегации и все в таком духе.
Виталий Столяров, тогда вы на правильном пути. Про безопасность, думаю вам тоже объяснять 2 раза не надо: ssl, jwt, openid/oauth/saml в зависимости от задачи.
могу разве что порекомендовать почитать вот этот труд
Если будут какие-то действительно сложные проблемы с организацией скорости доставки фич или архитектуры - могу подсказать (если вы захотите) и направить.
Заказчику не нравится скорость работ и он хочет чтобы все двигалось быстрее. Он сделал ужасное предложение, но почти всегда что-то можно оптимизировать
Средний
Простой
Простой
