Kronika AI-native
developmentu

Masz API, które odpowiada w 400 ms. Baza danych jest obciążona, użytkownicy czekają, a Ty patrzysz na wykresy i wiesz, że coś trzeba zrobić. Redis może rozwiązać ten problem w jeden dzień roboczy — bez przepisywania backendu, bez migracji, bez wielkiej architektury.

Nie wszystko warto cache'ować. Zły cache to źródło bugów, nie optymalizacja. Cache'owanie jest uzasadnione gdy:

- **Zapytania do bazy zajmują >50 ms** — widać to w logach, profilerze, Sentry traces - **Te same dane są serwowane wielu użytkownikom** — lista produktów, artykuły, konfiguracja aplikacji - **Dane zmieniają się rzadko** — ceny walut odświeżane co minutę, lista kategorii aktualizowana raz na tydzień - **Trafiasz w rate limity zewnętrznych API** — GitHub API, OpenAI, Stripe — cache chroni budżet - **Masz "hot paths"** — endpoint wywoływany tysiące razy na minutę z identycznym wynikiem

...

Większość developerów zna generics z jednego kontekstu: `Array<T>`, `Promise<T>`, `useState<T>()`. To użyteczna znajomość, ale generics w TypeScript sięgają znacznie dalej. Conditional types, infer, mapped types i template literal types — to narzędzia które pozwalają budować biblioteki i utilsy bezpieczne typowo bez powtarzania kodu. Warto je znać.

Generic to parametr typowy — zmienna dla typów, tak jak argument funkcji jest zmienną dla wartości. Zamiast pisać osobne funkcje dla `string`, `number` i `User`, piszesz jedną z parametrem `T`:

```typescript // Bez generics — trzy funkcje robiące to samo function firstString(arr: string[]): string | undefined { return arr[0]; } function firstNumber(arr: number[]): number | undefined { return arr[0]; } function firstUser(arr: User[]): User | undefined { return arr[0]; }

...

Real-time to jedno z tych wymagań, które brzmi prosto, a w praktyce potrafi zepsuć architekturę całego projektu. "Chcemy live dashboard" albo "niech powiadomienia pojawiają się bez odświeżania" — i nagle stajesz przed pytaniem: WebSockets, SSE, long-polling, a może zewnętrzna usługa? W Next.js App Router sprawa ma dodatkowy twist: serverless.

Zanim wybierzesz technologię, upewnij się, że w ogóle jej potrzebujesz. Real-time jest uzasadniony gdy:

- **Live dashboards** — metryki, wykresy, statusy, które zmieniają się co kilka sekund - **Collaborative editing** — kilku użytkowników edytuje ten sam dokument jednocześnie - **Powiadomienia push** — użytkownik ma natychmiast dostać alert bez pollingu - **Live chat** — wiadomości muszą pojawiać się w czasie rzeczywistym - **Game state** — pozycje, punkty, zdarzenia synchronizowane między graczami

...

Monorepo to jedno z tych rozwiązań, które zespoły odkrywają gdy projekt rośnie — i które potrafią zepsuć developer experience równie mocno jak go poprawić. Powolne buildy, zerwane zależności między pakietami, CI które trwa 20 minut — to klasyczne bolączki źle skonfigurowanego monorepo. Turborepo rozwiązuje dokładnie ten problem: zachowuje korzyści monorepo i usuwa ból.

Monorepo to nie zawsze dobry pomysł. Warto go rozważyć gdy:

- Masz **wiele aplikacji współdzielących kod** — komponent UI używany w web app i mobile, typy współdzielone między frontendem a backendem, wspólny API client - **Teamów traktuje kod jako jeden produkt** — zmiany w shared library muszą być odzwierciedlone we wszystkich aplikacjach jednocześnie - **Chcesz atomic commits** — jedna zmiana modyfikuje shared package i wszystkie aplikacje, które z niego korzystają, w jednym PR - Masz **wspólne standardy** — linting, TypeScript config, testy — które chcesz utrzymać spójnie

...

Vercel to platforma deployment zbudowana z myślą o frontendzie i frameworkach jak Next.js. Jej główna obietnica: połącz repozytorium, zrób push i w ciągu minuty masz działającą aplikację z HTTPS, globalnym CDN i preview URL. Brzmi jak marketing — w praktyce tak właśnie to działa.

Po podłączeniu repozytorium GitHub (lub GitLab / Bitbucket) Vercel:

- Buduje projekt przy każdym push na dowolną gałąź - Generuje unikalny preview URL dla każdego pull requesta (np. `projekt-git-feature-xyz.vercel.app`) - Deployuje produkcję przy każdym merge do main/master - Konfiguruje SSL/TLS automatycznie — certyfikat Let's Encrypt bez żadnej akcji z twojej strony - Dystrybuuje statyczne zasoby przez globalną sieć CDN (Edge Network) - Zarządza Serverless Functions z kodu w katalogu `/api` lub route handlerami Next.js

...

Każdy React developer zna ten pattern: `useEffect` do fetchowania, `useState` dla `loading`, `error` i `data`, ręczne unieważnianie cache, wyścig requestów... i to tylko dla jednego endpointu. TanStack Query (wcześniej React Query) rozwiązuje ten problem systemowo. To nie kolejna biblioteka do stanu globalnego — to narzędzie zaprojektowane specjalnie do zarządzania stanem serwera.

Klasyczne podejście wygląda tak:

```typescript function UserProfile({ userId }: { userId: string }) { const [user, setUser] = useState<User | null>(null); const [loading, setLoading] = useState(true); const [error, setError] = useState<Error | null>(null);

...

TypeScript to świetne narzędzie — ale ma jeden fundamentalny problem. Jego typy istnieją tylko podczas kompilacji. W runtime nie ma po nich śladu. Oznacza to, że każde dane wchodzące do aplikacji z zewnątrz — odpowiedź z API, dane z formularza, zmienne środowiskowe — mogą mieć zupełnie inną strukturę niż zakładasz. Zod rozwiązuje dokładnie ten problem.

Wyobraź sobie, że piszesz taki kod:

```typescript interface User { id: string; email: string; age: number; }

...

Każdy kto budował full-stack TypeScript z REST wie, jak to wygląda: definiujesz typy na backendzie, kopiujesz je na frontend, piszesz fetch wraппery, dodajesz ręczne rzutowania typów i modlisz się żeby nic się nie rozjechało przy refactoringu. tRPC rozwiązuje ten problem w elegancki sposób — dając end-to-end type safety bez żadnego generowania kodu.

Klasyczny przepływ przy REST API wygląda tak:

```typescript // Backend — Express lub Next.js API route interface CreatePostRequest { title: string; content: string; authorId: string; }

...

Prisma zrewolucjonizowała pracę z bazami danych w Node.js. Type-safe queries, automatyczne migracje, czytelne schema — brzmi idealnie. Ale w 2026 roku ekosystem się zagęścił: Drizzle ORM urósł w siłę, `postgres.js` zyskał popularność, a Prisma sama przeszła gruntowne zmiany w wersji 5 i 6. Czas odpowiedzieć uczciwie: czy Prisma nadal warto?

Prisma to ORM (Object-Relational Mapper) nowej generacji dla Node.js i TypeScript. Składa się z trzech części:

**Prisma Schema** — deklaratywny plik `schema.prisma`, w którym opisujesz modele danych, relacje i konfigurację bazy.

...

Serverless zmienił sposób deployowania aplikacji. Vercel, AWS Lambda, Cloudflare Workers — płacisz tylko za to, czego używasz, zero zarządzania serwerami. Ale jest jeden problem, o którym przekonujesz się dopiero w produkcji: funkcje serverless mają limit czasu. I to ostry limit.

Vercel Functions timeout po 10 sekundach na planie hobby, 60 sekund na Pro. AWS Lambda domyślnie 3 sekundy (max 15 minut, ale to konfiguracja, nie standard). Co to znaczy w praktyce?

**Wywołania AI** — Claude API przy skomplikowanym promptcie i długiej odpowiedzi potrafi pracować 30-90 sekund. Generowanie raportu z AI? Timeout gwarantowany.

...

"Działa na moim laptopie" — to zdanie słyszałeś pewnie dziesiątki razy. W 2026 roku, gdy Docker jest standardem, nadal zdarza się regularnie. Dlaczego? Bo większość zespołów używa Dockera w DevOps-ie, ale nie rozumie, co tak naprawdę robi ich Dockerfile. Ten artykuł to fix dla tego problemu.

Docker rozwiązuje problem środowiska, ale tylko jeśli używasz go poprawnie. Trzy główne przyczyny rozbieżności między lokalnym a produkcją:

**Wersje Node.js** — lokalnie masz Node 22 LTS, na serwerze stara CI/CD image z Node 18. Aplikacja zachowuje się inaczej, bo API się zmieniło.

...

Uwierzytelnianie wygląda prosto do momentu, gdy zaczniesz implementować. Sesje, JWTs, refresh tokeny, OAuth z Google i GitHub, magic links, MFA, webhook na aktualizację użytkownika — i nagle "prosty login" to tygodnie pracy. W 2026 roku masz trzy poważne opcje dla Next.js i TypeScript: Clerk, Supabase Auth i NextAuth (teraz Auth.js v5). Każda robi to inaczej. Która pasuje do Twojego projektu?

Podstawowy email + hasło to tylko wierzchołek góry lodowej. Prawdziwy system auth w produkcji musi obsługiwać:

- **Sesje i refresh tokeny** — jak długo użytkownik jest zalogowany? Co gdy token wygaśnie w połowie żądania? - **OAuth / social login** — Google, GitHub, Apple każdy ma inne flow, edge case'y i rate limity - **MFA** — TOTP (Google Authenticator), SMS, backup codes - **Zarządzanie użytkownikami** — blokowanie kont, zmiana emaila z weryfikacją, usuwanie danych (GDPR) - **Bezpieczeństwo** — brute force protection, account takeover prevention, anomaly detection - **Webhooks** — powiadomienie własnego backendu o zmianach w user record

...