AWS Blocks چیست؟ مقایسه عملی با CDK و Amplify برای ساخت Backend Type-safe

AWS Blocks در Public Preview یک Backend Toolkit متن باز مبتنی بر TypeScript است که توسعه Local-first، Type Safety از Backend تا Frontend و Deploy روی سرویس های AWS را در یک مدل واحد ترکیب می کند. سؤال درست این نیست که «آیا Blocks جای CDK یا Amplify را می گیرد؟»؛ باید ببینید پروژه شما به چه سطحی از abstraction، کنترل زیرساخت، تجربه Local و قابلیت escape به CDK نیاز دارد.

AWS Blocks دقیقاً چیست؟

Blocks مجموعه ای از Building Blockهای Backend است که Application Code، Local Development و تعریف Infrastructure را کنار هم قرار می دهد. به جای اینکه برای یک Feature ساده Auth، API، Database و Permission را از صفر با چند سرویس و Construct سیم کشی کنید، Block یک abstraction application-oriented می دهد و بخش زیادی از wiring را انجام می دهد.

این abstraction با Backend-as-a-Service کاملاً بسته تفاوت دارد، چون deployment همچنان به منابع واقعی AWS تبدیل می شود و پروژه از اکوسیستم CDK استفاده می کند. بنابراین Blocks بیشتر تلاش می کند فاصله Developer Intent و Infrastructure را کم کند تا اینکه AWS را پشت یک API مستقل از Cloud پنهان کند.

Local-first بدون AWS Account چه معنایی دارد؟

Getting Started رسمی می گوید برای شروع Local به AWS Account نیاز ندارید. Scaffold پروژه، npm install و npm run dev می تواند یک Backend محلی بالا بیاورد. Blockها Local Implementation دارند؛ مثلاً AuthBasic می تواند JWT محلی بسازد و Data Store در محیط توسعه رفتار سبک تری داشته باشد.

اما Local-first را با «Production دقیقاً شبیه Local است» اشتباه نگیرید. IAM، Network، Lambda concurrency، Service quota، Managed Database behavior و latency واقعی Cloud در Laptop بازسازی کامل نمی شوند. Local برای feedback loop سریع عالی است؛ Sandbox Cloud برای Integration parity همچنان ضروری است.

Type Safety بدون Codegen چه ارزشی دارد؟

یکی از ادعاهای اصلی AWS Blocks این است که API تعریف شده در Backend می تواند Typeهایش را مستقیم به Frontend TypeScript بدهد، بدون مرحله تولید Client. وقتی Signature تغییر می کند، Consumer در Compile خطا می گیرد و mismatch زودتر از Runtime دیده می شود. برای تیم Full-stack کوچک یا Monorepo این تجربه می تواند Boilerplate زیادی را حذف کند.

این مزیت یک Trade-off نیز دارد: هرچه Consumerها چندزبانه تر و مستقل تر شوند، Contract مشترک TypeScript کمتر کافی است. برای Public API، Mobile client یا ecosystem چندزبان، OpenAPI یا Contract مستقل هنوز ارزش دارد. Type Safety داخلی جای API versioning و backward compatibility را نمی گیرد.

AWS Blocks در برابر CDK؛ تفاوت سطح انتزاع

CDK یک Infrastructure as Code عمومی است و کنترل مستقیم تری روی Resource graph، Network، IAM و سرویس های AWS می دهد. Blocks روی CDK ساخته شده و docs رسمی می گوید می توانید CDK Constructها را کنار Blocks استفاده کنید. این escape hatch یعنی انتخاب شما الزاماً Blocks یا CDK نیست؛ می توانید 80 درصد Application plumbing را با Block و 20 درصد خاص را با CDK بسازید.

اگر معماری شما VPC پیچیده، Multi-account، cross-region، policy سفارشی یا سرویس نادری دارد، CDK مستقیم احتمالاً زودتر وارد طراحی می شود. اگر مسئله اصلی ساخت Featureهای محصول مانند Auth، CRUD، file، realtime و job است، Blocks می تواند abstraction مناسب تری باشد. معیار، محل پیچیدگی واقعی پروژه است.

AWS Blocks در برابر Amplify؛ جایگزین یا مکمل؟

مستند AWS این دو را Complementary توصیف می کند. Amplify تجربه ای Managedتر برای Hosting، CI/CD و Backendهای رایج Full-stack ارائه می دهد؛ Blocks روی Local-first و Type-safe infrastructure-from-code تمرکز دارد. پس مقایسه باید روی workflow تیم باشد، نه اینکه یکی را نسل جدید دیگری فرض کنیم.

اگر تیم می خواهد Hosting و deployment pipeline را هم در یک تجربه managed بگیرد، Amplify جذاب است. اگر تیم ترجیح می دهد backend composition در کد TypeScript باشد و escape به CDK داشته باشد، Blocks طبیعی تر است. در بعضی پروژه ها حتی ترکیب Hosting Amplify با Backend Blocks می تواند قابل بررسی باشد؛ صحت این ترکیب را باید با docs جاری و معماری خودتان تست کنید.

چه Blockهایی برای Backend وجود دارد؟

Reference رسمی دسته هایی برای Authentication، Data Storage، Realtime و Async، AI، Communication، Configuration، Observability و Hosting نشان می دهد. نمونه هایی مانند DistributedTable، Database، FileBucket، Realtime، AsyncJob و Agent کمک می کنند Featureهای رایج با قرارداد یکسان تری ساخته شوند.

وجود Block به معنی حذف تصمیم معماری نیست. Database relational و key-value رفتار یکسان ندارند؛ AsyncJob باید idempotency و retry policy داشته باشد؛ Agent نیازمند security boundary است. Block ساختن Resource را ساده می کند، اما semantic design سیستم همچنان مسئولیت تیم است.

AuthBasic، AuthOIDC و AuthCognito؛ انتخاب Prototype تا Production

Reference رسمی AuthBasic را برای سناریوهای ساده تر مانند Prototype یا Internal Tool مناسب توصیف می کند. AuthOIDC مسیر اتصال به Identity Provider سازگار با OIDC را می دهد و AuthCognito امکانات production-oriented مانند MFA، SAML و passkey را هدف می گیرد. این سه گزینه را فقط بر اساس تعداد خط کد مقایسه نکنید.

برای Production، Requirement را از Threat Model شروع کنید: MFA لازم است؟ SSO سازمانی دارید؟ Tenant isolation چگونه اعمال می شود؟ Token revocation و lifecycle چه می شود؟ Authentication فقط اثبات هویت است؛ Authorization روی resource و record باید مستقل طراحی و تست شود.

سه سطح Local، Sandbox و Production

CLI رسمی الگوی روشنی دارد: npm run dev برای Local، npm run sandbox برای محیط Cloud ایزوله و npm run deploy برای deployment production. این سه سطح یک Deployment Ladder طبیعی می سازد. Local برای سرعت، Sandbox برای رفتار واقعی AWS و Production برای rollout کنترل شده استفاده می شود.

در Sandbox دقیقاً چیزهایی را تست کنید که Local نمی تواند ثابت کند: IAM، permission boundary، network timeout، service quota، cold start، concurrency و integration با managed service. اگر Sandbox فقط برای گرفتن screenshot Demo باشد، مهم ترین ارزشش از دست می رود.

برای Next.js و SSR چه جذابیتی دارد؟

AWS در فهرست Frameworkهای پشتیبانی شده، Next.js و چند framework SSR/SPA دیگر را ذکر می کند. جذابیت برای تیم Next.js این است که frontend type-safe می تواند با backend مشترک در یک codebase توسعه پیدا کند و Local feedback سریع باشد. این موضوع برای feature team کوچک بهره وری زیادی دارد.

اما SSR deployment و backend deployment یک concern نیستند. Cache، edge/runtime compatibility، session، secret و networking باید جدا دیده شوند. قبل از adoption، یک flow واقعی SSR با Auth و data fetch را در Sandbox اجرا کنید و رفتار Local را با Cloud مقایسه کنید.

Shared Responsibility در یک abstraction ساده تر

Blocks wiring Permission را ساده می کند، اما AWS Shared Responsibility را حذف نمی کند. Deploy Role، Secret، data encryption، authorization و log hygiene همچنان نیازمند تصمیم تیم است. Abstraction می تواند خطاهای تکراری را کم کند؛ نمی تواند تعریف کند کدام کاربر باید به کدام Tenant دسترسی داشته باشد.

در Code Review، generated infrastructure را نیز قابل مشاهده نگه دارید. اگر Block پشت صحنه چند Resource می سازد، تیم باید بداند blast radius تغییر چیست. Security scanning و policy-as-code را در pipeline حفظ کنید، نه اینکه چون Resource دستی ننوشته اید آن ها را کنار بگذارید.

Vendor Lock-in را چگونه واقع بینانه بسنجیم؟

Blocks برای AWS ساخته شده و Production resources روی سرویس های AWS می نشینند؛ پس Cloud portability هدف اصلی محصول نیست. از طرف دیگر، اینکه پروژه CDK app است و CDK Construct قابل ترکیب است، خروج از abstraction Blocks در داخل AWS را ساده تر می کند. این دو نوع lock-in را از هم جدا کنید: lock-in به Cloud و lock-in به toolkit.

اگر Multi-cloud یک requirement واقعی و بودجه دار است، آن را از روز اول وارد تصمیم کنید. اگر فقط یک احتمال مبهم است، ساختن abstraction سفارشی برای portability فرضی می تواند هزینه ای بیشتر از lock-in فعلی بسازد. معماری باید constraint واقعی را حل کند، نه سناریوی خیالی.

Public Preview؛ چه ریسک هایی قبل از Adoption باید سنجیده شود؟

Preview یعنی API، behavior و Support matrix ممکن است تا GA تغییر کند. برای محصولی که اکنون MVP است این ریسک شاید قابل قبول باشد؛ برای core banking یا سرویس regulated احتمالاً نه. Feature criticality و هزینه migration را در تصمیم وارد کنید.

نسخه package را pin کنید و Changelog را در Renovation flow قرار دهید. Pilot باید یک exit plan داشته باشد: اگر Block موردنیاز تغییر کرد، آیا می توانید به CDK Construct مستقیم بروید؟ اگر جواب روشن نیست، قبل از تعمیق وابستگی آن را آزمایش کنید.

Pilot خوب برای AWS Blocks چه شکلی است؟

یک Feature واقعی اما محدود بسازید: Login، یک جدول، API، upload و یک job کوچک. همان Feature را Local اجرا کنید، Sandbox بسازید و Production-like metrics بگیرید. سپس یک Resource سفارشی با CDK کنار Blocks اضافه کنید تا escape hatch را در عمل بسنجید. Demo که فقط Todo local است بخش سخت تصمیم را آزمایش نمی کند.

معیار Pilot را قبل از شروع بنویسید: زمان ساخت Feature، تعداد تنظیمات، debug experience، testability، security review، cloud parity و هزینه عملیات. اگر Blocks فقط initial coding را سریع می کند اما debugging Cloud را سخت تر می کند، این Trade-off باید در نتیجه دیده شود.

در نهایت کدام را انتخاب کنیم؟

برای تیم TypeScript که backend محصول استاندارد، local feedback سریع و type safety end-to-end می خواهد، Blocks ارزش Pilot بالایی دارد. برای Platform team با زیرساخت پیچیده و کنترل granular، CDK همچنان primitive اصلی است. برای تیمی که Hosting و managed full-stack workflow اولویت دارد، Amplify را جدی تر مقایسه کنید.

هیچ جدول عمومی نمی تواند architecture context شما را جایگزین کند. تصمیم نهایی را با یک vertical slice واقعی بگیرید و در ADR بنویسید چرا abstraction انتخاب شده با تیم، محصول و lifecycle شما متناسب است.

Testing Strategy؛ Local Test کجا کافی نیست؟

Test Pyramid در Blocks باید سه محیط را آگاهانه تفکیک کند. Unit و business logic را تا جای ممکن بدون Cloud اجرا کنید؛ Integration سبک را روی Local Block implementation بگذارید؛ و Contractهای حساس به AWS مانند IAM، Event delivery، Object Storage permission، timeout و concurrency را در Sandbox اجرا کنید. اگر همه تست ها به Cloud وابسته شوند feedback loop کند و پرهزینه می شود؛ اگر هیچ تستی Cloud نبیند، parity فرضی باقی می ماند.

برای هر Block یک «cloud-only risk» بنویسید. مثلاً FileBucket می تواند در Local ساده باشد اما در Cloud policy، object size، presigned URL و CORS مطرح می شود. AsyncJob در Local شاید سریع پاسخ دهد ولی در Cloud retry و at-least-once delivery مهم است. این فهرست مشخص می کند کدام تست باید حتماً Sandbox باشد و از اجرای بی هدف Test Suite بزرگ جلوگیری می کند.

هزینه عملیاتی و Observability را در مقایسه وارد کنید

AWS برای خود Framework هزینه اضافه ای اعلام نمی کند و هزینه سرویس های زیرساختی مصرف شده باقی می ماند. اما Total Cost فقط صورت حساب Cloud نیست. زمان Debug، تعداد Resourceها، build/deploy duration، نیاز به Platform expertise و پیچیدگی Incident Response نیز هزینه اند. Pilot باید این موارد را کنار سرعت اولیه توسعه اندازه بگیرد.

Observability را هم از ابتدا امتحان کنید. ببینید Trace یک درخواست از frontend تا API و database چقدر قابل دنبال کردن است، logهای Local و Cloud چقدر متفاوت اند و تیم در Incident چگونه از abstraction Block به Resource زیرین می رسد. abstraction خوب فقط Happy Path را کوتاه نمی کند؛ مسیر فهمیدن Failure را هم باید قابل مدیریت نگه دارد.

تناسب با مهارت تیم؛ عامل پنهان انتخاب Toolkit

اگر بیشتر تیم Application Developer است و تجربه عمیق IAM/CDK ندارد، Blocks می تواند onboarding را ساده کند؛ اما باید حداقل یک Owner زیرساخت بداند abstraction در Cloud به چه Resourceهایی تبدیل می شود. برعکس، تیم Platform باتجربه CDK ممکن است هزینه یادگیری abstraction تازه را بیشتر از کاهش boilerplate ببیند.

در ADR فقط Featureهای Toolkit را ثبت نکنید؛ مهارت فعلی تیم، bus factor و مدل ownership را هم بنویسید. ابزاری که یک نفر آن را عالی می فهمد اما بقیه هنگام Incident نمی توانند Debug کنند، در مقیاس تیم انتخاب خوبی نیست. Adoption موفق زمانی است که توسعه روزمره ساده تر شود بدون اینکه عملیات Production به دانش پنهان وابسته بماند.

نمونه یا الگوی عملی

npm create @aws-blocks/blocks-app@latest my-app
cd my-app
npm install
npm run dev
# سپس برای تست رفتار واقعی AWS:
npm run sandbox

دستورها بر اساس Getting Started و CLI رسمی هستند. Local برای شروع بدون AWS Account است؛ Sandbox را برای سنجش IAM، network و managed-service behavior وارد جریان تست کنید.

پرسش های متداول

آیا AWS Blocks جایگزین AWS CDK است؟

خیر. AWS Blocks روی CDK ساخته شده و می توانید CDK Construct را کنار Blockها استفاده کنید.

آیا بدون AWS Account می توان AWS Blocks را اجرا کرد؟

بله؛ مستند رسمی Local Development را بدون AWS Account پشتیبانی می کند.

AWS Blocks با Amplify چه فرقی دارد؟

AWS آن ها را مکمل توصیف می کند: Amplify بیشتر hosting/CI-CD/managed backend و Blocks بیشتر local-first type-safe infrastructure-from-code.

آیا AWS Blocks برای Production آماده است؟

در زمان این مقاله Public Preview است؛ برای workload حیاتی باید preview risk و support matrix جاری را بررسی کنید.

برای شروع چه نسخه Node.js لازم است؟

Getting Started رسمی Node.js 22 یا بالاتر و npm 10 یا بالاتر را به عنوان پیش نیاز ذکر می کند.

آیا Local دقیقاً مثل Cloud رفتار می کند؟

نه. Local feedback سریع می دهد اما IAM، quota، latency و managed-service behavior باید در Sandbox Cloud آزمایش شود.

منابع رسمی

• اعلام رسمی Public Preview شدن AWS Blocks — تعریف محصول، local-first، Type Safety، CDK escape و availability
• AWS Blocks Developer Guide؛ معرفی و مقایسه با Amplify/CDK — رابطه Blocks با CDK و Amplify و مدل backend toolkit
• Getting Started رسمی AWS Blocks — پیش نیاز Node/npm و اجرای Local
• Building Blocks Reference رسمی — Auth، Data، Realtime، AI و سایر Blockها