то ли доступ закрыт то ли что

спасибо

Всем салют, господа, нужна помощь гуру) Никогда до этого не строил архитектуру api. Подскажите пожалуйста советы и рекомендации, может ссылки на книги, доки, видео. Или просто истории из личного опыта при построении архитектуры. Из книг прочитал только Арно Лоре «проектирование веб api» но она разумеется не дала полного понимания как построить архитектуру целого сервиса.


Вообщем стоит цель поднять отдельный сервис авторизации, но в виду экономии средств на галере решили что на том же сервере должен располагаться и API по взаимодействию клиента с БД. (Запись на услуги, получение данных по услугам, и все в таком духе). И все это желательно должно быть горизонтально масштабируемо и обязательно закрыто чтоб стучаться могли только наши сервера.

Для быстрого написания и распределения нагрузки планирую использовать - nodeJS. (В дальнейшем перепишут на более низкий уровень.)
Для балансировки и в качестве прокси - NGINX, базу для безболезненного переезда и дальнейшей простоты поддержки -  SQL.

Основной вопрос в том как организовать построение бэк части на ноде. Обязательно ли использовать docker в таком случае разделив api авторизации от api взаимодействия? Есть ли смысл поднимать 2 отдельные БД ?
И как в таком случае построить саму архитектуру api? (Достаточно ли будет разделить на api по путям
api/auth
api/client
api/reception ?)

много деталей хочешь сразу прояснить - ищи их отдельно, по каждому вопросу, что касается
самого api (вообще любого) это набор функций, разделенных по доменам неймспейсами в удобном для использования виде.
бд, можно и одно (но не нужно), это заставит проектировать api интерфейсов внутри сервиса для того чтобы домен авторизации не лез в бд куда ему не положено, а домен услуг в авторизацию на уровне бд. это и даст возможность скейлить. лучше сразу 2 сервиса и сразу 2 бд (ну пусть в одном инстансе, но с разными подключениями - тогда наверняка не полезут в чужую бд, но только через апи:))

Спасибо

Может взять готовое решение в виде hasura  той же или аналогов и не писать велосипед? И для авторизации тоже любое готовое решение.
Прикрутить это вместе за пару недель и все будут счастливы.

Увы, но как бы это странно не звучало : задача именно написать велосипед

Потому и задал вопрос.

1. Обязательно ли использовать docker в таком случае разделив api авторизации от api взаимодействия? - Docker же не для “разделения api”. Использовать его нужно, но это скорее что бы решить пункт касаемо масштабирования
2. Есть ли смысл поднимать 2 отдельные БД? - Как по мне, сейчас нет смысла
3. И как в таком случае построить саму архитектуру api? - Отдельные роуты на авторизацию в зависимости от её типа и отдельные роуты на клиентское взаимодействие

а есть такое же но на гуглдрайве?

Такое же, это short-url или file sharing?

типа клон папки на гуглодрайве, яндекс заблоче, не качает оттуда, а сношать себе мозг проксями и впн-ками не сильно хочется, поэтому спросил

А, понял уже что это за линка 🙃 Тогда присоединйюсь к вопросу, тоже интересно посмотреть что там, но из-за Яндекса сложно(

спасибо)

Да немного не корректно на счёт докера вопрос задал.

На какой более низкий уровень вы хотите перенести, если большая часть нагрузки все равно ляжет на БД?

с помощью каких инструментов проектировать БД, желательно чтобы была версию под линукс + возможность хранить данные в git?

erwin

MySQL Workbench

ES теперь уже не модно ? (не смотрел видео)