Kérések feldolgozása - avagy a Router Class
Egy dinamikus oldalnál elengedhetetlen, hogy valahogyan feldolgozzuk a kéréseket. Bevett szokás, hogy a .htaccess fileban a nem létező mappákra és file-okra csinálunk egy átirányítást az index.php-ra. Ezután millió és egy különböző megoldás van arra, hogyan dolgozzuk fel a kapott információt.
Jelenlegi módszer
Amit most használok, full egyszerű, amit már leírtam a Harc a cache-sel 1. részben. Ennek lényege, hogy adatbázisban a menüpontoknak 3 különböző értéke lehet: type, file és link. Tehát bejön a kérés a szerverhez, majd egy függvény mindenképpen kiveszi a linkből a nem oda illő karaktereket, ékezetmentesít, és minden nem megfelelő karaktert --re cserél. Ezután feldarabolja az URL-t a / jelek mentén. Az első mindig a feldolgozó egység neve. Ezt keresi meg az adatbázisban.
Például egy webshopnál lehet:
- kategóriák
- termékek
- tartalmak
- fiókom
Ezeket egyesével letárolom adatbázisban és megvizsgálom, hogy az adott linkhez tartozik-e valamilyen feldolgozó. Ha nem, akkor az 404. Egyéb esetben betölti a feldolgozót. Itt két lehetőség van, ha volt POST, akkor előbb a POST értékét dolgozza fel, majd betölti a tartalmat.
Ezzel egyetlen bajom van, túl sok kört futok feleslegesen. Kell egy egyszerűbb megoldás. Első körben - webshop témakörben - ránéztem, hogy ezt az OpenCart hogyan oldja meg, az eredmény nagyjából ugyanaz, mint amit én csináltam eddig. Csak itt egy alias táblát használ a rendszer, hogy lekérdezze a megfelelő route-ot. Tehát ezzel nem vagyok előrébb, sőt... Mivel az OpenCartnak saját SEO modulja van, ami ezért felelős, így előbb a háttérben mindig a sima route-ot állítja elő, majd ebből készít egy linket az alias alapján. Ugyanott járok, ahonnan indultam.
Minta kódok
Keresgetni kezdtem a neten php router class-ek után. Ekkor találkoztam a Pux, a klein.php és a FastRoute nevével.
A Pux egyetlen hátránya, hogy extensionként működik kimagaslóan gyorsan, amit mondjuk egy osztott kiszolgálón nem tudunk telepíteni. A klein.php-t egyik oldal dícséri, másik oldal szidja. A FastRoute volt az, ami egyből meggyőzött.
Pux?
A Pux készítője, c9s a közösség szerint is rengeteg hibát vétett. A készítő szerint az a leggyorsabb megoldás, ha a router C extensionként fut, így mivel C-ben gyorsabb a tömbök kezelése, a feldolgozás is gyorsabb, és a C kódot könnyebb optimalizálni. Az egyik támadás, ami többször is éri, hogy az almát és a narancsot próbálja összehasonlíani (Pux vs. Symphony), mivel az egyik egy Framework, a másik pedig csak egy router. Emellett sokan nem értik a C extension szükségességét. Tehát a Pux is eléggé megosztja az embereket.
Másrészről pedig azért is támadják a Puxot, mert ezzel az osztott kiszolgálók kiesnek a körből, akiknek külön kérnie kell, hogy telepítsék nekik ezt a kiegészítőt. Ezt pedig persze tudjuk, hogy sokan nem teszik meg a tárhelyszolgáltatók közül. Tehát a Pux jó, de csak saját szerveren, ahol tudod konfigurálni a php-t.
klein.php
A klein.php használatához először is Composer kell. Ha az nincs, nehéz szóra bírni a kicsikét. Másodikként a teszteken elég gyenge teljesítményt produkál. Ennek sokan hangot is adnak, így a választásból ez is kiesik.
FastRoute
Az egyetlen olyan osztály, amit anélkül tudtam életre kelteni, hogy bármit is le kellett volna töltenem (a csomagon kívül) és telepítenem. Egy sima php osztályként kapod kézhez. Ezt csak include-olod, majd mehet a menet. A készítője egy blogbejegyzésben részletezte is, hogy még a Pux-nál is jobb teljesítményt tud elérni szimplán optimalizálva a routert. Nem kell hozzá C nyelven írt extension, nem kell hozzá semmilyen extra modul. Simán, egyszerűen működik.
Így nálam jelenleg ez a nyerő router. Persze, nem fogom egyben beráncigálni az egészet a kódomba, hanem "lebutítom" annyira, hogy megfeleljen az igényeknek. Mivel sok olyan funkciója van a FastRoutenak, amit nem fogok használni, így ezeket feleslegesen tölti be.
Engem meggyőzött a sebessége, és az egyszerűsége. Mivel folyamatosan cloud szerverre vagy sima osztott tárhelyre rakom fel a programokat (ritka, hogy valakinek saját szervere van), így nekem az a fontos fejlesztéskor, hogy a lehető legtöbb helyen elérhető legyen a programom.
Például emiatt van cache-nél csak fájl alapú cachem. Mert azt sokkal több helyen érem el, mint például az APC-t vagy a Memcached-et. Majd, mikor már a saját szerverre kerülnek fel a programok, amiket 2016-ban fogunk közönség elé tárni (addig még tart a tesztelési és fejlesztési időszak, csak 1-2 ügyfél fogja megkapni a programot), akkor már a rendszergazdának megmondom, hogy x és y legyen a szerveren, és fenn lesz, akkor már lehet használni a bonyolultabb kódot, és a sokkal hatékonyabb megoldásokat is. Ezekre természetesen a rendszer fel lesz készítve, de még felesleges aktiválni őket.