Meglévő framework használata vagy saját megoldás a teljesítményt figyelembe véve
A nemrég indított Template engine topicban kialakult egy kis beszélgetés a framework-ökről. Felhő említette többször, hogy adott esetben a terhelés csökkentése miatt nem célszerű komolyabb framework-öt használni az adott alkalmazásnál, legalábbis nem mindent azzal megoldani.
Tanulságos volt a Template engine topic, amit indítottam, mert kicsit más szemszögből is nézem már a dolgokat. Eldöntöttem, hogy nyitok a komolyabb template engine-ek felé és úgy döntöttem, hogy megismerkedem pl. a CakePHP-vel.
A kérdésem az lenne, hogy egy olyan alkalmazás fejlesztésénél ahol elég fontos a teljesítmény, a skálázhatóség, érdemes-e mondjuk CakePHP-t választani framework-nek vagy inkább egy saját (MVC) megoldást érdemes alkalmazni?
Jelenleg teljesen saját megoldások alapján működik a rendszer lelke. Úgy próbálom felépíteni a kódot, hogy ne legyenek a jövőben teljesítmény gondok. Mivel több dolog van, ami miatt kénytelen vagyok jobban odafigyelni a terhelés kérdésre, ezért is érdekelne, hogy egy folyamatosan növő rendszert érdemes-e pl. CakePHP-vel felépíteni.
Ha már framework, akkor képbe kerül a JS is, mert a következő nagyobb fejlesztés az lesz, hogy AJAX alapokra lesz átültetve a rendszer. Itt jön a kérdés, hogy pl. prototype.js-t használjak vagy inkább saját JS és AJAX megoldásokat?
■ Tanulságos volt a Template engine topic, amit indítottam, mert kicsit más szemszögből is nézem már a dolgokat. Eldöntöttem, hogy nyitok a komolyabb template engine-ek felé és úgy döntöttem, hogy megismerkedem pl. a CakePHP-vel.
A kérdésem az lenne, hogy egy olyan alkalmazás fejlesztésénél ahol elég fontos a teljesítmény, a skálázhatóség, érdemes-e mondjuk CakePHP-t választani framework-nek vagy inkább egy saját (MVC) megoldást érdemes alkalmazni?
Jelenleg teljesen saját megoldások alapján működik a rendszer lelke. Úgy próbálom felépíteni a kódot, hogy ne legyenek a jövőben teljesítmény gondok. Mivel több dolog van, ami miatt kénytelen vagyok jobban odafigyelni a terhelés kérdésre, ezért is érdekelne, hogy egy folyamatosan növő rendszert érdemes-e pl. CakePHP-vel felépíteni.
Ha már framework, akkor képbe kerül a JS is, mert a következő nagyobb fejlesztés az lesz, hogy AJAX alapokra lesz átültetve a rendszer. Itt jön a kérdés, hogy pl. prototype.js-t használjak vagy inkább saját JS és AJAX megoldásokat?
JS
Javascriptre a prototype nagyon jó, és érdemes megnézni az ext.js-t is.
nagy terhelés is relatív
Amire nagyon figyelj oda, hogy skálázható megoldásokat használj. Ha ezt mindig szem előtt tartod, akkor a terhelés növekedését jó esetben könnyen tudod kezelni. Szintén fontos, hogy lehetőleg ne vigyél bele a program strukúrába felesleges kötéseket, minél jobban cserélhetőek legyenek a rendszer különböző komponensei. Alap példa: kezdetben nincs mondjuk szükséged cachelésre, de azért jó ha figylesz arra, hogy könnyen tud beépíteni a rendszerbe.
DB esetén is valami hasonlóra kell figyelni. Előre ne állj neki optimalizálni, használj rendes, normalizált struktúrát, aztán szülség esetén úgy is ki fog derülni, hogy mi a szúk keresztmetszet, aztán ott lehet valamlyen fajta denormalizálással, összesítő táblák létrehozásával stb. segíteni.
Plusz egy valamily widget gyűjtemény az nagy áldás lehet (ext az nagy királyság), ugyanis még ha nem is bonyolult, de azért elég sokat el kéne bibelődni különböző elemek létrehozásával, meg például gondolom, hogy egy datagrid rendezésénél egy extbe quick sortot fognak használni, nem kell Neked ilyesmikkel szórakoznod. Meg mondjuk ha egy YUI elég a YAHOO oldalain, akkor az valszeg nem lesz Nálad sem szűk keresztmetszet. Szerintem (ha csak nem valami iszonyat komplex GUI-ról van szó) egy intenzívebb AJAX alkalmazás esetén is a backenddel lesz több problémád: rengeteg apró kérés, amit jó gyorsan kell kiszolgálni a felhasználói élmény bztosítása érdekében.
Üdv,
Felhő
mootools.net
de?
Miért, az Ext esetében milyen csúnya "de" van az ingyenes után?
LGPL licenszes. Azaz majdnem azt csinálsz vele, amit csak akarsz. Csak nem adhatod el, mint saját terméket. De azt hiszem, hogy ez amúgy is természetes.
Csak akkor kell business licenszet venned, ha támogatni akarod a srácokat, vagy ha prémium support-ra vágysz. Amúgy enélkül is elég hamar segítenek.
Amúgy lehet, hogy a mootools kicsi, és cute, viszont az Ext-ben olyan problémák vannak megoldva, kulcsrakészen odaadva a feneked alá, amikkel el leszel hónapokig, ha ki akarod újra fejleszteni. Lásd datagrid, sorrendezéssel, oszlop-menedzseléssel, stb.
Érdemes rá vetni egy pillantást. Én belehabarodtam. :D
Ext
Bár a mootools tetszetős a demók alapján, az Ext pontosan olyan megoldásokat szolgáltat amire szükségem lesz.
Teljes felületekre
Egyszer írtunk is róla (itthon elsőként).
Mivel a topic címében a teljesítmény szó is benne van (bár az nem a javascript framework-ökre értendő, eléggé elkanyarodtunk) fontos megjegyezni, hogy az ext-el létrehozott felület betöltődése és működése nem feltétlenül a leggyorsabb, legalábbis saját tapasztalat szerint. (ajax-os tabos navigáció és layout kezelés, layouonként rendezhető grid-ek, xml adatforrással, lapozással, szerkesztéssel). Azt azért tegyük hozzá, hogy futott mellette egy-két erőforrásigényes cucc nálam.
Like desktop
Ami a betöltést illeti, ahogy néztem az ext-base és ext-all együtt 500KB, amit ezzel a megoldással kb. 130-150 kb-ra lehet tömöríteni, ez pedig nem vészes, ha azt nézzük, hogy az alap prototype.js ~100 KB.
Ahol lehet cache-elve lesznek az adatok, tehát a JS statikus adatokat kap. Jelenleg a legkisebb keresztmetszet a webszerver és az SAP szerver közötti sávszélesség.
A kérdés az, hogy ha ext.js-t használok, akkor érdemes-e mondjuk egy CakePHP-t használni szerver oldalon?
(Ps.: Annyira azért nem kanyarodtunk el, mert a JS framework is kérdés volt ...)
like desktop
Persze ha kellenek mellé effektek, mint pl a scriptaculous, akkor már 100k-nál vagyunk, ahogy mondtad. Sőt, túl is léptük.
Az említett felületet mi egy rails alkalmazás adminjához készítettük el (ezért lehet érdekes neked a cakephp), jól működött, szép volt, stb, de rá kellett jönnünk, hogy amit a rails ajax helperei és template/partial kezelése miatt kényelmesebben tudunk dolgozni. Ezért aztán visszalakítottuk az egészet. Ezzel elvesztettük a pl. "vista look" layout-ot, és az ext-gridet, helyette csináltunk sajátot, nagyjából ugyanazt tudta, nem tartott semmiből. Jelentősen gyorsult az ui-n keresztül elvégezhető munka.
Ebből is látszik, hogy bizonyos esetekben jól jön, bizonyos esetekben nem. Jó tudni, hogy az ext kisebb komponenseit pl felhasználhatod, ha nncs szükséged az egészre: ilyen pl. a tab-os navigáció, ami klikelésre tesz láthatóvá div-eket és még a tabok is kapnak szép (browser független) layout-ot.
viszont akkor itt is megkérdem. :D
when it's done
lassúság
(Mindegyik tömörített)
Sokat segít amúgy az, hogy ha nem muszáj, akkor nem bekapcsolt Firebug-gal nézed, ugyanis a legtöbb időt az viszi el, hogy a FB felparse-olja magának a JS fájlt. Azért valljuk be őszintén, az eléggé időigényes egy 200-300, esetenként full Ext kiszerelésnél 500k-nál.