ivanvorobei
@ivanvorobei
iOS разработчик, канал https://t.me/sparrowcode

Нагрузка на REST API в описанной реализации?

Цель
Реализовать API с единым аккаунтом и локальными профилями. Подобие TM у Хабра.

Проблема
Не хватает опыта оценить "костыльность" решения. Нет цели провести синтетические тесты на нагрузку, хотелось бы увидеть что-то вроде "норм ахитектура, не загоняйся" или "быстро вырастет нагрузка, нужно переделать"

Описание архитектуры
А - авторизационный API. Здесь храним аккаунты, связанные соц сети, email ну и все что положено.
Для конкретики расположим его в
api.company.com/

P - проект. Он связан с Account API. Регистрироваться в проекте не нужно, аккаунт уже заведен на api.company.com. Расположим проект тут:
api.project.com/

C - клиент. Любой сайт, мобильное приложение (и т.д.), работающее с API Project.

b18dd7a5e18141438ac98e53d3a75288.jpgВзаимодействие
Реализовано в лучших традициях: JWT, http статусы (200, 201 и т.д.), канал https, get/post/delete.. и прочее, за что любители православного REST-а не закидают тухлыми камнями :)

цифры на картинке совпадают с нумерацией ниже

- Авторизация:
1 - Пользователю отображается форма входа. Логин-пароль отправляются в заголовке запроса, запрос направляется к API Project. Что-то вроде:
api.project.com/login... c Authorization заголовком.
2 - API Project не хранит данные аккаунта, и делает запрос к API Account, передавая тот же заголовок. Ждет ответ.
3 - API Account проверяет логин-пароль, и если все в порядке, генерирует JWT. Возвращает его API Project.
4 - API Project возвращает токен клиенту. Так как запрос удался (токен был возвращен, хотя и не может быть расшифрован) - создается в проекте локальный профиль. Он связан с аккаунтом.

- Обычный запрос:
Так как токен получен (описал выше), то можно отправлять запросы. Картинка подойдет та же.
1 - Клиент отправляет на API Project запрос, прикрепляя в заголовке токен.
2 - API Project не знает как расшифровать токен. Отправляет запрос с токеном на API Account. В свою очередь API Account может расшифровать JWT, и проверяет его.
3 - Токен проверен, API Account возвращает ID пользователя, которому принадлежит токен. API Project теперь понимает для какого пользователя выполнить запрос. Выполняет и..
4 - Отправляет ответ клиенту.

Для дочитавших до конца, дублирую вопросы:
Критично ли вырастет задержка?
Если да, как лучше организовать систему с один аккаунтом?

P.S. Речь не SSO, вопрос конкретно о взаимодействии по API.

Спасибо со слезами на глазах!
  • Вопрос задан
  • 734 просмотра
Решения вопроса 1
Defman21
@Defman21
Выглядит вполне нормально. Можно, конечно, обращаться к АПИ аккаунтов напрямую, передавая уникальный ID проекта, а уже само АПИ аккаунтов будет генерировать уникальный токен, который будет понятен только проекту, который запрашивает конечный пользователь, но как по мне - это делает всю систему немного запутаннее.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы