Как спроектировать веб приложение с API и админкой?
Добрый день!
Подскажите как лучше спроектировать проект с админкой, веб-приложением и API для мобильного приложения.
Хотелось бы разделить проект на 3 части, подпроекта.
1) API имеет публичный интерфейс и только часть с API имеет прямой доступ к базе.
2) Админка управляет БД через АПИ, есть ручки для запуска скриптов, отдельная авторизация для админов.
3) Клиент (web & mobile) общается через АПИ, своя классическая авторизация, с этим вопросов нет.
Основной вопрос у меня с тем как разделить админку и АПИ. Намного удобнее будет сделать админке прямой доступ к БД, но тогда где держать модели, чтоб они не дублировались. Есть ли лучшие практики?
Отказ от ORM - отличная практика, если умеете SQL.
Упс ... тэг же mongo ) ну её тоже есть смысл знать - вряд ли какие ORM дают адекватный доступ к aggregation framework.
Админка это просто интерфейс для работы с api ( которое реализует crud операции над моделями ). Поэтому не совсем ясно что значит разделить админку от api. По сути есть только апи и фронты работающие с разными частями ( необходимыми ) апи. Модели в любом случае на стороне бэка. Или я не совсем понял вопрос?
Вы все правильно поняли. но в таком случае будет сложно управлять доступами к разным операциям. Второй сложный момент для меня - это реализация двух авторизаций для админов и обычных пользователей (ходят в разные таблицы и на разных url). Третий момент запуск скриптов, связанных с БД (но это уже мелочи)
Если есть задача разграничивать доступ разных пользователей системе к разным эндпойнтам то в любом случае придется делать механизм авторизации. Если будут только два вида пользователей ( пользователи и админы ) и внутри двух этих групп не будет разграничения прав то задачу можно решить разными стратегиями аунтификации. Скажем на админские эндпойнты повесить стратегию аунтификации админов ( по токену из заголовка ищется пользователь в таблице админов ), на пользовательские эндпойнты повесить стратегию аунтификации пользователя ( по токену из заголовка ищется пользователь в таблице пользователей ). И в таком варианте после аунтификации функционал авторизации не делать вовсе.
Средний
