Tudástár / Fejlesztői mélységek

Fejlesztői és technikai mélységek

Infrastruktúra, architektúra és teljesítmény azon a szinten, amit a modern webalkalmazások valóban megkövetelnek. Konkrét példák és szakmai kontextus, nem csak definíciók.

Mi az a stack és hogyan érdemes választani?

A stack a webalkalmazás teljes technológiai ökoszisztémáját jelenti: backend nyelv és keretrendszer, adatbázis, cache réteg, frontend technológia, szerver- és infrastruktúra megoldás. Egy rossz stack választás évekre meghatározza a fejlesztési sebességet, a karbantartási terhet és a skálázási lehetőségeket.

Tipikus modern stack például: Laravel + Livewire + MySQL + Redis + Nginx — erős ökoszisztéma, gyors fejlesztés, jól dokumentált, ideális SaaS és vállalati alkalmazásokhoz. Vagy: Laravel API + Vue.js/React SPA + PostgreSQL + Horizon — ha a frontend és backend élesen elválik, pl. mobilapphoz is kell API.

Stack választásnál a legfontosabb szempontok: az elérhető fejlesztői tudásbázis, a hosszú távú karbantarthatóság, a közösség mérete és aktivitása, és hogy a stack jól illeszkedik-e a konkrét üzleti igényekhez. A divatos technológia nem mindig a legjobb — a stabil, jól ismert stack hosszabb életciklust jelent.

Mi az a cache invalidation és miért tartják a fejlesztés egyik legnehezebb problémájának?

A cache invalidation azt jelenti, hogy a tárolt gyorsítótár-adatot érvénytelenítjük, amikor a mögöttes valódi adat megváltozik. Phil Karlton mondásában két nehéz dolog van a számítástechnikában: az egyik a cache invalidation, a másik az elnevezés.

A nehézség abban rejlik, hogy pontosan tudni kell, melyik cache elemet kell érvényteleníteni egy változáskor — és mikor. Túl korán érvénytelenítve elvész a cache előnye; túl lassan érvénytelenítve elavult adatot látnak a felhasználók. Komplex alkalmazásoknál egy adat módosítása sok más adat cache-ét is érintheteti.

Megközelítések: TTL-alapú (az adat X idő után automatikusan lejár — egyszerű, de nem precíz), eseményvezérelt invalidation (adatmódosításkor explicit törlés — precíz, de bonyolultabb), és cache tag-ek (pl. Laravel Cache tags: összefüggő rekordokat egy tagben invalidálunk).

Mi az a DNS TTL fejlesztői szemszögből és hogyan hat a migrációra?

A TTL (Time To Live) másodpercekben megadja, mennyi ideig cache-elhetik a névszerverek és kliensek az adott DNS rekordot. Szervermigráció esetén ez kulcsfontosságú: ha a TTL 86400 (24 óra) és megváltoztatjuk az A rekordot, az összes korábban cache-elt kliens még 24 óráig a régi szerverre fog csatlakozni.

Bevált migráció előtti eljárás: 72 órával az élesítés előtt csökkenteni a TTL-t 300 másodpercre (5 perc). Miután a régi TTL lejárt (tehát 86400 másodperccel a TTL-csökkentés után), megváltoztatjuk az A rekordot — és az új rekord 5 percen belül mindenhol érvénybe lép. Élesítés után a TTL visszaállítható magasabb értékre.

Zero-downtime migrációnál érdemes egy ideig párhuzamosan futtatni mindkét szervert, és csak a DNS-változás teljes propagációja után leállítani a régit.

Mi az a PHP-FPM és hogyan konfigurálható a worker limit?

A PHP-FPM (FastCGI Process Manager) a PHP folyamatkezelő rendszere, amely elkülöníti a PHP futtatást a webszervertől (Nginx, Apache). A worker pool-ok kezelik a bejövő PHP kéréseket: egy worker egyszerre egy kérést tud kiszolgálni.

A pm.max_children beállítás meghatározza a maximálisan futtatható worker folyamatok számát. Ha ez az érték alacsony és sok egyidejű kérés érkezik, a kérések sorba állnak, a válaszidő megnő — tipikus bottleneck forgalmas oldalakon. Ha túl magas, a szerver elfogy a memóriából.

Ökölszabály: max_children = elérhető memória / egy worker átlagos memóriahasználata. Például 4 GB RAM-ból ha egy worker átlagosan 50 MB-ot használ, az optimum körülbelül 80 worker. A pm.status_path-szal élőben monitorozható a pool kihasználtsága.

Mi az a load balancing és mikor válik szükségessé?

A load balancer a bejövő forgalmat több backend szerver között osztja szét, növelve a kapacitást és a rendelkezésre állást. Ha egy szerver kiesik, a load balancer automatikusan a többit veszi igénybe — zero downtime.

Terheléselosztási algoritmusok: Round Robin (egyszerű körforgás), Least Connections (mindig a legkevésbé terhelt kap új kérést), IP Hash (egy IP mindig ugyanarra a szerverre kerül — session-kezeléshez fontos).

Load balancing előtt fontos a session-kezelést megoldani: ha a felhasználó minden kérésnél más szerverre kerülhet, a szerveren tárolt session adatok elvesznek. Megoldás: session-ek Redis-be vagy adatbázisba mentése (megosztott backend), amit mindegyik node elér. Nginx és HAProxy a leggyakoribb szoftveres megoldások; felhő alapon az AWS ALB/NLB, vagy a Cloudflare Load Balancing.

Mi az a Docker és miben más a virtuális géptől?

A Docker az alkalmazást és minden függőségét (PHP verzió, könyvtárak, konfiguráció) egy izolált konténerbe csomagolja. A konténer bárhol ugyanúgy fut — fejlesztői laptopon, staging szerveren, éles környezetben. Ez eliminálhja a „nálam működik" problémát.

A virtuális géptől (VM) a fő különbség: a VM teljes operációs rendszert emulál (GB-os overhead), a Docker konténer a host OS kernelét használja (MB-os overhead, sokkal gyorsabb indítás). Ezért Docker konténerek sokkal hatékonyabbak és gyorsabban skálázhatók.

Laravel fejlesztői környezethez a Laravel Sail egy Docker Compose-alapú, előre konfigurált megoldás, amely percek alatt felállít PHP, MySQL, Redis, Mailpit és Minio konténereket. Éles környezetben a Kubernetes (K8s) a konténerek orchestrálásának ipari standardje.

Mi az a CI/CD pipeline és mit automatizál valójában?

A CI (Continuous Integration) automatikusan lefuttatja a teszteket és statikus analízist minden egyes kód push után — így a hibák azonnal kiderülnek, nem hetekkel később. A CD (Continuous Deployment/Delivery) automatizálja a deploy folyamatot: ha minden teszt zöld, a kód automatikusan kijut staging-re, majd élesre.

Egy tipikus Laravel CI/CD pipeline lépései GitHub Actions-ban: kód checkout → Composer install → PHPUnit tesztek → Laravel Pint (code style) → Larastan statikus analízis → SSH-n keresztüli deploy (pl. Envoyer-rel vagy custom deploy scripttel) → Artisan migrate + cache:clear + queue:restart.

A CI/CD értéke nem a „lustaságban" rejlik — abban, hogy a deploy kiszámítható, reprodukálható és dokumentált folyamat lesz. Nincs emberi hiba, nincs elfelejtett php artisan migrate, nincs deploy pénteken délután kézzel.

Mi az a Lighthouse score és mit jelent a Core Web Vitals?

A Google Lighthouse egy nyílt forrású automatizált auditeszköz, amely négy dimenzióban értékeli a weboldalt (0-100 skálán): Performance, Accessibility, Best Practices és SEO. Chrome DevTools-ból, PageSpeed Insights-ból vagy CLI-ból futtatható.

A Core Web Vitals a Google által meghatározott három kulcsmetrika, amely 2021 óta rangsorolási tényező:

  • LCP (Largest Contentful Paint): mennyi ideig tart megjelenni a legnagyobb tartalmi elem (kép, szövegblokk). Jó: < 2.5s.
  • CLS (Cumulative Layout Shift): mennyit ugrálnak az elemek betöltés közben. Jó: < 0.1.
  • INP (Interaction to Next Paint): a felhasználói interakció (kattintás, gépelés) és a látható reakció közötti késleltetés. Jó: < 200ms.

Magas Lighthouse score nem garantál jó üzleti eredményt önmagában, de az alacsony score biztosan hátrányos — mind keresési rangsorolásban, mind felhasználói élményben.

Mi az a SQL index és mikor érdemes (és nem érdemes) létrehozni?

Az SQL index egy adatstruktúra, amely meghatározott oszlopokra épül, és lehetővé teszi az adatbázis számára, hogy tábla-teljes szkennelés helyett közvetlenül ugorjon a keresett rekordhoz — mint egy könyv tárgymutató. Index nélkül a WHERE email = ? lekérdezés minden sort megvizsgál; indexszel B-tree struktúrán navigál milliszekundumok alatt.

Mikor érdemes indexet létrehozni: WHERE feltételekben, JOIN kulcsokban, ORDER BY oszlopokban és UNIQUE kényszerekhez. Laravel-ben a migration-ökben az ->index() és ->unique() metodusokkal adható hozzá.

Mikor nem érdemes: minden INSERT, UPDATE és DELETE mellett az indexeket is frissíteni kell — írásintenzív táblákon (pl. naplótáblák) a sok index ront a teljesítményen. Egy nagyon kis táblán (néhány száz sor) a full table scan gyorsabb is lehet, mint az index olvasása. A EXPLAIN paranccsal ellenőrizhető, hogy az adatbázis valóban használja-e az indexet.

Komolyabb technikai segítségre van szüksége?

Architektúra tervezés, optimalizálás és skálázás egy kézben.

Ajánlatkérés