Пару недель назад я начал создавать PoC для облачной службы нагрузочного тестирования. Общая архитектура была довольно стандартной:

  • Простой «маркетинговый» сайт, т.е. простой контент на основе шаблонов.
  • API на основе Express, который предоставляет некоторые защищенные конечные точки, что позволяет пользователям настраивать и запускать тесты, а также получать информацию о текущих и прошлых тестах.
  • Веб-приложение на основе React, для просмотра которого требуется проверка подлинности, которое, по сути, действует как «красивый» пользовательский интерфейс для API.

Обычно пользователь узнает о продукте на сайте www.myservice.com, тогда основное приложение, предоставляющее данную услугу, размещается на субдомене, таком как app.myservice.com, а доступ к API осуществляется по адресу api.myservice. .com. Конечно, не обязательно использовать поддомены, но это немного проясняет ситуацию, когда дело доходит до развертывания.

Проблема аутентификации

Когда я начинаю разрабатывать приложения, аутентификация обычно является одной из первых проблем, с которыми я сталкиваюсь, поскольку это фундаментальная часть многих приложений, и получение ваших пользователей, ролей и разрешений на раннем этапе имеет решающее значение. Мне очень нравится идея create-react-app и тот факт, что процесс обновления чрезвычайно прост, пока вы не извлекаете. Однако проблема заключается в том, что вы не можете получить доступ к серверу Express, который находится за вашим приложением create-response-app, и поэтому вам нужно полагаться на код на стороне клиента для обработки аутентификации, что для меня немного нет-нет, поэтому я установил о поиске альтернативного ответа.

Создан шлюз приложений

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

Примечание. Важно, чтобы токены доступа , выдаваемые шлюзом, распознавались вашим API. Например, вы можете использовать общие секреты между шлюзом и API, или, если вы используете API-шлюз, такой как AWS API Gateway, для управления доступом к API, вы можете написать собственный авторизатор, который может делать запросы к шлюзу для проверки токена. .

Мне понравилась эта концепция, и я быстро создал прототип шлюза, о котором я расскажу в следующей статье. Однако это заставило меня задуматься о других способах, которыми сервер шлюза может добавить дополнительную ценность, и, учитывая, что сейчас неделя Черной пятницы, когда я пишу это, первое, что пришло в голову, - это ограничение скорости доступа к приложению. В периоды пикового трафика многие крупномасштабные сайты (например, магазины розничной торговли и сайты продажи билетов) будут ограничивать количество посетителей, разрешенных на сайте одновременно, и эффективно управлять очередью. Фактически, эта функциональность настолько распространена на сайтах с высокой посещаемостью, что это уже готовая функциональность, предоставляемая Akamai. К сожалению, услуги Akamai - довольно дорогая роскошь, которую может себе позволить не каждый бизнес!

Точно так же вы также можете добавить мониторинг приложений и предупреждения в шлюз и запускать предупреждения, если серверное веб-приложение начинает замедляться или перестает отвечать. Думайте о шлюзе как о вышибале для вашего веб-приложения - если там слишком много людей или у вас нет идентификатора, вы не попадете.

С архитектурной точки зрения, этот шлюз похож на шлюз API, за исключением того, что он предназначен для приложений пользовательского интерфейса, поэтому я решил назвать его (подождите…) шлюзом приложений. Его единственная задача - выступать в качестве барьера для доступа к приложению, обеспечивая при этом обычно необходимые функции, такие как обеспечение доступа к приложению только авторизованным пользователям, или создание очереди пользователей в периоды пиковой нагрузки, когда приложение перегружено. При создании клиентских приложений с такими фреймворками, как React, этот шаблон в реальном времени экономит время, поскольку теперь вы можете предположить, что все пользователи аутентифицированы, вместо того, чтобы пытаться определить статус аутентификации из данных сеанса, хранящихся в локальном хранилище, управлять токенами истечения срока действия API и т. Д. Все, что вам нужно сделать, это получить токен, который был установлен в браузере пользователя шлюзом приложений, и отправить запрос в свой серверный API для получения информации о пользователе.

Соображения по развертыванию

Шлюз приложений - это точка входа для вашего веб-приложения, и поэтому оно должно быть общедоступным. Конечно, вы должны убедиться, что вышестоящий сервер, например сервер, на котором развернуто ваше приложение create-response-app, не является общедоступным. Кроме того, шлюз должен быть соответствующим образом масштабирован, и может потребоваться прокси для дополнительных протоколов, таких как WebSockets.

Заключительные мысли

Я буду следить за этой публикацией с примером реализации шлюза приложений на NodeJS, но если вы просто не можете дождаться, вот код: https://github.com/nicklee1990/auth-gateway-example

Шлюз приложений, по сути, является родственной концепцией API-шлюзу, то есть барьером, который обеспечивает стандартные функции перед входом в приложение, например аутентификацию. Сейчас мы находимся в мире, где клиентские приложения есть повсюду, облачная инфраструктура настолько дешева, а накладные расходы на производительность 1 дополнительного HTTP-перехода настолько незначительны (если все развернуто правильно), что отдельные развертываемые единицы, такие как шлюз приложений, которые абстрагируются общие и часто сложные задачи, такие как аутентификация, имеют гораздо больший смысл, чем раньше в мире монолитных приложений. А еще я очень не хотел отказываться от своего приложения create-react-app :)