Node.js Backend Frameworks 2024

Co to jest Hono i dlaczego jest idealny do edge computing?

Hono: ultra-lightweight web framework (Yusuke Wada, 2022). Nazwa: 'ogień' po japońsku. 14KB (minified+gzipped). Zero dependencies. Web Standards: Request/Response API (nie Express req/res). Działa na: Cloudflare Workers, Deno Deploy, Bun, Node.js, Vercel Edge, AWS Lambda@Edge, Fastly Compute. Hono routing: const app = new Hono(). app.get('/users', c => c.json({users})). app.post('/users', async c => {const body = await c.req.json(). return c.json(body, 201)}). app.get('/users/:id', c => c.json({id: c.req.param('id')})). Context (c): c.req — request (Request API). c.env — environment variables. c.json(data, status) — JSON response. c.text(text) — text response. c.html(html) — HTML response. c.redirect(url) — redirect. Middleware: app.use('*', middleware). Wbudowane: cors(), logger(), compress(), secureHeaders(), csrf(). hono/validator: zValidator(json, schema) — Zod validation. TypeScript: pełen type safety. Typing per route. Hono RPC: client() z typami. Type-safe client generowany z routes. jak tRPC ale REST-based. Zod OpenAPI: @hono/zod-openapi. OpenAPI schema generowany automatycznie. Hono JSX: jsx('element', ...) — server-side HTML rendering. Kiedy Hono: edge deployment. Ultra-performance. Lightweight API. Bun/Deno runtime. tRPC alternative.

Fastify — co to jest i dlaczego jest szybszy od Express?

Fastify: szybki i niskopoziomowy web framework (Matteo Collina, Tomas Della Vecchia, 2016). Nadal Node.js. Benchmark: 30,000+ req/s (Express: 14,000 req/s). Dlaczego szybszy: JSON serialization (fast-json-stringify). Schema-based validation (ajv — JSON Schema). Route management (find-my-way — radix tree router). Pino logger (szybszy od Winston). Schema validation: fastify.route({method: 'POST', url: '/users', schema: {body: {type: 'object', properties: {name: {type: 'string'}, email: {type: 'string', format: 'email'}}, required: ['name', 'email']}, response: {201: {type: 'object', properties: {id: {type: 'number'}}}}}, handler: async (request, reply) => {...}}). TypeBox dla TypeScript: Type.Object({name: Type.String(), email: Type.String()}) zamiast JSON Schema. Plugin system: fastify.register(plugin, options). Każdy plugin ma własny scope (DI-like). fastify-plugin: wyłącz scope isolation. Lifecycle hooks: onRequest, preHandler, preSerialization, onSend, onResponse, onError. Dekoratory: fastify.decorate('db', prisma). fastify.decorateRequest('user', null). Fastify Swagger: @fastify/swagger. OpenAPI doc automatyczny. Fastify Auth: @fastify/jwt, @fastify/auth. Bearer token, cookie. Fastify vs Express: Fastify — schema validation, szybszy, TypeScript-friendly. Express — minimalistyczny, największy ekosystem, simple. Fastify dla: performance-critical. Schema-driven API. Fastify + TypeBox = świetna DX.

Express.js w 2024 — czy jest jeszcze relevantny?

Express.js (2010): najstarzszy i nadal najpopularniejszy Node.js framework. 21+ milionów pobrań tygodniowo. 'Standard' przez lata. Express 5 (beta, 2024): async/await error handling. Brak require('./route')(app) — ESM. Routing.Route ulepszony. Lepsze TypeScript. Dlaczego nadal popularny: największy ekosystem middleware. Ogromna dokumentacja i zasoby. Większość tutoriali. Legacy projekty. Minimalistyczny — sam decydujesz o strukturze. Wady Express: brak schema validation (manualnie). Wolniejszy od Fastify. Brak TypeScript first. Express vs Fastify vs Hono: Express — legacy, max ekosystem. Fastify — szybki, schema, TypeScript. Hono — edge, ultra-light, Web standards. Middleware Express (popularne): body-parser (wbudowany w Express 4.16+). cors. helmet (security headers). morgan (logging). multer (file uploads). express-rate-limit. express-validator. Compression. Cookie-parser. Struktura Express projektu: routers/ (route files). controllers/ (request handlers). services/ (business logic). middleware/ (custom middleware). Express Generator: express --view=pug myapp (generator). Ale dziś lepiej ręcznie lub Template. Express i TypeScript: @types/express. ts-node lub tsx dla dev. Bun + Express: działa, ale Hono lepszy wybór dla Bun. Kiedy Express 2024: istniejące projekty. Nauka podstaw. Maximum flexibility. Brak potrzeby edge.

REST API design best practices — wersjonowanie, błędy i dokumentacja?

REST API design principles: REST (Roy Fielding): stateless, cacheable, uniform interface. HTTP methods: GET (odczyt), POST (tworzenie), PUT (pełna aktualizacja), PATCH (częściowa), DELETE (usuwanie). Resource naming: /users (kolekcja), /users/:id (zasób). Liczba mnoga. lowercase. Hyphens. Kod statusu HTTP: 200 OK, 201 Created, 204 No Content. 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 422 Unprocessable Entity. 500 Internal Server Error, 503 Service Unavailable. Odpowiedź błędów: RFC 7807 Problem Details. Content-Type: application/problem+json. {type, title, status, detail, instance}. Paginacja: Cursor-based (lepszy dla dużych danych): ?cursor=abc&limit=20. Offset-based: ?page=1&limit=20. Response: {data, meta: {total, page, limit, nextCursor}}. Filtrowanie i sortowanie: ?status=active&sort=createdAt:desc&fields=id,name. HATEOAS (optional): linki do powiązanych zasobów. {id: 1, _links: {self: '/users/1', posts: '/users/1/posts'}}. Rate limiting headers: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset. Retry-After. API versioning: URL: /api/v1/users (widoczna). Header: Api-Version: 1. Accept header: application/vnd.api.v1+json. Dokumentacja: OpenAPI (Swagger). AsyncAPI dla event-driven. Postman Collections. Redoc / Swagger UI.

tRPC vs REST vs GraphQL — praktyczne porównanie dla full-stack TS?

Podsumowanie po omówieniu poszczególnych podejść w osobnych artykułach: REST API: dobrze znany. Tooling wszędzie. Works with any client. Wady: over/under-fetching. Ręczna synchronizacja typów (jeśli nie OpenAPI). GraphQL: elastyczne queries. Schema jako kontrakt. Wady: learning curve, N+1 problem (DataLoader), złożona konfiguracja. tRPC: type-safe bez codegen. Tylko TypeScript. Wady: tylko TS klienci. Brak REST protocol. Praktyczny wybór 2024 (full-stack TypeScript): Next.js + tRPC: T3 Stack. Prostsze mutations/queries. Type-safe end-to-end. Bez REST overhead. Next.js + REST (Route Handlers): gdy potrzebujesz zewnętrznych klientów. OpenAPI spec. Hono jako osobne API: lightweight. Cloudflare Workers. Hono RPC jako tRPC alternative. NestJS + REST: enterprise. Swagger automatyczny. Zewnętrzni klienci. NestJS + GraphQL: złożone relacje danych. Multiple teams. Subscriptions. Fastify + REST: performance. Simple API. schema validation. Mikroserwisy: każdy serwis = własne API. REST między serwisami. Message queue dla async. gRPC dla performance-critical. Decision checklist: Zewnętrzni klienci? REST lub GraphQL. Tylko TS? tRPC. Złożone relacje? GraphQL. Simple CRUD? REST + OpenAPI. Performance critical? Hono/Fastify. Enterprise structure? NestJS.

Wyślij zapytanie