Temat: Jaki micro framework?

Witam!
Odnośnie czytam dużo o czym takim jak micro framework. Podobno jest to nowocześniejsze podejście, a do tego w miarę szybkie i małe. Czy możecie coś polecić? Może być polskie, ale nie musi. Musi mieć dobrą specyfikację i być zgodny z obecnymi standardami.
Widziałem już Silex, Slim, itd. Ale nie analizowałem dokładnie. Widzę, że wyrosło tego sporo, więc najpierw wolę spytać Was o Wasze doświadczenie w tym temacie.
Jeśli chodzi o "normalne" frameworki, to w paru już pracowałem. Nie będę podawał ich nazw, bo chcę w ogóle zorientować się czy warto zająć się tym po nowemu.

Temat: Jaki micro framework?

Micro frameworki są spoko w pewnych specyficznych zastosowaniach, np.: jakieś restowe API, prosta wizytówka z backendem lub jakieś inne małe, proste rzeczy. Do większych projektów odradzam, bo mają spore braki które trzeba by uzupełniać własnym lub zewnętrznym kodem.

Są one nowym, elastycznym podejściem, ale nie jest to coś, co zastąpi obecne pełne frameworki. Dobrze jednak znać z jeden na wypadek gdy trzeba coś prostego szybko zakodować.

Sam miałem styczność ze Slimem i Silexem. Slim wg. mnie jest prostszy, jest zamkniętą całością, całkiem kompletną. Silex korzysta z bundli Symfony i łatwo może być o nie rozbudowany. Jeśli potrzebujesz czegoś rozszerzalnego bierz się za Silexa, jeśli coś prostszego, z dobrą dokumentacją to Slim będzie odpowiedni. Oba są najpopularniejsze w swojej kategorii i posiadają spory fragment rynku micro.

Poza tym jak ten tym frameworków ci się nie przyda, to dużo czasu nie stracisz na naukę, bo przez prostotę można je ogarnąć w jeden dzień.

Temat: Jaki micro framework?

Ja osobiście przy kilku projektach używałem FatFree (http://fatfreeframework.com)
Prosty, przyjemny do nauki. Osobiście używałem do restowego API - nie mam mu nic do zarzucenia.

Polecam z czystym sumieniem.

Temat: Jaki micro framework?

Jak zwykle polecam Phalcon - cały FW to jeden plik dll/so. Ma gotowe klasy do realizacji mikroframeworka, co czyni tworzenie np. prostych aplikacji REST bardzo szybkim.Ten post został edytowany przez Autora dnia 16.06.15 o godzinie 13:03

Temat: Jaki micro framework?

Zdecydowanie Silex. Z powodów o których wspomniał Przemysław Mierkowski. Wykonywałem na nim różne projekty. Czasem się trafiło że komuś nagle potrzebny był porządny system uprawnień, rozbudowana konfiguracja, coś dobrego do logowania, jakiś system szablonów bo widoki zrobiły się skomplikowane itp.
Chodzi o sytuacje gdzie malutki projekcik stał się troszkę większy.

Zamiast się męczyć z prostymi microframeworkami albo przerzucać wszystko do kombajnu (full stack), dorzucasz sobie moduły z Symfony i śmiga jak marzenie nadal zachowując swoją wydajność.
Wg mnie świetny kompromis pomiędzy wydajnością a możliwościami.

A jeżeli interesuje Cie coś spoza PHP to jest jeszcze Express. Rzuć sobie okiem na MEAN stack (Mongodb, Express, Angular, Node).

No i jest jeszcze Phalcon o którym ciągle powtarza Tomasz :-) Jeżeli lubisz ciekawostki i masz możliwość instalacji rozszerzeń do PHP oraz pewność że ten projekt nie wyląduje na tanim hostingu dzielonym to owszem - jest taka opcja.

Temat: Jaki micro framework?

Dzięki za wypowiedzi :)

Temat: Jaki micro framework?

Dariusz P.:

[...]

No i jest jeszcze Phalcon o którym ciągle powtarza Tomasz :-) Jeżeli lubisz ciekawostki i masz możliwość instalacji rozszerzeń do PHP oraz pewność że ten projekt nie wyląduje na tanim hostingu dzielonym to owszem - jest taka opcja.

Jest właściwie w dużym stopniu na odwrót, oto dlaczego:

I) Hosting współdzielony a Phalcon vs Symfony 2 i inne FW

Coraz więcej hostingów współdzielonych ma zainstalowanego phalcona jako rozszerzenie - co zwalnia użytkownika z potrzeby instalacji tego FW.

Phalcon jest wręcz idealny do współdzielonego bo siedzi sobie jako moduł i wszyscy na danej maszynie wspólnie z tego modułu korzystają - zużycie pamięci na serwerze jest minimalne.

Jest to duża korzyść w porównaniu z sytuacją kiedy np. na 10 kontach na jednym serwerze każdy ma osobno zainstalowany jakiś tradycyjny framework - np. Symfony 2. To oznacza, że do pamięci jest załadowanych o wiele więcej plików przy korzystaniu np. z OPCache, sytuacja jest jeszcze gorsza na niekorzyść Symfony 2 i innych jeżeli tego cache brak.

II) Potrzeba lepszego hostingu niż współdzielony

Jak już wyżej napisałem - coraz więcej hostingów oferuje phalcona, potrzeba więc posiadania VPS-a / dedyka dla Phalcona wcale nie jest taka duża, można bez.

Jak to się ma z Symfony? Jeżeli używamy go jako microframeworka (Silex) to jeszcze od biedy pójdzie na współdzielonym.

Jeżeli jednak używamy edycji standardowej (czy chociażby Doctrine) to oznacza ponad 50 tys. plików php, tego żaden hosting współdzielony nie uciągnie - bardzo szybko zostaną osiągnięte limity a user wyproszony z serwera - i trzeba sobie kupić VPS/Dedyka.

Z tego wynika, że Phalcon jak najbardziej nadaje się na hosting współdzielony i to o wiele bardziej niż Symfony.

:=]Ten post został edytowany przez Autora dnia 22.06.15 o godzinie 15:05

Temat: Jaki micro framework?

Tomasz Z.:
Jeżeli jednak używamy edycji standardowej (czy chociażby Doctrine) to oznacza ponad 50 tys. plików php, tego żaden hosting współdzielony nie uciągnie

Wyjaśnij mi coś bo czegoś tu nie rozumiem. Kopiuję sobie przez taką FileZillę na FTP aplikację webową w takim Symfony, czy jakimkolwiek innym frameworku opartym o PHP i ona sobie zaczyna funkcjonować na tym serwerze. I te 50K różnych plików PHP zostało tam wysłane. Uruchamiam dla przykładu taką stronę startową jakiegoś tam mikro serwisu. Ile z tych plików PHP będzie w ogóle w takim Symfony użyte tylko po to żeby wygenerować tą stronę startową w odniesieniu do liczby wszystkich wysłanych plików PHP? Konkretniej chodzi mi o tworzenie i kasowanie odpowiednich obiektów, wszystkich zmiennych za każdym requestem i wpływ czegoś takiego na wydajność.

Temat: Jaki micro framework?

Tomasz Z.:
Jest właściwie w dużym stopniu na odwrót, oto dlaczego:

I) Hosting współdzielony a Phalcon vs Symfony 2 i inne FW

Coraz więcej hostingów współdzielonych ma zainstalowanego phalcona jako rozszerzenie - co zwalnia użytkownika z potrzeby instalacji tego FW.

Symfony zadziała Ci w zasadzie wszędzie bo to czyste PHP. "Coraz więcej hostingów" to nadal nie "każdy hosting".

Phalcon jest wręcz idealny do współdzielonego bo siedzi sobie jako moduł i wszyscy na danej maszynie wspólnie z tego modułu korzystają - zużycie pamięci na serwerze jest minimalne.

I przychodzi zaktualizować jeden serwis. Albo postawić go na nowszej wersji phalcona. Ups? Współdzielenie to wcale nie zaleta...

Jest to duża korzyść w porównaniu z sytuacją kiedy np. na 10 kontach na jednym serwerze każdy ma osobno zainstalowany jakiś tradycyjny framework - np. Symfony 2. To oznacza, że do pamięci jest załadowanych o wiele więcej plików przy korzystaniu np. z OPCache, sytuacja jest jeszcze gorsza na niekorzyść Symfony 2 i innych jeżeli tego cache brak.

Owszem ale wolę to niż sytuacje opisane wcześniej.

Jak to się ma z Symfony? Jeżeli używamy go jako microframeworka (Silex) to jeszcze od biedy pójdzie na współdzielonym.

Nie od biedy tylko śmiga jak marzenie. I w zasadzie na każdym czego nie można powiedzieć o Twoim phalconie. Wręcz rzeknę że "od biedy można znaleźć hosting z phalconem"...

Jeżeli jednak używamy edycji standardowej (czy chociażby Doctrine) to oznacza ponad 50 tys. plików php, tego żaden hosting współdzielony nie uciągnie - bardzo szybko zostaną osiągnięte limity a user wyproszony z serwera - i trzeba sobie kupić VPS/Dedyka.

Może być nawet 1000000 plików i nie ma to znaczenia. Od tego jest autoloader i classmap żeby ładować to co trzeba. Poza tym wyciągnąłeś sobie "50 000" z tyłka i tak rzucasz na lewo i prawo. Twoje 50 000 plików to tak naprawdę około 350. Uwielbiam kiedy ludzie wymyślają własne fakty z kosmosu żeby dać sobie wymyślony argument do ręki.

Z tego wynika, że Phalcon jak najbardziej nadaje się na hosting współdzielony i to o wiele bardziej niż Symfony.

:=]

Mhm... jeżeli jest zainstalowany, jeżeli jest w odpowiedniej wersji, jeżeli nie ma potrzebny mieć innych wersji ani nie ma się starszych projektów. Jeżeli nie będzie go trzeba aktualizować do ważniejszej wersji itp...
Wybacz ale prawda jest taka że Phalcon na współdzielonym hostingu to zwykła pomyłka. Już sam fakt że musiałby być dzielony pomiędzy projekty wyklucza takie rozwiązanie.

Temat: Jaki micro framework?

Dariusz R. i Dariusz P.:

Tutaj chodzi głównie o pamięć serwera współdzielonego.

Na takim serwerze jeżeli masz powiedzmy upchaną setkę klientów, i przechowujesz skompilowane pliki PHP w pamięci (OPCache), to liczba plików ma ogromne znaczenie.

Owszem przy jednym requeście użyjesz powiedzmy 50 plików, przy innym 100, a po wejściu do panelu adm. kolejne - a jeżeli w użyciu jest takie doctrine to zaczyna się to liczyć w tysiącach plików. To wszystko siedzi w pamięci (do czasu wyczyszczenia przez algorytmy cache / LRU: co kosztuje moc procesora)

To ogromnie zżera pamięć sewera współdzielonego w porównaniu do biblioteki/modułu z którego wspólnie wszyscy na raz korzystają. I właśnie m.in. dlatego na tanim współdzielonym hostingu często pojawiają się różne "zwiechy" i problemy z wydajnością.

Wtedy okazuje się, że jednak trzeba kupić lepszy współdzielony albo przejść na VPS/dedyka. Gdybym oferował hosting współdzielony to wręcz zachęcałbym klientów do korzystania z takich rozwiązań jak phalcon.

Oczywiście jak masz aplikacyjkę która notuje 100 odsłon dziennie, i ledwo korzysta z bazy, to nie ma większego znaczenia.

Ja mówię o systemach/stronach bardziej rozbudowanych i uważam, że taki system ma większe szanse pracować w miarę normalnie na współdzielonym hostingu korzystając z phalcona niż z jakiejś kobyły z tysiącami plików PHP.

Oczywiście na współdzielonym hostingu tylko część zależy od nas, a reszta od tego co robią inni klienci na tej maszynie.

Ja już teraz nawet VPSów nie kupuje tylko dedyki, już miałem taką sytuację ostatnio, że teoretycznie silny VPS co chwilę miał spadki wydajności szczególnie na I/O.

Ktoś inny na tej samej fizycznej maszynie tak "zarzynał" swój VPS, że zarzynał przy okazji całe I/O które jest wspólne dla fizycznego serwera i nie da się go tak łatwo podzielić jak mocy procesora.

Po kupnie dedyka który parametrami odpowiadał VPSowi wszystkie problemy zniknęły.

Tak więc podsumowując: wszelkie dzielenie z kimkolwiek maszyny czy to na hostingu współdzielonym czy VPS to tak naprawdę amatorszczyzna jeżeli robi się coś poważniejszego.Ten post został edytowany przez Autora dnia 24.06.15 o godzinie 16:57

Temat: Jaki micro framework?

Tomasz Z.:
Dariusz R. i Dariusz P.:

Tutaj chodzi głównie o pamięć serwera współdzielonego.

Na takim serwerze jeżeli masz powiedzmy upchaną setkę klientów, i przechowujesz skompilowane pliki PHP w pamięci (OPCache), to liczba plików ma ogromne znaczenie.

Owszem przy jednym requeście użyjesz powiedzmy 50 plików, przy innym 100, a po wejściu do panelu adm. kolejne - a jeżeli w użyciu jest takie doctrine to zaczyna się to liczyć w tysiącach plików. To wszystko siedzi w pamięci (do czasu wyczyszczenia przez algorytmy cache / LRU: co kosztuje moc procesora)

Znowu wyciągasz liczby z tyłka. Tysiące? Taka sugestia - może sprawdź? Poza tym - to jest zmartwienie właściciela hostingu współdzielonego, nie Twoje. Zresztą wszystko o czym mówisz ma mechanizm autoloadingu. Załadowane jest tylko to co jest niezbędne.

To ogromnie zżera pamięć sewera współdzielonego w porównaniu do biblioteki/modułu z którego wspólnie wszyscy na raz korzystają. I właśnie m.in. dlatego na tanim współdzielonym hostingu często pojawiają się różne "zwiechy" i problemy z wydajnością.

Jeżeli się pojawiają to coś jest z hostingiem nie tak.

Wtedy okazuje się, że jednak trzeba kupić lepszy współdzielony albo przejść na VPS/dedyka. Gdybym oferował hosting współdzielony to wręcz zachęcałbym klientów do korzystania z takich rozwiązań jak phalcon.

Tak samo jak niektórzy zachęcają do zbiorowego samobójstwa? Może Ci to wyjaśnię bo Ty chyba nie do końca rozumiesz o czym mówisz. W Twoim wyimaginowanym świecie masz 10 klientów używających phalcona i wszyscy są zadowoleni.
W moim realnym świecie wygląda to tak że masz 10 klientów używających phalcona. Jeden z nich po 1-2 latach postanawia przenieść projekt na nowszą wersję phalcona. I w tym momencie co robisz na takim współdzielonym hostingu? Aktualizujesz wersję?
Nagle 9 klientom coś może przestać działać. Coś się zmieniło w oprogramowaniu. Coś jest nie tak? Wolno Ci tak postąpić?
Pójdźmy w drugą stronę. 9 klientów postanawia sięgnąć po nową wersję. Dziesiąty nie chce bo nie ma takiej potrzeby. Co robisz? Stawiasz mu osobną virtualkę? Wypraszasz?

Właśnie na współdzielonym hostingu Phalcon to będzie pomyłka. Masz za dużo klientów którzy aktualizują swoje witryny kiedy chcą i na jaką wersję chcą. Jeżeli masz jedną współdzieloną bibliotekę w czymś co jest regularnie aktualizowane to masz problem a nie rozwiązanie.

Oczywiście jak masz aplikacyjkę która notuje 100 odsłon dziennie, i ledwo korzysta z bazy, to nie ma większego znaczenia.

Ja mówię o systemach/stronach bardziej rozbudowanych i uważam, że taki system ma większe szanse pracować w miarę normalnie na współdzielonym hostingu korzystając z phalcona niż z jakiejś kobyły z tysiącami plików PHP.

Albo nie będą działać w ogóle - patrz wyżej.

Oczywiście na współdzielonym hostingu tylko część zależy od nas, a reszta od tego co robią inni klienci na tej maszynie.

Ja już teraz nawet VPSów nie kupuje tylko dedyki, już miałem taką sytuację ostatnio, że teoretycznie silny VPS co chwilę miał spadki wydajności szczególnie na I/O.

To nie są spadki wydajności. To naturalna kolej rzeczy. Operacje I/O na plikach są blokujące. Tzw 2 procesy nie mogą modyfikować jednego pliku jednocześnie. Takie operacje są odpowiednio kolejkowane. Dodatkowo żeby było zabawniej operacje na plikach do najszybszych nie należą. Dlatego stosuje się ram-dyski. Dlatego stosuje się redisa itp. By ograniczyć ilość takich operacji.

Ktoś inny na tej samej fizycznej maszynie tak "zarzynał" swój VPS, że zarzynał przy okazji całe I/O które jest wspólne dla fizycznego serwera i nie da się go tak łatwo podzielić jak mocy procesora.

Po kupnie dedyka który parametrami odpowiadał VPSowi wszystkie problemy zniknęły.

Tak więc podsumowując: wszelkie dzielenie z kimkolwiek maszyny czy to na hostingu współdzielonym czy VPS to tak naprawdę amatorszczyzna jeżeli robi się coś poważniejszego.

To się nijak ma do tematu.

Temat: Jaki micro framework?

Dariusz P.:
W moim realnym świecie wygląda to tak że masz 10 klientów używających phalcona. Jeden z nich po 1-2 latach postanawia przenieść projekt na nowszą wersję phalcona. I w tym momencie co robisz na takim współdzielonym hostingu? Aktualizujesz wersję?
Nagle 9 klientom coś może przestać działać. Coś się zmieniło w oprogramowaniu. Coś jest nie tak?

To w takim razie przed twórcami Phalcona niełatwe zadanie, bowiem każda nowa wersja musi być przy tym założeniu całkowicie kompatybilna wstecz (a to jest chyba celem twórców Phalcona), musi również działać niemal całkowicie bezbłędnie i to w każdej wersji.

Ale podobnie można by podchodzić do użytej na współdzielonym hostingu wersji PHP, choć może być wybór między określonymi wersjami. Zastanawiam się też czy nie istnieje możliwość wyboru między wersjami zainstalowanego Phalcona i przełączania się między nimi. Chociaż przy idealnym założeniu 100% kompatybilności wstecz i bezbłędnej pracy FW można by w zasadzie wybrać wersję najnowszą i nie ma problemu. Tylko że to pewnie piękne ideały.

Temat: Jaki micro framework?

Dariusz R.:

Dariusz P.:
W moim realnym świecie wygląda to tak że masz 10 klientów używających phalcona. Jeden z nich po 1-2 latach postanawia przenieść projekt na nowszą wersję phalcona. I w tym momencie co robisz na takim współdzielonym hostingu? Aktualizujesz wersję?
Nagle 9 klientom coś może przestać działać. Coś się zmieniło w oprogramowaniu. Coś jest nie tak?

To w takim razie przed twórcami Phalcona niełatwe zadanie, bowiem każda nowa wersja musi być przy tym założeniu całkowicie kompatybilna wstecz (a to jest chyba celem twórców Phalcona), musi również działać niemal całkowicie bezbłędnie i to w każdej wersji.

Albo zwyczajnie nie należy go używać na współdzielonym hostingu a przy własnych projektach każdy powinien mieć własną wirtualkę.
Kompatybilność wstecz jak najbardziej ale raczej nie jest to framework zrobiony perfekcyjnie od początku do końca. Co za tym idzie czasem coś stanie się przestarzałe (depracated) i gdzieś w przyszłości zostanie usunięte. Z czasem zmiany dojdą do takiego stanu albo przyjdzie tyle nowych lepszych pomysłów że pojawi się "duża" wersja itp.

Ale podobnie można by podchodzić do użytej na współdzielonym hostingu wersji PHP, choć może być wybór między określonymi wersjami. Zastanawiam się też czy nie istnieje możliwość wyboru między wersjami zainstalowanego Phalcona i przełączania się między nimi. Chociaż przy idealnym założeniu 100% kompatybilności wstecz i bezbłędnej pracy FW można by w zasadzie wybrać wersję najnowszą i nie ma problemu. Tylko że to pewnie piękne ideały.

Idealnie tak jak jeden hosting mi znajomy który pozwalał na tworzenie stron, każda dostawała dedykowany php.ini i mogłeś dorzucać własne rozszerzenia. Kompilujesz albo wrzucasz gotowy plik i dodajesz odpowiednie wpisy. Wtedy zrzucasz z siebie konieczność instalacji/aktualizacji phalcona zrzucając to na użytkownika hostingu. Wtedy ma to jakąś szansę działać.

Temat: Jaki micro framework?

Dariusz P. - trochę może zluzuj orzecha z tekstami typu "z tyłka" etc., dyskutujemy kulturalnie czy robimy tutaj wykop.pl?

Każda wersja phalcona jest kompatybilna wstecz w ramach dużej wersji, 2.0.1 jest kompatybilne z 2.0.3, i będzie kompatybilne np. z 2.5.5. Więc to pisanie o problemach przy zmianach wersji, czy absurdalne porównanie do samobójstwa nie ma racji bytu.

Każdy kto robi oprogramowanie i nie zachowuje kompatybilności wstecz w ramach dużej wersji, dla mnie jest po prostu amatorem.

Piszesz:

"Zresztą wszystko o czym mówisz ma mechanizm autoloadingu. Załadowane jest tylko to co jest niezbędne."

I co z tego? To co było załadowane wcześniej w innym requeście dalej siedzi w pamięci jeżeli jest używany np. OPCache, często każdy request to inny zestaw plików - przynajmniej częściowo, i po 1000 requestów masz w pamięci tysiące plików php na jednego klienta hostingu współdzielonego. Jeżeli OPCache nie jest używany, to pamięć jest mniej obciążona/używana ale zajeżdżany procesor. Coś z czym przy użyciu Phalcona nie ma problemu.

Piszesz:

"Poza tym - to jest zmartwienie właściciela hostingu współdzielonego, nie Twoje."

Rozumiem, że jak strona pada z powodu problemów z współdzielonym hostingiem, to odsyłasz swojego klienta do firmy hostingowej i niech on sobie z nimi rozmawia, bo to nie Twój problem? Świetne podejście, szczególnie kiedy klient nie ma pojęcie o technicznych sprawach.

Ewentualnie inaczej - nie zrzucasz tego na klienta ale żądasz od firmy hostingowej, aby sajt na symfony2+doctrine chodził płynnie na tanim hostingu współdzielonym (50-200 zł za rok)? Pomarzyć zawsze można.

Ja już nie mam zamiaru się produkować w tym wątku - napisałem i wyjaśniłem już najważniejsze aspekty techniczne związane z porównaniem Phalcon vs czysty PHP. Każdy ma swój rozum i niech decyduje :)Ten post został edytowany przez Autora dnia 25.06.15 o godzinie 22:22

Temat: Jaki micro framework?

OK, w sumie każdy będzie robił jak uważa, a jak nie będzie wiedział to ma tu argumenty za i przeciw :)

Mnie interesuje jeszcze jedno czego nie mogę znaleźć. Porównanie wydajności między Symfony2, Silex i powiedzmy CodeIgniter, Yii2. Może ktoś z Was wie gdzie takie coś znajdę?
W zasadzie funkcjonalność S2 mnie przekonała. Odpycha mnie jeszcze ta "słynna" wydajność takiej strony. I nie do końca chodzi mi o pojedynczą stronę. Szukam czegoś do napisania oprogramowania, które w miarę szybko będę mógł postawić na każdym serwerze dostarczonym przez klienta (obojętnie czy to hosting współdzielony, czy dedyk).

Temat: Jaki micro framework?

http://systemsarchitect.net/performance-benchmark-of-p...

Phalcon wygrywa :-) Zaraz po nim Slim, dalej Kohana a Symfony czy Zend gdzieś na końcu.Ten post został edytowany przez Autora dnia 26.06.15 o godzinie 06:22

Temat: Jaki micro framework?

Jarosław O.:
W zasadzie funkcjonalność S2 mnie przekonała. Odpycha mnie jeszcze ta "słynna" wydajność takiej strony. I nie do końca chodzi mi o pojedynczą stronę.

Nie wiem czy to jest akurat (przynajmniej na dedyku) powód do tego żeby kierować się taką wydajnością, bo jakby nie było zawsze wąskim gardłem będzie sama baza danych a sprzęt jest dzisiaj tak wydajny, że zastanawiam się ile tu tak naprawdę w takim przypadku można ugrać?

Szukam czegoś do napisania oprogramowania, które w miarę szybko będę mógł postawić na każdym serwerze dostarczonym przez klienta (obojętnie czy to hosting współdzielony, czy dedyk).

Te hostingi współdzielone to są chyba po to żeby na nich stawiać dużą ilość stronek dla klientów którzy mają pewnie ograniczony budżet, jako że taki hosting jest tani. Ja używałem Kohana (jeden z tych szybszych), bo gotowce takie ja Wordpress czy Joomla całkowicie odpadają w co niektórych zastosowaniach. I prawdę mówiąc mam gdzieś to że ten FW jest niszowy bo jak dla mnie jest bardzo fajny i ma bardzo ciekawą architekturę.

Oczywiście do takich operacji jak mailing trzeba pobrać np. Swiftmailer, bo w standardzie tego nie ma, tak samo jak HTMLPurifier, celem zabezpieczenia przed atakami XSS. Ogólnie masz do wyboru, do koloru.Ten post został edytowany przez Autora dnia 26.06.15 o godzinie 06:55

Temat: Jaki micro framework?

Tomasz Z.:
Dariusz P. - trochę może zluzuj orzecha z tekstami typu "z tyłka" etc., dyskutujemy kulturalnie czy robimy tutaj wykop.pl?

Więc zacznij proszę używać argumentów zamiast wymyślać własne prawdy dla poparcia tego co mówisz. Argument wyjęty z tyłka to argument reprezentujący właśnie to co wyjąłeś. Niczym nie poparte bzdury.

Każda wersja phalcona jest kompatybilna wstecz w ramach dużej wersji, 2.0.1 jest kompatybilne z 2.0.3, i będzie kompatybilne np. z 2.5.5. Więc to pisanie o problemach przy zmianach wersji, czy absurdalne porównanie do samobójstwa nie ma racji bytu.

Może wyjaśnię Ci jak wygląda taki 3-cyfrowy system wersjonowania.
+0.0.1 - wszelakiej maści poprawki, czasem przynoszące jakąś nowość. Głównie małe rzeczy.
+0.1.0 - większy pakiet poprawek, nowości itp. Ogólnie poważniejsze zmiany.
+1.0.0 - duże zmiany, najczęściej zrywające z wsteczną kompatybilnością.
Więc nie musisz mi wyjaśniać jak działa wersjonowanie. Mam nadzieje że teraz i Ty wiesz. Problem pojawi się właśnie wtedy kiedy będziesz miał największe zmiany (+1.0.0).
Dodatkowo często jest że twórcy frameworków usuwają coś/zmieniają w ramach średnich zmian (+0.1.0) z uwagi na różnego rodzaju konflikty albo nieporozumienia.
Dodatkowo co raczyłeś pominąć, mówiłem o problemie zmiany wersji w środowisku gdzie taka biblioteka jest dzielona pomiędzy projektami. Aktualizacja w ramach jednego projektu to nie jest problem.

Każdy kto robi oprogramowanie i nie zachowuje kompatybilności wstecz w ramach dużej wersji, dla mnie jest po prostu amatorem.

Więc rynek jest pełen amatorów drogi profesjonalisto. Bo jeszcze nie widziałem oprogramowania które na jakimś etapie nie sprząta za sobą ze starych rozwiązań i chybionych pomysłów. Spróbuj sobie odpalić coś napisanego w PHP 4 z użyciem PHP 5 dla przykładu. Taka próba nawet jeżeli się powiedzie, skończy się całą masą ostrzeżeń, błędów, komunikatów o przestarzałych rozwiązaniach itp itd etc.

Piszesz:

"Zresztą wszystko o czym mówisz ma mechanizm autoloadingu. Załadowane jest tylko to co jest niezbędne."

I co z tego? To co było załadowane wcześniej w innym requeście dalej siedzi w pamięci jeżeli jest używany np. OPCache, często każdy request to inny zestaw plików - przynajmniej częściowo, i po 1000 requestów masz w pamięci tysiące plików php na jednego klienta hostingu współdzielonego. Jeżeli OPCache nie jest używany, to pamięć jest mniej obciążona/używana ale zajeżdżany procesor. Coś z czym przy użyciu Phalcona nie ma problemu.

Ale tak samo ma phalcon. Jak to ładnie mówisz - to rozszerzenie musi zostać załadowane do pamięci. I ładowane jest CAŁE. Niezależnie od tego co aktualnie potrzebujesz. Poza tym myślisz że opcache nie ma zastosowania w phalconie? Ma. Bo pomoże również zwiększyć wydajność phalcona. W końcu wszystko oprócz core musisz normalnie napisać w PHP.

"Poza tym - to jest zmartwienie właściciela hostingu współdzielonego, nie Twoje."

Rozumiem, że jak strona pada z powodu problemów z współdzielonym hostingiem, to odsyłasz swojego klienta do firmy hostingowej i niech on sobie z nimi rozmawia, bo to nie Twój problem? Świetne podejście, szczególnie kiedy klient nie ma pojęcie o technicznych sprawach.

Jeżeli hosting ma problemy wydajnościowe to jest problem hostingu. Jeżeli powodem jest Twoja nieoptymalna aplikacja to jest to Twój problem. Proste jak drut. Zresztą rozwiązania pisze się pod aktualną sytuację a nie stosuje jeden wielki złoty środek. Kiepski hosting? Użyję slima. Zależy mi na aplikacji czasu rzeczywistego (może nie dosłownie ale wiesz o co chodzi), zrobię ją w Node. Chcę zaoszczędzić czas na developerce a hosting ma techniczne możliwości? Użyję Symfony 2. Potrzeba coś zrobić szybko, po taniości bez oglądania się na nic tak by dostarczyć wygodny panel administracyjny? Użyje jakiś CMS ala Silverstripe albo inne ustrojstwo. Do wyboru do koloru.

Ewentualnie inaczej - nie zrzucasz tego na klienta ale żądasz od firmy hostingowej, aby sajt na symfony2+doctrine chodził płynnie na tanim hostingu współdzielonym (50-200 zł za rok)? Pomarzyć zawsze można.

O dziwo Symfony jest bardzo wydajne jeżeli odpowiednio przygotowane. Masz tu ciekawy tekst jak to jedną znaną stronę porno postawiono na S2:
http://highscalability.com/blog/2012/4/2/youporn-targe...

200 milionów odwiedzin dziennie? Nie ma problemu...

Ja już nie mam zamiaru się produkować w tym wątku - napisałem i wyjaśniłem już najważniejsze aspekty techniczne związane z porównaniem Phalcon vs czysty PHP. Każdy ma swój rozum i niech decyduje :)

Nom. Pomijasz też jedną ważną kwestię. Błędy we frameworku. Przykładowo Phalcon ma koło 500 otwartych ticketów na Githubie. Zresztą inne frameworki nie są lepsze. Różnica jest taka że w wypadku innych poprawkę mogę zrobić sobie sam, podgrać i zostawić ją tam do czasu aktualizacji frameworka. W wypadku phalcona... no właśnie?

Każdy ma swój rozum. Phalcon ma ten problem że jest zbyt kłopotliwy żeby używać go w poważnych projektach i wymaga za dużo kombinowania żeby nadawał się do prostych rozwiązań. Co właśnie sprawia że nadal pozostaje tylko ciekawostką. Jak rozszerzenie w C do Twiga o którym pisałem.Ten post został edytowany przez Autora dnia 26.06.15 o godzinie 15:13

Temat: Jaki micro framework?

Dariusz R.:

Jarosław O.:
W zasadzie funkcjonalność S2 mnie przekonała. Odpycha mnie jeszcze ta "słynna" wydajność takiej strony. I nie do końca chodzi mi o pojedynczą stronę.

Nie wiem czy to jest akurat (przynajmniej na dedyku) powód do tego żeby kierować się taką wydajnością, bo jakby nie było zawsze wąskim gardłem będzie sama baza danych a sprzęt jest dzisiaj tak wydajny, że zastanawiam się ile tu tak naprawdę w takim przypadku można ugrać?

No to jednak zdecydowałem się poznać lepiej Symfony2. I niemiłe zaskoczenie. Prosta strona ładuje mi się w minimum 1,5s (zdarza się ponad 3). Podobna funkcjonalność na CodeIgniter2 łądowała się w 0,2s. Zaznaczam, że to bez dodatkowego cache'owania, ale i tak wynik mnie poraził...

Temat: Jaki micro framework?

Jarosław O.:
No to jednak zdecydowałem się poznać lepiej Symfony2. I niemiłe zaskoczenie. Prosta strona ładuje mi się w minimum 1,5s (zdarza się ponad 3). Podobna funkcjonalność na CodeIgniter2 łądowała się w 0,2s. Zaznaczam, że to bez dodatkowego cache'owania, ale i tak wynik mnie poraził...

1. Annotacje
To akurat głównie wina debuggera oraz wyłączonego cache. Symfony 2 ma annotacje. Tu masz przykład:
http://symfony.com/doc/current/bundles/SensioFramework...
bloki kodu pozwalające na opisywanie różnych rzeczy w fw. W trybie developerskim annotacje są odczytywane od nowa za każdym razem. To oznacza parsowanie plików projektu i wyciąganie ich z kodu.

2. Szablony
Wszystkie szablony są rekompilowane w podobny sposób. Twig -> PHP.

3. ORM
Podobnie jak poprzednio, masz pliki konfiguracyjne, annotacje itp. Normalnie to wszystko ląduje w cache ale ten jest wyłączony dla trybu dev.

4. Debugger
To jest najwolniejsza kobyła. Daje Ci zrzut WSZYSTKIEGO co się dzieje podczas działania aplikacji. Dostajesz pełny stacktrace, informacje co ile zajęło czasu, jakie zapytania zostały wykonane, jakie są dane przesyłanych formularzy oraz dziesiątki innych rzeczy. Otwórz pasek developerski i zobacz.
Chociażby z powodu tego narzędzia S2 jest jednym z najlepszych frameworków PHP. Mało który ma tak kompleksowe narzędzie przy developerce.

Produkcja będzie miała cache, wyłączony debugger i polecam opcache jako dodatek. I będzie śmigać jak marzenie. Można dodatkowo dokręcić wydajność stosując memcache dla ORM i redis dla sesji. Te 2 ostatnie rzeczy zalecane są w zasadzie w każdym frameworku. Sesje w php by default działają na plikach a to nigdy nie jest szybkie. Znowu ORM może często powtarzać te same zapytania do bazy gdzie dane się nie zmieniają więc warto ograniczać je stosując memcache.

W skrócie - w momencie kiedy zrobisz błąd w aplikacji i rozwiążesz go z użyciem debuggera i świetnie przygotowanych stron błędu - będzie Ci trudno się przesiąść na inne frameworki z powodu braku podobnych narzędzi ;-)Ten post został edytowany przez Autora dnia 28.06.15 o godzinie 02:42