Как ответить
Выбор между прямыми запросами к БД и API — это вопрос архитектурной границы. В большинстве продакшен-систем лучше использовать API: он даёт абстракцию, контроль доступа, версионирование и возможность менять реализацию без ломки клиентов. Прямой доступ к БД оправдан только в очень простых монолитах или временных скриптах, но при росте системы он превращается в耦合 (сцепление) и угрозу безопасности.
Вот основные аргументы:
- Безопасность и изоляция. Через API ты можешь проверять права, валидировать входные данные, логировать. Прямой SQL-доступ — это дыра: клиент может выполнить любой запрос, включая DROP TABLE, если нет тонкой настройки прав.
- Версионирование и эволюция. API позволяет менять схему БД, не ломая старых клиентов (через версии эндпоинтов). При прямом доступе любое изменение таблицы — breaking change.
- Тестируемость. API можно замокать, написать интеграционные тесты на уровне HTTP. С прямым доступом тесты жёстко привязаны к схеме БД.
- Производительность. Кажется, что прямой запрос быстрее, но на практике API может агрегировать данные, кешировать, пагинировать, избегая проблем N+1. Например, GraphQL позволяет клиенту запросить ровно то, что нужно, за один запрос.
Когда же прямой доступ допустим? Внутри одного сервиса (монолит) — через слой репозитория или ORM, но не открывая БД наружу. Для миграций данных, ETL-задач, аналитики — да, но там обычно нет внешних клиентов. В микросервисах прямой доступ к чужой БД — антипаттерн: нарушается граница контекста, теряется независимость.
Пример: если у нас сервис заказов и сервис пользователей, то сервис заказов не должен лезть в таблицу users. Вместо этого он вызывает API сервиса пользователей (или использует событийную шину).
Итог: для внешних интеграций — только API. Внутри границы одного модуля — репозиторий/DAO, но не прямой SQL-доступ. Для middle-разработчика важно уметь аргументировать этот выбор и приводить конкретные кейсы.