Изготовление сайтов в Санкт-Петербурге. Как мы создали бессерверное веб-приложение для Stax Console

Создание веб-консоли для такого сложного продукта, как Stax, сопряжено с рядом проблем. Наша бессерверная платформа, ориентированная на API, предлагает широкий спектр функций для предприятий, которые хотят управлять своей экосистемой AWS и оптимизировать ее.

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

В этом посте будет рассказано о том, чего мы намеревались достичь при создании консоли Stax, о нашем опыте создания бессерверного API GraphQL для его работы, а также об уроках, которые мы извлекли на этом пути.

Бессерверный по дизайну

Мы хотели создать бессерверное решение с самого начала, чтобы оно соответствовало архитектуре, которую мы используем для остальной части продукта. Одним из самых больших преимуществ, которые мы увидели в результате использования бессерверных архитектур в Stax, является время безотказной работы и надежность. Отказ от использования сервера, который может стать единой точкой отказа, позволяет нам соблюдать наше Соглашение об уровне обслуживания и гарантировать клиентам доступ к платформе в периоды пиковой нагрузки. Использование AWS Lambda означает, что запросы от нашего внешнего интерфейса масштабируются горизонтально, и всегда имеется достаточно вычислительных ресурсов для обработки запросов.

Использование бессерверных продуктов также повышает безопасность во время разработки, поскольку такие сервисы, как AWS Lambda, обеспечивают встроенные уровни соответствия и обслуживания. Предоставление Amazon возможности выполнять обновления и исправления инфраструктуры, на которой работает наш код, позволяет нам сосредоточиться на создании программного обеспечения, а не на управлении оборудованием.

Минимальные накладные расходы на инфраструктуру при переходе на бессерверные решения позволили нашей команде полностью взять на себя развертывание и мониторинг нашего API GraphQL. Например, разработчики могут добавить новые функциональные возможности сетей, используя отдельные функции Lambda для извлечения данных учетной записи, сводя к минимуму радиус поражения от внедрения нового изменения в рабочую среду.

Первые дни

Первая итерация нашей консоли имела довольно традиционную веб-архитектуру. Одностраничное приложение React (SPA), вызываемое напрямую Stax REST API, представляет собой бессерверное решение, использующее AWS API Gateway и AWS Lambda перед реляционной базой данных. AWS Cognito обрабатывает аутентификацию и вход пользователей как для консоли, так и для REST API.

При таком подходе мы столкнулись с несколькими техническими проблемами:

Инструменты. Современные интерфейсные фреймворки развиваются быстро. Использование данных из REST API с помощью React было сложным, и им было трудно управлять состоянием.

Стабильность. Тесная связь нашего внешнего SPA с внутренним REST API была эффективной, но контракт между системами постоянно менялся по мере разработки функций, которые рисковали нарушить наш пользовательский интерфейс.

Обновления в реальном времени. Нам нужно будет создать собственную реализацию WebSocket для отправки данных в наш интерфейсный SPA для обеспечения обновлений в реальном времени. Это было бы сложно реализовать как во фронтенде, так и во бэкенде.

Также стало очевидным, что по мере роста Stax как продукта консоль нуждалась в интеграции с другими серверными службами, помимо нашего REST API, такими как данные о стоимости и соответствии для учетных записей и наша служба поддержки клиентов. Взаимодействие с несколькими API и протоколами с разными механизмами аутентификации привело нас к рассмотрению шаблона Back End for Front End с одним GraphQL API.

Наша консольная архитектура сейчас

Архитектура сосредоточена на уровне API GraphQL, который выступает в качестве прокси-сервера между нашими внешними и внутренними службами. GraphQL — это язык запросов для API; он позволяет разработчикам определять типы данных в системе (схема) и подключать функции для получения данных из разных источников (преобразователи). Отношения между данными можно раскрыть в одном запросе GraphQL. Например, один запрос может разрешить рабочую нагрузку Stax и пользователя, развернувшего ее, за один раз.

Ключевая причина, по которой GraphQL подходит для наших нужд, заключается в том, что данные могут быть получены из любого источника с помощью преобразователя и представлены во внешнем интерфейсе в виде единого интерфейса. Это означает, что по мере роста Stax мы можем реорганизовать и оптимизировать серверные службы с минимальным воздействием на наших разработчиков и клиентов. Аутентификация также значительно упрощена. Внешний интерфейс выполняет аутентификацию в нашем API GraphQL в одном месте, которое обрабатывает подключения к различным API REST и GraphQL и источникам событий за кулисами.

В Stax мы тесно сотрудничаем с AWS и стараемся использовать нативные решения AWS, где это возможно, в рамках нашей философии разработки. Мы решили использовать AWS AppSync, полностью управляемую бессерверную реализацию GraphQL в качестве ядра нашего сервиса.

AWS AppSync реализует основные директивы GraphQL, включая подписки GraphQL, которые управляют соединениями WebSocket между клиентами и вашим API GraphQL. AWS Lambda извлекает и преобразует данные в функциях преобразователя GraphQL, AWS DynamoDB используется для бессерверных хранилищ данных, а AWS EventBridge запускает функции Lambda в ответ на системные события.

Наша текущая архитектура консоли Stax использует GraphQL, AWS AppSync, AWS Dynamo и AWS EventBridge.

Создано с помощью Stax

Stax — это продукт, ориентированный на API, поэтому мы использовали общедоступный Stax REST API для создания большей части пользовательской консоли. Использование (на самом деле пробная версия) нашего собственного REST API означает, что мы можем протестировать функциональность и улучшить нашу документацию до того, как функциональность будет выпущена для клиентов, действуя в качестве нашего собственного контроля качества. Наличие GraphQL API, который проксирует нашу серверную часть, также позволяет нам внедрять новые функции в консоль до того, как они станут общедоступными для клиентов в Stax REST API. Мы можем просто подключить его к AppSync и добавить в консоль в качестве «бета-функции».

Наш API GraphQL взаимодействует с серверной частью Stax, обмениваясь данными аутентификации от AWS Cognito между сервисами. Это обеспечивает строгое разделение пользовательских данных организацией клиента на каждом этапе процесса и поддерживает контрольный журнал, привязанный к конкретному пользователю, инициировавшему действие. Наличие единого API-интерфейса GraphQL для нашего внешнего интерфейса также позволяет нам применять контроль доступа на основе ролей, что означает, что мы можем применять ограничения для действий пользователей в зависимости от их роли на уровне запроса.

AppSync API также подключается к шине событий Stax для прослушивания системных событий, генерируемых серверными службами, таких как статус завершения отдельных шагов настройки учетной записи. Мы используем подписки GraphQL для расширения функциональности, предоставляемой шиной событий Stax, и отправки обновлений на консоль без необходимости обновлять страницу.

Принимая ограничения

Аутентификация часто представляет собой проблему для бессерверных архитектур, поскольку информация об аутентификации пользователя должна передаваться каждой службе или API, участвующим в выполнении запроса. Один запрос GraphQL может привести к вызову нескольких нижестоящих служб — например, для отображения сети, учетной записи, в которой она развернута, и пользователя, создавшего ее.

AWS AppSync упрощает абстрактную аутентификацию с помощью AppSync Pipeline Resolvers, но по-прежнему важно свести к минимуму количество обращений к службам со строгими ограничениями скорости, такими как AWS Cognito. Мы подошли к этому, абстрагировав взаимодействия с Cognito в выделенный сервис, но это можно улучшить с помощью кэширования.

Будучи относительно новым продуктом, AWS AppSync имел несколько ограничений в реализации GraphQL, которые нам пришлось преодолеть. AppSync устанавливает строгий 30-секундныйтайм-аут для всех запросов, а это означает, что большие списки данных с разбивкой на страницы и вложенными связями требуют тщательной обработки. AppSync также позволяет пакетировать функции Lambda при работе с отношениями «один ко многим», но в настоящее время существует ограничение на количество пакетов, равное 5, что слишком мало для практического использования. Развертывание собственной реализации GraphQL позволило бы нам избежать этих проблем, но преимущества использования полностью управляемого бессерверного решения перевешивают болевые точки.

Следующие шаги

Будущее нашего API GraphQL будет сосредоточено на повышении производительности за счет кэширования данных и расширении обновлений в реальном времени для всех компонентов Stax. Кэширование данных позволит клиентам управлять своими средами Stax и просматривать данные, даже когда нижестоящие сервисы недоступны.

Поскольку платформа Stax продолжает развиваться, мы продолжим добавлять новые функции в нашу консоль, чтобы вашей организации было как можно проще управлять всеми аспектами своей экосистемы AWS из одного места. Но поскольку мы используем бессерверный подход, нам не нужно выделять усилия на обслуживание серверов. Вместо этого мы можем сосредоточиться на создании более удивительных возможностей для наших клиентов, в то же время оставаясь безопасными и совместимыми, даже когда платформа становится все более сложной.