aws-blocks

AWS Blocks — скилл для создания full-stack приложений с Infrastructure-from-Code подходом. В исходном описании Building Blocks объединяют CDK, SDK и локальные mock-реализации в единый API. Каталог блоков включает хранилища, аутентификацию, realtime, фоновые задачи, файлы, AI и поиск, email и наблюдаемость; среди названных вариантов есть KVStore, DistributedTable, Database, AuthBasic, AuthCognito, Realtime, AsyncJob и FileBucket. Основная идея — один каталог aws-blocks описывает backend, а frontend получает типизированные импорты без отдельной генерации клиента. Новый проект можно создать через npx @aws-blocks/create-blocks-app my-app, после чего перейти в каталог. Та же команда с точкой добавляет AWS Blocks в существующий проект; при обнаружении amplify/backend.ts источник описывает автоматическую интеграцию с Amplify Gen 2. Доступны шаблоны default, bare, react, backend, demo, auth-cognito и nextjs. Они различаются составом стартового приложения: от минимального Vite/lit-html и backend-only варианта до React/Vite, Next.js, демонстрации с AuthBasic, KVStore и DistributedTable или сценария с passwordless email OTP и ролями. Локальная разработка является отдельной сильной стороной скилла: блоки могут работать без AWS credentials, а mock-данные сохраняются в .bb-data/. Для окружений источник разделяет ephemeral testing через npm run sandbox и длительные окружения через npm run deploy; deploy использует least-privilege credentials. После scaffolding подробный порядок работы нужно сверять с README установленного пакета @aws-blocks/blocks, а API конкретного блока — с README соответствующего пакета, например bb-kv-store. Это ограничивает риск писать код по устаревшей общей памяти вместо документации версии, реально установленной в проекте. Скилл содержит важные ограничения безопасности. Методы ApiNamespace по умолчанию неаутентифицированы, поэтому каждый метод, который не должен быть публичным, обязан требовать auth.requireAuth(context). Секреты и API-ключи следует объявлять через AppSetting с secret: true, а не хранить в коде или .env. KVStore и AppSetting должны получать схему, принимающую только ожидаемую структуру данных: RPC проверяет форму, но не бизнес-правила. Широкие IAM-политики с * добавлять не следует; блоки уже дают scoped least-privilege доступ. Для FileBucket нельзя снимать blockPublicAccess; публичные файлы должны отдаваться через CloudFront. В production нужно явно задать CORS_ALLOWED_ORIGINS и не использовать wildcard. Для cross-domain аутентификации передаётся crossDomain: true, а для мониторинга Hosting может включать alerts через monitoring и SNS topic. Публичным приложениям всё равно потребуются WAF и throttling API Gateway через CDK — эти меры не включены автоматически. Logger умеет безопасно сериализовать циклические структуры, но не редактирует секреты, поэтому credentials и токены нельзя передавать ему в сыром виде. Таким образом, карточка помогает начать проект и выбрать блоки, но не отменяет ревью IAM, CORS, auth, WAF и конфигурации production перед deploy.