aws-blocks

Name: aws-blocks
Author: aws

1.1kinstalls190forks

How to install aws-blocks?

aws/agent-toolkit-for-aws/aws-blocks

$npx -y skills add aws/agent-toolkit-for-aws --skill aws-blocks

Installs into the current project.

Summary

Guides building full-stack applications with AWS Blocks — an Infrastructure-from-Code framework. Applies when creating APIs, selecting Building Blocks (KVStore, DistributedTable, Database, AuthBasic, AuthCognito, Realtime, AsyncJob, FileBucket, etc.), running local development, o

Files · 1

View on GitHub

SKILL.md

1	# AWS Blocks Application Development
2
3	> Package naming: All packages are published under the `@aws-blocks` scope (e.g., `@aws-blocks/core`, `@aws-blocks/blocks`, `@aws-blocks/bb-kv-store`).
4
5	## Overview
6
7	AWS Blocks is an Infrastructure-from-Code framework where Building Blocks bundle CDK, SDK, and local mocks into a single API. It provides 18+ Building Blocks covering storage, authentication, real-time communication, background jobs, file management, AI/search, email, and observability — all working locally without AWS credentials.
8
9	Key characteristics:
10
11	- One `aws-blocks/` directory defines the entire backend
12	- Frontend imports are fully typed — no client generation needed
13	- All Building Blocks work locally without AWS (mocks persist to `.bb-data/`)
14	- Deploy ephemeral, individual testing environments with `npm run sandbox` and long-lived environments with `npm run deploy` using least-privilege credentials
15
16	## Scaffolding a New Project
17
18	```bash
19	npx @aws-blocks/create-blocks-app my-app
20	cd my-app
21	```
22
23	### To add AWS Blocks to an existing project:
24
25	```bash
26	npx @aws-blocks/create-blocks-app .
27	```
28
29	This detects the existing project and adds an `aws-blocks/` workspace alongside your code.
30
31	### To add AWS Blocks to an Amplify Gen 2 project:
32
33	```bash
34	npx @aws-blocks/create-blocks-app .
35	```
36
37	When the CLI detects `amplify/backend.ts`, it automatically integrates AWS Blocks with your Amplify backend.
38
39	### With a specific template:
40
41	```bash
42	npx @aws-blocks/create-blocks-app my-app --template demo
43	cd my-app
44	```
45
46	### Available Templates
47
48	\| Template \| Description \|
49	\|----------\|-------------\|
50	\| `default` \| Vite + lit-html starter app with basic authentication, data persistence, and realtime to help demonstrate basic app architecture and patterns (used when --template is omitted) \|
51	\| `bare` \| Vite + lit-html starter with a single "hello world" API method and a bare frontend \|
52	\| `react` \| React + Vite starter with a single API endpoint and typed React frontend \|
53	\| `backend` \| Backend-only — no frontend, just the AWS Blocks API with a single endpoint \|
54	\| `demo` \| Todo app with AuthBasic, KVStore, DistributedTable, Zod schemas, indexes, and auth-protected CRUD \|
55	\| `auth-cognito` \| Full AuthCognito passwordless email-OTP with roles, device management, and Authenticator UI \|
56	\| `nextjs` \| Next.js + React starter with AWS Blocks backend integration (SSR + Server Components) \|
57
58	## Development Workflow
59
60	After scaffolding, refer to node_modules/@aws-blocks/blocks/README.md for the complete development workflow including:
61
62	- Core concepts (Architecture, Building Block selection)
63	- Project structure and Scope organization
64	- Error handling patterns
65	- Schema validation
66	- Local development
67	- Best practices and common mistakes
68	- Deployment IAM role setup and security guidance
69
70	When implementing a specific Building Block, read its package README for the detailed API reference (e.g., `node_modules/@aws-blocks/bb-kv-store/README.md`). These are the authoritative docs for your installed version.
71
72	## Security Considerations
73
74	- Use `await auth.requireAuth(context)` in every method that shouldn't be public — ApiNamespace methods are unauthenticated by default
75	- Use `new AppSetting(scope, id, { secret: true })` for API keys and credentials — never hardcode or use `.env` files
76	- Always attach a schema to KVStore/AppSetting that accepts user data — the RPC layer validates structure but not business logic
77	- Do not add broad `*` IAM policies — each Building Block already grants least-privilege scoped to its own resources
78	- Never change `blockPublicAccess` on FileBucket — serve public files through CloudFront instead
79	- Configure `CORS_ALLOWED_ORIGINS` explicitly for production — avoid wildcards
80	- For cross-domain deployments, pass `crossDomain: true` to auth constructors (enables `SameSite=None; Secure; Partitioned`)
81	- Enable `monitoring: { enabled: true, snsTopicArn: '...' }` on Hosting for production alerts
82	- Add WAF and API Gateway throttling via CDK for public-facing apps — not included by default
83	- Logger provides serialization safety (circular refs, type coercion) but does NOT redact sensitive content — never pass raw credentials, tokens, or secrets to Logger methods; sanitize context objects before logging

People who liked this also viewed

6 picks

Type

aws-blocks

1.1kinstalls190forks

View on GitHub

How to install aws-blocks?

aws/agent-toolkit-for-aws/aws-blocks

$npx -y skills add aws/agent-toolkit-for-aws --skill aws-blocks

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# AWS Blocks Application Development
2
3	> Package naming: All packages are published under the `@aws-blocks` scope (e.g., `@aws-blocks/core`, `@aws-blocks/blocks`, `@aws-blocks/bb-kv-store`).
4
5	## Overview
6
7	AWS Blocks is an Infrastructure-from-Code framework where Building Blocks bundle CDK, SDK, and local mocks into a single API. It provides 18+ Building Blocks covering storage, authentication, real-time communication, background jobs, file management, AI/search, email, and observability — all working locally without AWS credentials.
8
9	Key characteristics:
10
11	- One `aws-blocks/` directory defines the entire backend
12	- Frontend imports are fully typed — no client generation needed
13	- All Building Blocks work locally without AWS (mocks persist to `.bb-data/`)
14	- Deploy ephemeral, individual testing environments with `npm run sandbox` and long-lived environments with `npm run deploy` using least-privilege credentials
15
16	## Scaffolding a New Project
17
18	```bash
19	npx @aws-blocks/create-blocks-app my-app
20	cd my-app
21	```
22
23	### To add AWS Blocks to an existing project:
24
25	```bash
26	npx @aws-blocks/create-blocks-app .
27	```
28
29	This detects the existing project and adds an `aws-blocks/` workspace alongside your code.
30
31	### To add AWS Blocks to an Amplify Gen 2 project:
32
33	```bash
34	npx @aws-blocks/create-blocks-app .
35	```
36
37	When the CLI detects `amplify/backend.ts`, it automatically integrates AWS Blocks with your Amplify backend.
38
39	### With a specific template:
40
41	```bash
42	npx @aws-blocks/create-blocks-app my-app --template demo
43	cd my-app
44	```
45
46	### Available Templates
47
48	\| Template \| Description \|
49	\|----------\|-------------\|
50	\| `default` \| Vite + lit-html starter app with basic authentication, data persistence, and realtime to help demonstrate basic app architecture and patterns (used when --template is omitted) \|
51	\| `bare` \| Vite + lit-html starter with a single "hello world" API method and a bare frontend \|
52	\| `react` \| React + Vite starter with a single API endpoint and typed React frontend \|
53	\| `backend` \| Backend-only — no frontend, just the AWS Blocks API with a single endpoint \|
54	\| `demo` \| Todo app with AuthBasic, KVStore, DistributedTable, Zod schemas, indexes, and auth-protected CRUD \|
55	\| `auth-cognito` \| Full AuthCognito passwordless email-OTP with roles, device management, and Authenticator UI \|
56	\| `nextjs` \| Next.js + React starter with AWS Blocks backend integration (SSR + Server Components) \|
57
58	## Development Workflow
59
60	After scaffolding, refer to node_modules/@aws-blocks/blocks/README.md for the complete development workflow including:
61
62	- Core concepts (Architecture, Building Block selection)
63	- Project structure and Scope organization
64	- Error handling patterns
65	- Schema validation
66	- Local development
67	- Best practices and common mistakes
68	- Deployment IAM role setup and security guidance
69
70	When implementing a specific Building Block, read its package README for the detailed API reference (e.g., `node_modules/@aws-blocks/bb-kv-store/README.md`). These are the authoritative docs for your installed version.
71
72	## Security Considerations
73
74	- Use `await auth.requireAuth(context)` in every method that shouldn't be public — ApiNamespace methods are unauthenticated by default
75	- Use `new AppSetting(scope, id, { secret: true })` for API keys and credentials — never hardcode or use `.env` files
76	- Always attach a schema to KVStore/AppSetting that accepts user data — the RPC layer validates structure but not business logic
77	- Do not add broad `*` IAM policies — each Building Block already grants least-privilege scoped to its own resources
78	- Never change `blockPublicAccess` on FileBucket — serve public files through CloudFront instead
79	- Configure `CORS_ALLOWED_ORIGINS` explicitly for production — avoid wildcards
80	- For cross-domain deployments, pass `crossDomain: true` to auth constructors (enables `SameSite=None; Secure; Partitioned`)
81	- Enable `monitoring: { enabled: true, snsTopicArn: '...' }` on Hosting for production alerts
82	- Add WAF and API Gateway throttling via CDK for public-facing apps — not included by default
83	- Logger provides serialization safety (circular refs, type coercion) but does NOT redact sensitive content — never pass raw credentials, tokens, or secrets to Logger methods; sanitize context objects before logging

People who liked this also viewed

6 picks

Type