INSANE v2

Mi az a v2?

A v2 egy teljesen újraírt motor az insane alá. Ez azt jelenti, hogy a backend és a frontend teljesen nulláról van újraírva az új kor technológiáinak megfelelően. Az esetlegesen újrafelhasznált kódok teljesen át lettek nézve sorról sorra és ahol kellett javítva lett.

Az újraírás folyamán az elsődleges szempont a sebességoptimalizálás. Ebből kifolyólag bizonyos kompromisszumokat meg kellett kötni. Ezekről részletesen lejjebb lehet olvasni.

További cél volt a jó skálázhatóság is és a gyors fejleszthetőség is, az ismert modern technológiák minél jobb kihasználásával együtt (MVW pattern, frameworking, stb.).

A v2 koránt sincs kész, folyamatos fejlesztés alatt áll. Ez jelenti új funkciók bevezetését, valamint a már megírtak folyamatos modernizálását, karbantartását is.

A backend

A rendszer hátulja továbbra is php. Ennek több oka is van. Egyrészt a php nyelv sokat fejlődött az utóbbi időben, másrészt a backward compatibility miatt is szükség volt rá, harmadrészt pedig ehhez a nyelvhez volt kellő szaktudás.

Backward compatibility

Mivel a motor teljes újraírása óriási munka, úgy döntöttünk, hogy bizonyos elkészült elemeket a már futó rendszerben is használni akarunk. Egyrészt tesztelési, másrészt modernizálási célokkal. Emiatt a már futó rendszer mögött is sok helyen a v2-es modulok tudnak futni. Ennek viszont olyan ára volt, hogy a futó rendszerrel is kompatibilisnek kellett lennie a rendszernek. Ez némi kompromisszummal járt ugyan, de megoldható volt. Persze emiatt a futó rendszerhez is sok helyen hozzá kellett nyúlni, a korábbi xbt-s kódnak már csak töredéke van jelen a rendszerben, az is inkább csak a frontenden.

PHP

A kód 5.3-as php verzióban kezdett íródni, de az idők folyamán az újabb verziók megjelenésével azokkal is kompatibilis módon folytattuk a fejlesztést, PHP 7.0-ával is futtatható, deprecated funkciók sehol sincsenek használva.

A teljes kód objektumorientált, bizonyos megkötésekkel megfelelő design patterneket is használtunk, de a backward comptibility miatt nincs például namespacing, de ettől még teljes értékűen MVW alapokon íródik a dolog.

Design

A korábbi torrent motorokkal ellentétben cél volt egy jól fejleszthető, skálázható, tesztelhető rendszer megírása. Hasonló irányt vett a whatcd-s Gazelle is egyébként, bár ott más megoldások születtek. Patternként leginkább a MVW rendszer áll legközelebb az insane v2 motorhoz. A view teljesen szeparált (template-elhető), vékony controller réteggel és heavy Model réteggel megtámogatva. Ennek segítségével nagyon gyorsan fejleszthető. Például egy bookmarking rendszer hozzáadása 1-1,5 óra volt, aminek java része a view megírása volt.

Mivel nagyon sok interakció van az oldalon, a controller réteg ketté lett választva és kapott egy auto evaluation réteget is, így a formok kezelése is villámgyors és biztonságos és igen jól skálázható.

Framework/nem Framework

A v2-es motor felfogható framework-ként, mivel minden általánosan lett megírva és controller rendszeren keresztül van csak példányosítva (API-zható is). Ugyanakkor, mivel cél volt a sebességoptimalizálás, bizonyos helyeken eltértünk az általános framework szabályoktól. A v2 nem készül más oldalak számára, és a fejlesztése sem nyílt. Ebből kifolyólag néhány helyen megengedtük azt a luxust, hogy speciális insane specifikus kódok legyenek a model rétegben is. Ezzel megspórolhatjuk, hogy rettenetes objektumhierarchiák keletkezzenek minden futásnál. Továbbá nem keletkezett irtózatos osztálymennyiség sem, így nincsenek interface-ek és factory-k sem, de nincs is rá szükség. Ez futásidő szempontból a nagy lekérésmennyiség miatt erősen memória és processzorkímélő megoldásnak bizonyult. Csak összehasonlításképp a korábbi xbt-s oldal generálást néhol sikerült a tizedére csökkenteni.

Adatbázis

A backward compatibility és a korábbi rendszerrel való párhuzamos futás miatt az adatbázis ugyanaz maradt, mint a korábbi, azaz egy MariaDB fork. MySQLi kompatibilitással. Erre a modern php direktívák miatt is szükség volt.

Egyébként emiatt a v1-et is teljesen ezekre az alapokra helyeztük már korábban, és nincsenek a kódban mysql_query-k sem sehol.

Adatbázis design

Sokáig hezitáltunk az InnoDB és MyISAM motorok közt, végül mégiscsak MyISAM-nál maradtunk. Egyrészt sebesség optimalizációs szempontok miatt, másrészt akkor még az InnoDB nem támogatta a FULLTEXT search-öt (azóta már igen). Így sajnos elvesztettünk pár nagyon kényelmes és hasznos funkciót, mint például az idegen kulcs kezelést vagy a rollbackinget, de a MyISAM pont arra van optimálva, amit az oldal működését is jellemzi, azaz rengeteg olvasás (select hegyek) és kevesebb írás. A szakirodalom szerint a MyISAM akár 15%-kal is gyorsabb lehet ilyen esetekben. Persze ez extra effortot jelent php oldalon, de kezelhető mennyiséget.

Adatbázis használat

Kód szinten a php csak egy saját, speciális csatolón keresztül kommunikál az adatbázissal, ezért adatbázis csatlakozás, valós adatbázis műveletek csak egyetlen ponton vannak a rendszerben. Ennek eredményeképp az adatbázis nagyon rövid időn belül lecserélhető a rendszer mögött - és persze a kód sincs tele mysql_query-kkel. A csatoló kapott pár hasznos funkciót, így nagyon könnyű lekéréseket végezni bárhol a rendszerben. Természetesen amit lehet, kivezettünk user cache-be, hogy kíméljük az adabázist és csökkentsük az egyidejű kapcsolatok számát.

A táblák nevei csak egyetlen helyen vannak megadva konstansként, így egy táblát átnevezni, vagy áttérni egy másik táblára egy modellen belül egy pillanat műve. Biztonsági okokból például a felhasznalok táblanév helyett használhatunk xyz nevet a torrentekre yxz-t, stb.

Caching

Mivel a modern PHP-s rendszerek megoldják az opcode cachinget beépítve, ezért ezzel nem kellett már külön foglalkozni. Ugyanakkor a korábbi user caching rendszereket (APC) már nem lehet használni. Egyelőre az oldal mögött APCu fut. Ez ugyan elosztott rendszerekhez nem alkalmas, de az insane még nem hízta ki az egyszerveres kiszolgálást, így megtartjuk addig, amíg fejlesztik és nem kell több szerverre költözni. Ha ez megtörténik átállunk egy elosztott caching rendszerre (memcache, Xcache, eAccelerator). User cacheben tárolunk mindent, amit csak lehet; fordításokat, kategória táblázatokat, és rengeteg minden mást is természetesen. A cache pucolás mindenhol optimálisan be van építve, ahol szükséges, így nincsenek beragadt adatok.

Hibakezelés

A rendszerben kizárólag Exception kezelés van. A hibák kiértékelésére egy felsőszintű Exception kezelő réteg van beépítve, így nagyon egyszerű a debuggolás és a hibák megfelelő formájának mutatása felhasználói szinttől függően. Például egy átlag felhasználó egy adatbázis hiba esetén csak egy általános hibát fog látni, míg egy sysop részletes exception-t. Ugyanígy nem kell minden ponton ellenőrzések és adatformátum ellenőrzéseket beiktatni, mert ezek egyetlen ponton elég, ha kezelve vannak. Így csökken a támadhatóság és a hibák lehetőségének száma is töredéke az egyébként lehetségesnek és ezzel együtt a kód bonyolultsága is minimális lesz.

Jogosultság kezelés

A felhasználók jogainak kezelése jogosítási mátrixokban vannak tárolva egy helyen. Ilyen például a szerkesztési jogok mátrixa, vagy az oldalelérések mátrixa, stb. Így ezek akár adatbázisba is kivezethetők (cachinggel), bár jelenleg kódban vannak tárolva a gyorsabb futás érdekében (úgysem változnak gyakran). Emiatt nem lesznek a kódban jogosításból származó ellentmondások. Például nem lesz olyan szerkesztési mező, amit a frontenden lát egy felhasználó, ugyanakkor a backenden nem lesz joga hozzá és hibát kapna.

Frontend

A frontendes fejlesztések teljesen szeparáltan vannak kezelve az MV* direktíváknak megfelelően.

HTML/CSS/JavaScript

Ahogy a backenden, úgy a frontenden is cél a minél gyorsabb futás és a minél kevesebb adatáramlás megoldása. Ebből kifolyólag a legmodernebb technológiákat igyekeztünk értelmesen felhasználni.

Az oldal természetesen mindenhol kizárólag HTML5-öt használ. Ennek megfelelően a html szerkezet szemantikusan is helyes, így könnyen skin-ezhető. Használjuk a jól scriptelhető data-* formulákat is. Aria használat cél hiányában nincs az oldalon (egyelőre). Szerkezet felépítéshez nem használunk táblázatokat, kivéve egyetlen helyen, mivel a flex még nem működik mindenhol tökéletesen.

A css a css3 szabványokat használja. Emiatt nem használunk scripteket animációkhoz, sem képeket design effektekhez (árnyékok, lekerekítések, stb.) ezzel is gyorsítva az oldalgenerálást és megjelenítést. A kód sehol sem tartalmaz inline style-okat, kizárólag class használat van mindenhol. Ez is erősen segíti a skinezést.

Javascript szintjén alapként jQuery-t használunk lib-ként, egyelőre 2.x-es verziókat. Néhány apróbb lib még bekerülhet (például webes rádió lejátszó). A rendszer egy saját "library"-t is kapott, nem a global scope van teleszórva funkciókkal. Scriptelés csak annyira van elengedve, amennyire feltétlen szükséges.

Ajax kezelés
Az insane library kapott egy összevont ajax (igazából ajaj, mert kizárólag json kommunikáció van nem xml) kezelő rendszert, így minden ajax kérés egy ponton van kezelve általánosan, így nagyon egyszerű új ajax funkciókat beépíteni és kezelni.

Mobil applikáció

A mobil böngészők rohamos fejlődése mellett megszűnt az az igény, hogy külön mobil applikációt készítsünk, így ez nincs is tervben. Az oldal webes megjelenítését igyekszünk majd mobilra is optimalizálni.