Почему я создал бессерверный GraphQL API на AWS Lambda

Обо мне

Я создаю веб-приложения более 15 лет в самых разных отраслях. От стартапов в сфере финансов и лотерей до компаний из списка Fortune 500 в области машинного обучения и искусственного интеллекта. Я запустил множество компаний в качестве основателя, технического директора и соучредителя и непосредственно руководил командами из более чем 20+ инженеров. Я старший инженер-программист, технический директор и опытный предприниматель. Знаком с операционными, юридическими, бухгалтерскими и лидерскими аспектами запуска, построения и ведения успешного бизнеса.

Стабильность, безопасность и масштабируемость — сейчас.

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

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

Чтобы двигаться быстро и позволить партнерам использовать масштабируемую и стабильную платформу (в ряде стран по всему миру, где связь может быть фактором), мне нужно было просто сосредоточиться на создании API на основе GraphQL, который мог бы быть быстро обновляется и развертывается внутри глобального поставщика IaaS — AWS.

Почему Serverless и GraphQL на AWS?

Уже будучи знакомым с GraphQL и различными лидерами отрасли в этой области, я решил использовать реализацию GraphQL Yoga Lambda, чтобы иметь возможность быстро развертывать бессерверные сервисы с конечными точками GraphQL, которые можно было бы сшить вместе в одной конечной точке доступа. Кроме того, учетные данные пользователя и API, основанные на AWS API Gateway и Cognito, позволяют быстро создавать и управлять пользователями и ключами API, которые можно масштабировать по всему миру, а также быстро управлять или отключать в случае злоумышленников в партнерской экосистеме. Основание всего этого на TypeScript позволило обеспечить безопасность типов от серверной базы данных до пользовательского интерфейса.

Процесс создания Serverless GraphQL API на AWS
Первым шагом в этом процессе было создание монорепозитория, который должен был содержать различные бессерверные сервисы, а также множество других пакетов, включая приложение React Native для использования на устройствах, где мы должны были предоставить партнерам сквозную концевая оснастка.

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

Вторым шагом настройки API-интерфейсов GraphQL было определение как распознавателей для запросов и мутаций в GraphQL, так и связанных с ними пользовательских интерфейсов React. Каждый из сервисов выполнял рендеринг на стороне сервера (SSR), который также был вшит в различные внешние контексты с использованием проекта TailorJS с открытым исходным кодом Zalando. Использование этого подхода позволило каждому элементу пользовательского интерфейса и сервису содержать свою соответствующую функциональность, не создавая беспорядочного дублирования на стороне пользовательского интерфейса.

Заключительной частью процесса была настройка системы CI/CD, которая могла бы выполнять как тестирование, так и развертывание различных сервисов в нескольких дистрибутивах пользовательских доменов CloudFront в нескольких зонах доступности в AWS для глобального API с малой задержкой, предоставляемого Route53. Правила DNS на основе задержки и пользовательские домены шлюзов API.

Проблемы

Некоторые из проблем с этим подходом заключались в возможности эффективно поддерживать концепцию пользователя во всех службах. Используя токены API и токены JWT в сочетании с Cognito, мы можем разрешать разрешения API в отношении Партнера (через ключ API) и пользователя на основе токенов Cognito JWT ID.

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

Выводы

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

Кроме того, чтобы иметь отзывчивый API, вам потребуется как минимум две или более зон доступности для развертывания AWS (мы начали с US-EAST-1 и EU-CENTRAL-1), чтобы убедиться, что на задержку вашего API не влияют региональные ограничения подключения. . Использование прокси-серверов VPN может значительно повысить уверенность при тестировании глобальной доступности и производительности API. Мы обнаружили, что это очень помогло нам при попытке диагностировать конкретные проблемы реализации с партнерами.

Во время разработки мы были удивлены тем, что поняли, что Dry и Serverless не всегда хорошо сочетаются. Мы начали с намерения поделиться кодом в различных сервисах, где это необходимо, и могли бы сделать это с помощью пакетов NPM, но в конечном итоге решили использовать конвейер CI / CD для синхронизации «источника правды» между сервисами путем копирования файлов во время сборки. Наш подход сработал в нашу пользу, когда мы поняли, что у нас есть различные исключения из правил для нескольких компонентов, которые имеют «почти» общую бизнес-логику.

Некоторые советы

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

Сотрясение

В результате я считаю, что этот тип стека и развертывания может стать будущим веб-разработки. Возможность устранить барьеры как на фронтах Dev-Ops, так и на фронтах разработчиков упрощает создание и поставку с уверенностью, не теряя возможности использовать большое количество сервисов, которые вы можете найти в общедоступных облаках, которые в настоящее время существуют. Кроме того, стоимость эксплуатации этих систем при привязке к транзакциям, приносящим доход, позволяет никогда не становиться проблемой стоимости операций, пока вы не оптимизируете прибыль в отдаленном будущем.

Похожие записи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *