Primjetio sam da je malo forum tih pa da ozivim. Zanima me malo vase misljenje o popularnim php framewoksima. Malo cu testirati i pisati svoje dozivljaje ovdje. Vi ako imate ista reci mozete slobodno, cak generalno o php-u, podijeliti linkova itd.
Glavne tocke su:
ORM/DBAL
Performansa
Template engine
Lokalizacija
Podrska za web servise (uglavnom REST)
ACL
Izgleda da su vodeci laravel i phalcon. Phalcon je jako brz i to mu je ogromna prednost. Ima i neke cli alate, dokumentaciju finu i mnogo ga developera prisvaja. Mozda jer je egzotican hehe. Instalirat cu ga pa stay tuned.
Znam da se ponavljam ko pokvarena ploča, ali, ako ikako možeš reci PHP-u ne
A sad nešto konstruktivno.
Meni se ne sviđaju samoproglašeni “šampioni” koji niču kao gljive poslije kiše i tvrde da su najbolji, najbrži i šta sve ne. Kao da je bitno koliko “hello world” requesta može servirati PHP framework (hint, u poređenju sa drugim web platformama jako malo). Ono što je bitno jesu “real world” situacije, gdje je skoro svaki PHP framework dovoljno brz. Osim ako ORM nije ekstremno glup (mahanje Yii frameworku), ili imate bug na “bazi podataka” (mahanje MySQL). Uglavnom, iskontrolišite se prilikom izrade projekta u nekom frameworku, da aplikacija ne bude 10x sporija od “običnog” PHP-a.
Imho, u zadnjih par godina, najbolji izbor je Symfony2, koji je baza kako za veoma popularne web platforme (Drupal), tako i za Laravel, najsexy PHP framework u našem dijelu galaksije.
Framework je veoma razuman, ne izmišlja toplu vodu (svoj template engine, svoj ORM, database layer), čak ima i doticaja sa Python Flask frameworkom, odnosno Jinja template jezikom.
[quote=adis]Znam da se ponavljam ko pokvarena ploča, ali, ako ikako možeš reci PHP-u ne
[/quote]
Imas li nekih prijedloga? Pretpostavljam nesto kao perl/ruby/python?
Slazem se sa ovim. Svaki framework moze biti dovoljno brz ako se pravilno konfigurira.
Inace mislim da su ORM-ovi najveci bottleneck. Dosad sam imao iskustva sa doctrine i osim sto je imao problema sa vecim brojem zapisa, cudne stvari su se desavale. Moje osobno misljenje je da bi ORM-ove trebalo zaobici zasad, ali sto stoji je da stvarno olaksavaju rad. Ima nekih naznaka da je mozda problem u underlying libu, tj PDO stvara problem. Ako netko neki link da mogu procitati vezano za optimalnu praksu sto se tice koristenja baze podataka nije na odmet. Ja sam trazio, nisam nasao. Mozda nisam trazio dovoljno dobro.
Opcenito ja naginjem na laravel. Moj razlog je dokumentacija i jednostavnost. Jako ga je intuitivno koristiti.
Izvrsavao sam malo testiranje. Imamo jedan query koji se sastoji od 6 joinova. Query bi trebao vratiti 15k zapisa. Testirao sam poziv na symfony u kojem je originalno napisan i preveo sam u phalcon. U oba slucaja poziv traje 31-33s. Phalcon ima peak od ~60MB dok ne vrati response. Symfony doctrine pukne na takvom pozivu troseci >200MB dozvoljene memorije. To je ugrubo testirano. U symfony je cak optimiziran query tako sto su se koristili rezultati u array. U phalconu sam podatke pokupio preko njegovog ORM-a. Sad mene zanima jedna stvar, mozda je ocita ali uvijek sam se ovo pitao. Kada se radi join, baza ce vratiti jedan redak onoliko puta koliko postoji razlicitih redaka u joined tabeli. Ima li neki nacin da se uradi mapiranje, kao sto to radi doctrine, tj. da rezulrate mapira u podnizove bez koristenja velikog broja querija? Sad sam malo rastegao na esej, al evo jedan primjer. Zelim uraditi join tabele user i comment. Ako imam vise usera koji mogu imati vise komentara, kako mogu mapirati listu komentara za jednog usera pod isti kljuc u nizu? Naravno, veza je 1-n.
$query = <<<SQL
SELECT
u.id AS user_id,
c.id AS comment_id,
c.text AS comment_text
FROM user u, comment c
WHERE u.id = c.user_id
SQL;
$queryResult = $db->query($query);
$comments = array();
while ($row = $queryResult->fetch()) {
$comments[$row['user_id']][$row['comment_id']] = $row['comment_text'];
}
Jedan query, jednom prodjes kroz rezultate i imas array sa svim userima i njihovim komentarima. Elem, ako imas pravo puno komentara i jedini mapping koji te zanima je user.id -> comment.user_id mozda ne bi bilo na otpad probat neku od NoSQL baza. Recimo uzmes redis koji je pravo brz, nakrkas komentare u njega i stavis tagove po user.id (relevantno: http://www.rediscookbook.org/implement_tags_and_search_them.html).
ORMovi su korisni za bazicni CRUD (create/read/update/delete) ali cim logika postane zamrsena postanu spori (relacije, SQL izrazi tipa CASE, agregatne funkcije). Svaki ORM kog sam dosad vidio je spor i oslanja se na cinjenicu da ga neces koristit puno (zato sve vece aplikacije imaju bruku cachinga i posebno napisane indexere i sta vec ne).
Slažem se, samo da dodam: za prosječnog programera. Čovjek koji jako dobro razumije kako funkcioniše ORM - u principu a i njegova odabrana biblioteka - može optimizovati svoj kod, zato su sva benchmark poređenja ORMova meni smiješna jer je to u suštini takmičenje ko bolje poznaje svoj ORM. Naravno tu se postavlja pitanje u kojem trenutku je jednostavnije sve skupa odraditi na neki drugi način.
Meni je samo ova rečenica zapala za oko. Zašto moraš vratiti 15k zapisa? Da li prikazuješ sve zapise odjednom, možeš li recimo vraćati po blokove po 100 rezultata?
Zamislite da grep tako radi i prvo čitavu datoteku učita u memoriju, pa onda traži neki tekst. Koliko ja znam, grep radi na datotekama N puta većim od RAM-a, zar ne?
Ako hoćeš biti fancy sa upitima, onda možda može nešto ovako (Common Table Expressions, CTE):
Meni je samo ova rečenica zapala za oko. Zašto moraš vratiti 15k zapisa? Da li prikazuješ sve zapise odjednom, možeš li recimo vraćati po blokove po 100 rezultata?
Zamislite da grep tako radi i prvo čitavu datoteku učita u memoriju, pa onda traži neki tekst. Koliko ja znam, grep radi na datotekama N puta većim od RAM-a, zar ne?
Ako hoćeš biti fancy sa upitima, onda možda može nešto ovako (Common Table Expressions, CTE):
Slažem se, samo da dodam: za prosječnog programera. Čovjek koji jako dobro razumije kako funkcioniše ORM - u principu a i njegova odabrana biblioteka - može optimizovati svoj kod, zato su sva benchmark poređenja ORMova meni smiješna jer je to u suštini takmičenje ko bolje poznaje svoj ORM. Naravno tu se postavlja pitanje u kojem trenutku je jednostavnije sve skupa odraditi na neki drugi način.[/quote]
Mislim da je tu vise pitanje optimizacije onog ispod haube (konkretno baze). U biti, ako znas pisat efektivan SQL mozes naucit kako ga replicirat koristeci recimo Doctrineov DQL al opet nekako dodjes na optimizovanje SQLa samo sto sad imas jedan debeli layer izmedju, mada vecina ORMova dolazi sa nekim upakovanim query builderom (doctrine, laravel, etc). To na stranu, ORMovi imaju zgodnih zezancija, npr. doctrine moze da verzionise database schemu i lako je napravit funkcionalan model od nule sto je IMHO korisno.
