TypeScript‑first: Next.js, React, Angular

Az elsődleges stackünk a TypeScript, erős fókuszsal a Next.js‑en és a Reacten, amit Angularral egészítünk ki, ahol annak ökoszisztémája és struktúrája ad több értéket. A gyakorlatban ez többek között azt jelenti, hogy:

• Next.js‑t használunk modern React appokhoz (SSR/SSG, app router, server components ott, ahol tényleg segít)
• Reactet választunk erősen interaktív felületekhez és design system alapú dashboardokhoz
• Angulart ott vetünk be, ahol az opinionated struktúra, DI és RxJS hozza a legtöbb értéket

Folyamatosan követjük a Next.js újdonságait (routing, caching, server actions, RSC, turbopack, partial prerendering stb.), és csak akkor visszük be őket a projektekbe, ha mérhető előnyt adnak teljesítményben, fejlesztői élményben vagy az infra egyszerűsítésében – nem csak azért, mert újak.

Design system, MUI és Tailwind

Koherens design systemeket építünk, nem elszórt képernyőket. React alapú projekteknél ez gyakran MUI és Tailwind CSS kombinációját jelenti:

• MUI a hozzáférhető, jól tesztelt komponensekhez és layout elemekhez
• Tailwind a gyors iterációhoz tipográfián, térközökön, reszponzív viselkedésen
• Saját komponenskönyvtár, ha a brand vagy a UX ezt megköveteli

Így a frontend egységesen néz ki, kiszámíthatóan viselkedik minden breakpointon, és több csapat is tud rajta dolgozni anélkül, hogy minden release vizuális regresszióval járna – ami végső soron kevesebb hibajavítást és alacsonyabb karbantartási költséget jelent.

State management a valós igényekhez igazítva

Nem erőltetünk egyetlen state management könyvtárat minden projektre. Olyan eszközöket választunk, amelyek illenek az alkalmazás komplexitásához:

• Egyszerűbb esetekben elég a React hook + context alapú lokális state
• Összetettebb, több képernyőn megosztott állapotnál jöhet Redux Toolkit, Zustand vagy NgRx
• Adatlekéréshez React Query, SWR és hasonló cache‑tudatos, robusztus megoldások

Ez hosszú távon érthetőbb kódot, kisebb belépési küszöböt új fejlesztőknek és kevesebb félreértést jelent – ami nagyon konkrétan látszik a bevezetési idő, a hibák száma és a fejlesztési költség alakulásán.

Playwright és CI/CD – kockázat helyett kontroll

A komoly frontendet nem tekintjük „best effort” alapon tesztelt területnek. A Playwright‑tal a kritikus üzleti folyamatokat (checkout, login, onboarding, backoffice workflowk) védjük le teljes end‑to‑end tesztekkel, mindezt CI/CD pipeline‑ba kötve. Ha szükséges, kiegészítjük ezt olyan eszközökkel, mint a Vitest, fókuszált unit és komponens tesztekhez – de ezek az e2e + CI/CD mellett inkább támogató szerepet játszanak:

• Több böngészőn futó ellenőrzések, ahol ez üzletileg indokolt
• Stabil teszt ID‑k, nem törékeny CSS szelektorok
• Gyorsan lefutó tesztcsomagok, amelyek beleférnek a napi fejlesztési ciklusba

Ennek az eredménye üzleti oldalról az, hogy gyakrabban lehet új funkciót kitenni, kisebb a release‑ek kockázata, és ritkábbak a drága, „mindent állítsunk vissza” típusú incidensek.

AI‑val megtámogatott frontend fejlesztés

A fejlesztés során aktívan használunk AI eszközöket: tesztadat generálásra, komponens skeletonok felrajzolására, refaktorok átnézésére és alternatív megoldások feltérképezésére. Nem a fejlesztők kiváltása a cél, hanem az, hogy gyorsabban, stabilabban jussunk el ugyanarra a minőségre – vagy jobbra.

Készül egy dedikált cikkünk arról is, hogyan használunk AI‑t a teljes delivery folyamatban – a tervezéstől a kód review‑n át az automatizált tesztelésig. Erről részletesebben az AI a szoftverfejlesztésben cikkben lehet majd olvasni, amint publikáljuk.