Wzorce rozwoju serverless

Wzorce rozwoju serverless dla asystentów AI eliminują luki niezawodności, które Cursor, Claude Code i Codex zostawiają w AWS Lambda, Cloudflare Workers i Vercel: idempotentne handlery deduplikujące ponowione zdarzenia S3, SQS i EventBridge, strukturalne logowanie do CloudWatch, API gateway na Cloudflare Workers z pasującym wrangler.toml, podgląd żywej infrastruktury przez serwer MCP Cloudflare oraz triage cold startów przed opłaceniem provisioned concurrency.

Twoja Lambda przetwarzająca obrazy odpala się dwa razy na ten sam upload do S3, więc połowa miniatur zostaje zapisana, usunięta i zapisana ponownie — a CloudWatch to ściana nieustrukturyzowanych console.log, których nie da się powiązać z żadnym żądaniem. W międzyczasie p99 skacze co rano do 4 sekund przez cold starty, a „poprawka”, którą ktoś wdrożył (provisioned concurrency na każdej funkcji), podwoiła rachunek. Serverless usuwa serwery, a nie problemy systemów rozproszonych: ponowienia, idempotencja, cold starty i limity poszczególnych platform to teraz Twój kod.

Ten przepis pokazuje, jak sterować Cursor, Claude Code i Codex, by generowały kod serverless, który przetrwa te problemy — a nie demo na szczęśliwej ścieżce, które psuje się przy pierwszym ponownym dostarczeniu wiadomości przez SQS.

Co wyniesiesz z tych wzorców serverless

• Gotowy prompt, który tworzy idempotentny handler AWS Lambda (deduplikacja przy ponowieniach) ze strukturalnym logowaniem do CloudWatch
• Wzorzec API gateway na Cloudflare Workers z prawdziwym wrangler.toml oraz to, jak serwer MCP Cloudflare podgląda KV/R2/D1 bez wychodzenia z edytora
• Workflow triage cold startów, który mówi, kiedy provisioned concurrency naprawdę jest warta swojej ceny
• Podział na trzy narzędzia: kiedy używać agenta w Cursor, headless runs w Claude Code i Codex Cloud do PR-ów wdrożeniowych
• Tryby awarii, które gryzą na produkcji — zduplikowane dostarczenia z SQS, hot partitions w DynamoDB, limity CPU w Workers — oraz prompty, które im zapobiegają

Workflow

Krok 1: Zbuduj szkielet usługi (gdzie trzy narzędzia się różnią)

Etap budowania szkieletu to moment, w którym ergonomia narzędzi rozjeżdża się najbardziej. Cursor edytuje pliki wizualnie w Twoim repozytorium; Claude Code uruchamia CLI frameworka z terminala i da się skryptować w CI; Codex potrafi rozdzielić to samo zadanie do worktree w chmurze i otworzyć PR wdrożeniowy. Wybieraj według tego, gdzie żyje praca, a nie według możliwości — wszystkie trzy sterują tymi samymi CLI: AWS SAM / Serverless Framework / Wrangler.

Cursor

Otwórz tryb Agent (Cmd/Ctrl + I) w pustym repozytorium i daj mu jedną konkretną usługę do zbudowania:

Set up a Serverless Framework v4 service in TypeScript targeting AWS eu-central-1. One HTTP Lambda behind API Gateway (GET /health), one S3-triggered Lambda for image processing, and a DynamoDB table media (PK id). Use esbuild bundling, Node 22 runtime, and put stage/region in serverless.yml provider vars. Add a dev and prod stage.

Agent pisze serverless.yml, zaślepki handlerów i package.json. Przejrzyj diff w pasku bocznym przed zaakceptowaniem — Cursor zapisuje checkpoint przy każdej edycji, więc możesz cofnąć zły plik bez utraty reszty.

Claude Code

Claude Code uruchamia CLI frameworka za Ciebie i jest właściwym wyborem, gdy chcesz mieć budowanie szkieletu odtwarzalne w skrypcie lub kroku CI. Daj mu tę samą konkretną specyfikację jako prompt pozycyjny:

claude "Set up a Serverless Framework v4 service in TypeScript targeting AWS eu-central-1: one HTTP Lambda behind API Gateway (GET /health), one S3-triggered image-processing Lambda, and a DynamoDB table 'media' (PK id). Use esbuild bundling, Node 22 runtime, and stage/region provider vars in serverless.yml."

Agent edytuje pliki i sam uruchamia npx serverless; nie wyświetla kreatora wyboru dostawcy — dostawcę podajesz w prompcie. Dodaj --permission-mode acceptEdits, gdy zaufasz planowi, by przestał pytać przed każdym zapisem.

Codex

Codex obejmuje CLI, IDE i Cloud. Przy jednorazowym lokalnym szkielecie ogranicz edycje do workspace i zachowaj możliwość ich przeglądu:

codex --sandbox workspace-write -c approval_policy=on-request "Scaffold a Serverless Framework v4 TypeScript service for AWS eu-central-1 with an HTTP /health Lambda, an S3-triggered image Lambda, a DynamoDB 'media' table, esbuild, Node 22, and stage/region provider vars."

Jawny sandbox ogranicza zapis do workspace; approval_policy=on-request pozwala Codex poprosić o zgodę, gdy polecenie potrzebuje szerszego dostępu, ale nie wymusza zatwierdzania każdej edycji w sandboxie. Przejrzyj diff i testy. Gdy chcesz szkielet oraz PR do przeglądu, wypchnij go do worktree w chmurze poleceniem codex cloud exec "<same prompt>, then open a PR" — Codex działa w izolowanym środowisku i oddaje gotową gałąź.

Notatka

Model ma tu znaczenie. Do wieloplikowych szkieletów i budowania usług od zera najlepsze wyniki daje Claude Fable 5; przy ograniczonym budżecie użyj do implementacji Claude Opus 5 lub Sonnet 5. Default konta Claude Code zależy od planu/providera. ChatGPT Codex oferuje GPT-5.6 Sol, Terra i Luna zależnie od planu i zadania; w API gpt-5.6 wskazuje na Sol. Aktualne ceny: porównanie modeli.

Krok 2: Uczyń handler idempotentnym (część, którą dema pomijają)

S3, SQS i EventBridge dostarczają co najmniej raz. Naiwny handler przetwarza ten sam obiekt ponownie przy retry. Rozwiązaniem jest klucz deduplikacji — dla S3 to eTag obiektu — sprawdzany zapisem warunkowym przed wykonaniem pracy. To najcenniejsza rzecz, jaką możesz umieścić w prompcie, więc powiedz to wprost:

Wskazówka

Gotowy prompt — idempotentny procesor obrazów S3 → Lambda:

Write an AWS Lambda handler in TypeScript (Node 22) for an S3 ObjectCreated trigger that resizes the uploaded image to 256/512/1024px WebP with sharp and writes them to a derived/ prefix in a destination bucket. Make it idempotent across S3 retries: before processing, do a DynamoDB PutItem with ConditionExpression: 'attribute_not_exists(pk)' on pk = <bucket>/<key>#<eTag>, and skip (return early) if the condition fails. Emit one structured JSON log line per invocation with requestId, bucket, key, eTag, and durationMs. Wrap the work in try/catch, log the error with the same requestId, and rethrow so the event lands in the configured DLQ. Then give me the matching serverless.yml function block with memorySize: 1024, timeout: 30, an onError DLQ, and the s3 event.

Ten prompt tworzy coś zbliżonego do tego — zwróć uwagę na wczesny return przy duplikacie i strukturalny log, bo to właśnie czyni kod możliwym do debugowania na produkcji:

// handler.ts — the AI-generated shape worth reviewing for
import { S3Event } from 'aws-lambda';
import { DynamoDBClient, PutItemCommand } from '@aws-sdk/client-dynamodb';

const ddb = new DynamoDBClient({});

export const handler = async (event: S3Event) => {
  const start = Date.now();
  for (const rec of event.Records) {
    const { bucket, object } = rec.s3;
    const pk = `${bucket.name}/${object.key}#${object.eTag}`;
    const log = { requestId: rec.responseElements['x-amz-request-id'], bucket: bucket.name, key: object.key, eTag: object.eTag };
    try {
      await ddb.send(new PutItemCommand({
        TableName: process.env.DEDUPE_TABLE!,
        Item: { pk: { S: pk } },
        ConditionExpression: 'attribute_not_exists(pk)',
      }));
    } catch (err: any) {
      if (err.name === 'ConditionalCheckFailedException') {
        console.log(JSON.stringify({ ...log, status: 'duplicate-skipped' }));
        continue; // already processed — S3 redelivery
      }
      throw err;
    }
    // ... resize with sharp, write derived/ objects ...
    console.log(JSON.stringify({ ...log, status: 'ok', durationMs: Date.now() - start }));
  }
};

To, co trzeba zweryfikować w wyniku AI: że zapis deduplikacyjny dzieje się przed efektami ubocznymi oraz że blok catch ponownie rzuca wyjątek (żeby DLQ faktycznie łapał awarie), zamiast go połykać.

Krok 3: API gateway na Cloudflare Workers

Na Workers ograniczenia są inne — brak środowiska Node, budżet czasu CPU na żądanie i bindings zamiast klientów SDK. Poproś o gateway i konfigurację razem, żeby bindings w wrangler.toml pasowały do kodu:

Wskazówka

Gotowy prompt — API gateway na Cloudflare Workers:

Write a Cloudflare Worker (TypeScript, ES modules) that acts as an API gateway: route GET /v1/* to an origin via fetch, enforce a bearer-token check against a TOKENS KV namespace, rate-limit per token to 100 req/min using a Durable Object counter, and cache successful GETs in the Cache API for 60s. Read the origin URL from an ORIGIN var. Return structured JSON errors { error, requestId } with the right status codes, and keep synchronous CPU work minimal — the Free plan caps CPU at 10ms per request — so defer non-blocking work with waitUntil where possible. Then give me the wrangler.toml with the KV namespace binding, the Durable Object binding + migration, and the ORIGIN var.

# wrangler.toml — the AI should produce bindings that match the Worker
name = "api-gateway"
main = "src/index.ts"
compatibility_date = "2026-06-01"

[vars]
ORIGIN = "https://origin.internal.example.com"

[[kv_namespaces]]
binding = "TOKENS"
id = "<your-kv-id>"

[[durable_objects.bindings]]
name = "RATE_LIMITER"
class_name = "RateLimiter"

[[migrations]]
tag = "v1"
new_sqlite_classes = ["RateLimiter"]

Krok 4: Podgląd działającej infrastruktury serwerem MCP Cloudflare

Wygenerowanie Workera to połowa roboty; błędy żyją w wartościach bindings — źle wpisane id namespace’u KV, nieaktualny wiersz w D1. Bez MCP przełączasz się alt-tabem między dashboardem a edytorem. Z zarządzanymi zdalnymi serwerami MCP Cloudflare AI czyta rzeczywisty stan Twojego konta oraz dokumentację w tej samej rozmowie. Konfiguracja jest identyczna we wszystkich trzech narzędziach — wskaż im zdalne endpointy (pełny katalog serwerów i przepływ OAuth w przewodniku Cloudflare MCP):

{
  "mcpServers": {
    "cloudflare-bindings": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://bindings.mcp.cloudflare.com/mcp"]
    },
    "cloudflare-observability": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://observability.mcp.cloudflare.com/mcp"]
    }
  }
}

Przed MCP debugowanie błędu nieaktualnego cache oznaczało kopiowanie id namespace’ów między czterema kartami przeglądarki. Po: „Read the TOKENS KV namespace bound to the api-gateway Worker and list the keys written in the last hour” i AI odpowiada na podstawie Twojego działającego konta. Do wdrożeń i edycji bindings z CLI lżejszą alternatywą jest skill Cloudflare wrangler — zainstaluj go poleceniem npx skills add cloudflare/skills/wrangler (z repozytorium cloudflare/skills, wymienionego na skills.sh). Skill lepiej pasuje, gdy chcesz tylko, by agent znał polecenia i konwencje wrangler; serwer MCP wygrywa, gdy potrzebujesz, by czytał stan na żywo.

Gotowe prompty

Wskazówka

Triage cold startów — zanim zapłacisz za provisioned concurrency:

My Lambda image-processor (Node 22, 1024MB, in a VPC) has p99 latency of 4s in the morning and ~300ms otherwise. Analyze the cold-start cost: check whether the VPC ENI attachment, the bundle size, or SDK client init at module scope is the dominant cost. Show me the init vs invocation split I’d see in a CloudWatch REPORT line. Then propose the cheapest fix first (lazy-init SDK clients, drop unused deps, esbuild tree-shaking, remove the VPC if it’s only there for DynamoDB) and only recommend provisioned concurrency with a concrete number if the others don’t get p99 under 1s.

Wskazówka

Sterowane zdarzeniami fan-out z DLQ i replayem:

Design an SQS → Lambda consumer (TypeScript) that processes order events with batchSize: 10 and functionResponseType: ReportBatchItemFailures so one poison message doesn’t fail the whole batch. Validate each message against a zod schema, send invalid ones to a DLQ, and make the handler idempotent on orderId via a DynamoDB conditional write. Give me the serverless.yml for the queue, the DLQ with maxReceiveCount: 3, and a small replay.ts script that re-drives the DLQ back to the main queue.

Wskazówka

Vercel Function ze streamingiem i routingiem A/B:

Write a Vercel Function that does geographic A/B routing: read the visitor country with geolocation(request) from @vercel/functions (standalone Edge Functions and request.geo are deprecated), assign a stable variant by hashing a cookie (set one if absent), and stream the chosen origin’s HTML response straight through with TransformStream. Return a Set-Cookie for the variant on first visit. Keep it Web-Streams based so it runs on either the Node.js or Edge runtime.

Gdy te wzorce serverless zawodzą na produkcji

Uwaga

Zduplikowane przetwarzanie przy ponowieniach. To błąd serverless numer jeden, a wynik AI z happy-path prawie nigdy go nie obsługuje. S3, SQS i EventBridge są at-least-once. Jeśli handler ma efekty uboczne (zapisy, maile, obciążenia), musi deduplikować po stabilnym kluczu (S3 eTag, SQS messageId, własny orderId) przed działaniem. Doprecyzuj prompt: „This handler isn’t idempotent — add a DynamoDB conditional-write dedupe on <key> and return early on a duplicate.”

Uwaga

Hot partitions w DynamoDB. Single-table design z kluczem partycji o niskiej kardynalności (np. status#PENDING) kieruje cały ruch do jednej partycji i pod obciążeniem dostajesz ProvisionedThroughputExceededException mimo niskiego średniego wykorzystania. Poproś AI, by „check the partition-key cardinality and suggest a write-sharding suffix or a GSI”, zamiast po prostu podbijać pojemność.

Uwaga

Limity CPU w Cloudflare Workers, nie czasu rzeczywistego. Workers limitują czas CPU (10ms na planie Free; domyślnie 30s na planie płatnym/Standard, podnoszalne do 5 min przez cpu_ms), a nie to, jak długo czekasz na fetch. Worker, który robi ciężkie parsowanie JSON-a albo kryptografię w pętli, dostaje Error 1102 (Worker exceeded CPU limit), choć na Twoim laptopie jest szybki. Przenieś ciężką pracę poza gorącą ścieżkę (waitUntil, konsument Queue albo Durable Object) i poproś AI, by „profile the synchronous CPU work and move anything non-blocking out of the request path.”

Uwaga

Provisioned concurrency odruchowo. Włączanie jej hurtowo na każdej funkcji to sposób, by podwoić rachunek. Pomaga tylko funkcjom na synchronicznej, czułej na opóźnienia ścieżce z przewidywalnymi szczytami. Dla asynchronicznych/sterowanych zdarzeniami Lambd (handlery S3 i SQS powyżej) cold starty rzadko mają znaczenie — najpierw napraw bundle i VPC.

Dokąd dalej z wzorcami serverless

Wzorce projektowania API Wzorce REST i walidacji, które pasują do Workera-gatewaya powyżej.

Wzorce baz danych Single-table design w DynamoDB, pulowanie połączeń i serverlessowe opcje SQL.

Infrastruktura jako kod Awansuj te stacki do Terraform/Pulumi i podłącz wieloetapowe wdrożenia.

Serwery MCP Cloudflare Pełny katalog 16 serwerów, przepływ OAuth i konfiguracja per narzędzie.