Witam wszystkich, zainteresowałem się frameworkiem Phalcon i chciałbym dowiedzieć się czegoś od Was, może ktoś ma doświadczenie? Jakie są zalety i wady całego rozwiązania, w porównaniu np. do Symfony? Czy ktoś tworzył w nim większy projekt, jak to się sprawdza w praktyce? Czy poza wydajnością oferuje coś więcej?
Znalazłem dużo artykułów w sieci, właściwie wszędzie go chwalą. Lepsze są odgrzewane Symfony i Zend czy jednak warto interesować się wydajnością zanim nie pojawi się php-ng w oficjalnej wersji?

Dla zainteresowanych: Is Phalcon really so good?

Ja bym inaczej zapytał... co ma symfony dobrego? nic? nigdy się nie przekonam do FW.

Symfony jednak ułatwia pracę, pisanie w czystym PHP też ma swoje granice. Zależy od zastosowania, ale jak Phalcon może wyglądać przy dużym projekcie? Mało kto to sprawdzał chyba, Symfony ma większą popularność, taka kobyła bardziej
Dlaczego nigdy się nie przekonasz do FW? Jakie są Twoje argumenty?

Pasja jest moim argumentem. Nie robie tego dla kasy tylko frajdy. A to ze mi jeszcze za to placa pozwala mi to robic w pelnym wymiarze godzin. Dlatego wole rozwiazania w pelni autorskie i zawsze natywne, a widzialem chyba wiekszosc popularnych na polskim rynku frameworkow i tylko fat-free mi przypadl do gustu.. z frontu angular a ostatnio poznaje asm.js. Nie mowie ze FW to zlo... ale troche zabija kreatywnosc i robi z Ciebie maszynke do szybkiego klepania kodu i kasy, bo co ? ulatwic sobie trzeba? wole 20 razy napisac to samo inaczej i rozwinac abstrakcje logicznego myslenia ktora w tym zawodzie jest bardzo wazna. Znam mase programistow ktorzy sa lepsi ode mnie i pisza w FW.. ale jednak przychodzi trudniejszy problem do rozwiazania to maja z tym problem a ja nie mam z tym problemow. To tylko moje osobiste zdanie, nie twierdze ze robicie zle piszac z udzialem jakis tam narzedzi.. ale pamietaj. jak nie potrafisz myslec jak programista to zadne biblioteki nie odwala za Ciebie roboty i nie napisza programu.

tzm tylko po co sobie utrudniać życie skoro można je ułatwić. To tak jakby wulkanizator miał odkręcać opony ręcznie kluczem zamiast tym urządzonkiem automatycznie, bo to robi z niego lenia. Jestem zdania, że trzeba sobie ułatwiać życie ile się da, ale z głową,

tzm, zgadzam się z Tobą, FW uczą lenistwa, ale przyznajmy sobie szczerze, w pracy czas gra rolę, a czas to pieniądz. Niestety bez znajomości frameworka pracę znaleźć trudno, a jak już trzeba jakiś znać to... Symfony. Dlaczego nie dostrzega się takich rozwiązań jak Phalcon? Jakiś czas temu podczas rozmowy zostałem zaskoczony poziomem rekrutera, nie wiedział że taki FW jak Laravel w ogóle istnieje, dla większości ZF1 cały czas na topie i świata poza tym nie widzą. Tutaj sprawdza się Twoja teza, programiści stają się leniwi, po co uczyć się myśleć, po co poznawać nowe rozwiązania, jak stary dobry kotlet, ZF1 robi co trzeba. A performance? A to już drugorzędna sprawa.
No właśnie, a jak tworzysz autorskie rozwiązania (takie w pełni) to używasz bibliotek, ORM i composera, czy ufasz sobie bardziej niż społeczności ?

tzm a ty robisz front czy back? Angular to front prawda? Dodatkowo zapewne korzystasz z jakiegoś twig czy smarty. Utrudniasz sobie życie Gdy kiedyś zmienisz pracę na porządnie płatną, gdzie czas gra ważną rolę to przeprosisz się z np. symfony. Zalety? Narzucanie pewnych standardów i ułatwienie pracy w psosób o którym nie zdajesz sobie sprawy. Ja np. gdy w pracy pobieram jakiś projekt to nie tracę czasu na wdrażanie się. Dlaczego? Ponieważ wszystkie są napisane w symfony i praktycznie po kilku minutach wiem co gdzie szukać.

Nie zgadzam się, że framework robi z programisty kogoś w stylu głupka. Kiedyś w pewnej książce przeczytałem: "Dobry programista to leniwy programista"


edit:

@modern-web: takie "lenistwo" i zacofanie programisty bardzo często wynika właśnie z pracodawców. Ilu z was ma za szefa programistę? Ja mam takie szczęście, że mam i dlatego poznaje ciągle coś nowego, updatujemy do najnowszych wersji projekty itp. Większość tego szczęścia nie ma.

No to pojechałeś po bandzie . Tylko żebyś mnie nie zrozumiał źle, ale... kiedy ostatnio miałeś okazję zrobić coś więcej niż zrobienie paru zapytań w kontrolerze i odpowiednie przedstawienie ich w widoku? Chodzi mi o to, że odnosisz się do frameworków jako do panaceum na wszystkie problemy. Czym jest FW w najkrótszej definicji wystarczy przetłumaczyć na polski słowo "framework". Daje Ci on pewne ramy projektu. Owszem, z FW masz najczęściej dostępny już jakiś zakres narzędzi, ale pracując przy różnorakich projektach jest to oszczędność na poziomie może kilku procent jak dobrze pójdzie. Pracuję jako programista już od jakiegoś czasu 5 dni w tygodniu z czego:
- 5 dni w tygodniu to praca na frameworkach
- 5 dni w tygodniu to ciągłe poszukiwanie i implementacja nowych rozwiązań

Jeśli chodzi o sam Sf2 to póki co jedyne czego mi brakuje, to jakiegoś porządnego query caching jak np. w Yii, gdzie można sobie ustawić dowolne dependency (cache, query, time, etc...), a poza tym chyba wszystko pasuje. Fakt faktem - Sf2 to jeden z najbardziej rozbudowanych FW i trudniejszych do opanowania (i pewnie dlatego sporo osób go nie lubi ). Z tymi testami prędkości to powinni jakieś szczegóły testów dawać, bo mam wrażenie, że nie odnoszą się zupełnie do realiów. FW w środowisku produkcyjnym działa bardzo szybko.

Jest dużo klepaczy kodu, większość opanuje framework i kopiuje bezmyślnie kontrolery. A serwisy i logika? Upchnąć wszystko w jednej klasie "bo działa". Tak to często wygląda, z zewnątrz wygląda tak samo, bo to back w końcu. Także jakoś kodu zależy od programisty, a nie od tego jakiego narzędzia używa można mieć młotek i nie potrafić wbić gwoździa, takie realia.
Oczywiście, widziałem gdzieś testy Symfony2.5 (bodajże) pod kątem wydajności i radzi sobie całkiem nieźle, biorąc pod uwagę skalę rozwiązania (rozbudowany) i nawet podstawowe cacheowanie to wynik był imponujący. Niestety nie pamiętam linka ale może znajdę to wrzucę
A Phalcon? Brakuje faktycznie informacji o sprzęcie i skali aplikacji ale 2x większe słupki w przypadku RPS jednak nie biorą się z nieba Symfony z pewnością nie grzeszy aż taką wydajnością, tylko jak to wygląda przy tak dużych apkach (jakie można stworzyć w ZF czy SF)... to mnie ciekawi

@forti: wystarczy ogarnięty team leader, czy zespół, szef nie musi siedzieć w samym kodzie. Dzielenie się wiedzą jest podstawą w świecie IT, samemu nie jesteś w stanie wszystkiego ogarnąć i być na bieżąco, życia by nie starczyło

edit:
Znalazłem wspomniany wcześniej link: Handling 1 000 000 000 Billion requests a week with Symfony2

Forti spokojnie, ja nie mowie ze glupkow z kogos robia fw. W ogole ich nie krytykuje, przedstawilem tylko swoj punkt widzenia na sprawe.
Dyskusja o tym jest jak dyskusja o tym czemu blondynki a nie brunetki. Takze odniose sie do tematu glownego jeszcze...


phalcon z tego co czytalem dokumentacje kilka razy i rozwazalem zabawy z nim ma jeden wielki atut. wydajnosc.
przy duzych serwisach odbija sie to bardzo na portfelu inwestora przez co jest bardziej zadowolony i mozna wtedy dostac wiecej siana. jak pozwolisz komus zaoszczedzic powiedzmy 100 tysiecy rocznie to uwierz mi - nie zostanie to bez echa.
czyli skoro frameworki sa do zarabiania kasy wg was... to phalcon i oszczednosci ktore moze przyniesc jest jeszcze lepszy niz symfony wiec nie ma nawet o czym dyskutowac idac waszym tokiem rozumowania.

ja jednak zostane przy fat-free do swoich uzytkow.

Każda opinia jest interesująca nikt nikogo nie ucisza. Tak czy inaczej Twój punkt widzenia jest ciekawy. Również jestem zwolennikiem tworzenia własnego kodu w miarę możliwości, ale też przeciwnikiem wymyślania koła na nowo. Mało jest ludzi, którzy potrafią stworzyć dobry, przetestowany, re-używalny soft, tak o, w pojedynkę. Jeżeli należysz do tej grupy to poważnie podziwiam. Z FW korzystam dla ułatwienia, przyznam bez bicia że trochę z lenistwa ale dobrze jest znać bebechy od wewnątrz, przynajmniej ma się świadomość jak to działa i jak można ew. uprościć coś i zrobić samemu niż implementować obcy kod. Narzucenie struktury i sztywne standardy dają pewne plusy przy dużych aplikacjach, na małych to w zasadzie lepiej zacząć od zera bo jest zwyczajnie szybciej, a i do pewnego momentu jest mniej zabawy

Owszem, wydajność to coś czego inne narzędzia mogą mu zazdrościć. Ale co w przypadku gdy baza jest wąskim gardłem? Przecież soft najczęściej nie stanowi problemu (chyba, że spojrzy się w kod i zarządzi wielki refactor).

@tzm: dbasz jakoś o jakość kodu? trzymasz się standardów, tak że obcy programista szybko ogarnąłby temat? pytam z czystej ciekawości

Wiesz co.. ja mam małe doświadczenie zawodowe.. staram się wyciągać wnioski od kolegów z większym doświadczeniem tylko jeśli przechodzą moją walidację logicznego podejścia do tematu. Przepisywanie funkcji sort to wynajdywanie koła od nowa, tworzenie wzorców projektowych nie, każdy projekt jest inny, a każde sort takie samo. Trzeba znać granice i umiar takiego podejścia.

Pierwsze podejście do jakiejś tam funkcjonalności jest z reguły nie dbałe, chyba że się jakieś proste rzeczy pisze. W miarę jak funkcjonalność zdaje egzamin zawsze przepisuje co pisze na czysto że tak ujmę dbając o standard aczkolwiek wiesz.. co ja tam pisze:P

@Forti jeszcze jedno.... w javascripcie da się pisać aplikacje backendowe nie ustępujące php, słyszałeś? czy tam z tyłu się o tym nie mówi głośno?

W sumie angular jest raczej z tych cięższych frameworków na froncie. Jest w sumie też najmniej "natywny", bo wprowadza własne definicje scope i własny parser wyrażeń.

Wydaje mi się, że bardziej w Twoje gusta trafiłby mithril/mercury/vue jako kompletne FW, react.js jako samo V w MVC, albo intercooler.js jako całkowite minimum na froncie konsumującym RESTa.

@modern-web - patrz Pan, niby proste pytanie o phalcon, a tu zaraz druga strona będzie o ideach i kulcie pisania kodu

Angular to takie symfony w javascript. Jeżeli ci się angular podoba, a symfony czy inne php'owe FW nie, to najwyższy czas zastanowić się, bo rzeczy które piszesz są sprzeczne ze sobą. Angular to jest kobyła jeżeli by zliczyć wszystkie moduły, w porównaniu do innych javascriptowych FW jest duży. Przecież można napisać coś samemu, natywnego, co będzie w pełni autorskie.. Twoim argumentem jest niezdecydowanie i brak doświadczenia, a nie pasja..

Jesteś, niestety, jak ci goście, którzy uważają że przestrzenie nazw to zbędne udziwnienia, które tylko utrudniają im życie, bo muszą się uczyć (szalenie skomplikowanej) nowej rzeczy...

Jeżeli chodzi o temat, to kiedyś miałem chęć użyć tego FW, do projektu znajomego (4kkk req/month), martwiąc się że symfony czy inny FW będzie za ciężki do tego zadania, zwłaszcza że znajomy za dużo kasy na serwer nie miał.. Ale koniec końców użyłem symfony (a raczej jego komponentów tworząc swojego "silexa"), i dzisiaj ten projekt śmiga na serwerze za 600zł rocznie (bez promocji, w promocji zapłacił 300zł) z ponad 60% rezerwą. Konkluzja jest taka że nie wiem czy jest sens stawiać na coś super szybkiego, kiedy pod ręką ma się coś może nie tak równie szybkiego, ale z ogromną bazą bibliotek i super aktywną społecznością. Jeżeli symfony wydaje ci się za duży, czy trudny, to jest jeszcze laravel, który zaczyna mi się podobać (głównie eloquent).

Phalcon jako sam projekt i rozwiązanie jest rewolucyjne pod względem skompilowanego Core. To daje mu przewagę na aplikacjami pisanymi w PHP.
Jednak, samo Core to nie wszystko. Wystarczy 1 programista dupa który wpier... li zapytanie SQL które zarżnie serwis i serwer.

Przy Phalconie nie można zapominać że Tylko Core jest mega szybkie, a już cała aplikacja cały czas musi mielić przez praser PHP. Tak więc im więcej logiki w samym PHP napisane tym wydajność Phalcona będzie malała.

@!*!: Jak to zazwyczaj bywa ale dobrze jest poznać również idee, FW to nie wszystko jak wiadomo, a na pytanie kiedyś pojawi się jakaś odpowiedź trzeba być czujnym!

@by_ikar: Masz rację, grunt to dobrać narzędzie pod wymagania. W podanym wcześniej wpisie wspomniane było wykorzystanie od strony projektowej, i faktycznie support w przypadku Symfony jest zdecydowanie lepszy, pierwszy lepszy programista chyba szybciej ten temat ogarnie. Stąd powiedzenie "Masz problem? Sprawdź czy nie ma na to bundla!" Ale gdyby tak patrzeć na samą wydajność, to otrzymujemy całkiem przyzwoite rezultaty. Gdyby tak połączyć 2 aplikacje, z czego Phalcon byłby odpowiedzialny jedynie za bezpośrednie obsługiwanie requestów w szybki sposób (a cała logika wykonywałaby się na bieżąco, gdzieś głęboko w sieci na sofcie typu Symfony + integracja w jakiś sposób - to tylko zarys, być może nierealny..), do tego szybki nginx i wydajny hardware to mielibyśmy nowej generacji aplikacje W ciągu roku takie rozwiązanie zmniejszyłoby koszty utrzymania o jakieś 30-50%.

Angular jest spoko, podoba mi się. Zobaczymy co będzie z 2 wersją, już scopa nie będzie

@Pyton_000: Ciekaw jestem jak wypadnie w porównaniu z PHP-NG i HHVM, ale wydajnością możemy się jarać, i tak większość z nas wybierze Symfony bo zwyczajnie wygodniej się pisze Dobrze ująłeś kwestie "dobrego" programisty i jego genialnego wkładu w rozwój projektu, tacy też się zdarzają, a FW nie jest debiloodporny

Orientujesz się jaki jest stopniowy spadek wydajności wraz z rozwojem projektu? Mniej więcej taki sam jak w przypadku konkurencji? Czy może dodany kod Phalcona uśmierca ?

I takie "rewolucyjne" rozwiązanie już istnieje i nazywa się node.js. Sam jestem zauroczony tym jak szybko działa node a jak niewiele przy tym wymaga zasobów. Przyzwyczaić się trzeba do kilku rzeczy i można tworzyć równie skomplikowane projekty co w php, aczkolwiek nie koniecznie mniejszym nakładem pracy. http://www.prahladyeri.com/2014/06/php-vs-...eal-statistics/ pozostaje już tylko kwestia do jakiego projektu, bo nie wszędzie ma to sens, użycie zarówno php (np do websoketów..) jak i node (np do jakiejś prostej apki). Tak czy inaczej node mocno zmienił mój sposób myślenia o javascript.

Jasne, w porównaniu do języka nie wspierającego współbieżności, reactor pattern z callbackami jest ciekawy. Jednak też ma swoje wady, a w wypadku dużej aplikacji warunkowe ładowanie modeli robi się zabawą samą w sobie i do tego wymaga dużo uwagi - trzeba uważać na referencje. W modelu CGI (php, standardowe python i ruby ...) wszystko załatwia się jednym exit i już jest się gotowym na następne requesty.

Zgadza się, dlatego od jakiegoś czasu skutecznie wdrążam się, jak i projekt w promisse/deferred aby pozbyć się "choinek" callbacków, i mieć jakiś "synchroniczny" przepływ kodu.

Phalcon ma jedną zasadniczą wadę, nie jest dostępny na każdym serwerze. Gdyby stał się natywną częścią php, a tym samym był dostępny na każdym serwerze to ja przesiadam się tak szybko jak to tylko możliwe.
Oczywiście przy większych projektach można sobie pozwolić na to żeby kupić dedyka i instalować co się, ale przy mniejszych projektach gdzie często klienci mają już jakieś serwery typy "najtańsza oferta z home/nazwy" jest to problem nie do przeskoczenia.

Gdyby chociaż była opcja do wyboru: moduł serwera lub zwykłe plik php, to jasne biere, ale tak... no niestety...


kkk ? według google to "Ku Klux Klan"

W różnych grach mmo (i w sumie nie tylko) przyjęło się coś na zasadzie: 1k = 1000; 100k = 100 tysięcy, 1kk = milion. W sumie za dużo K mi tam wyszło

że 1k to 1000 to się zgodzę
że 100k to 100000 również
ale milion to 1M czyli 1 mega, a nie jeden kilo kilo
Więc 4kkk to 4G czyli 4 giga a nie 4 kilo kilo kilo
oczywiście zdaję sobie sprawę z tego że ludziom bardzo spodobał się ten zapis "kk" ale osobiście strasznie go nie lubię.

tak swoją drogą to jest to równie bezsensowne jak czytanie mocy samochodu jako "kW" zamiast kilo waty

Albo co gorsza Kilo Woltów

@sazian: Oczywiście, globalnie mało gdzie jest dostępny ale... często wystarczy poprosić administratora o support i doinstalowanie wyłącznie dla Twojego konta. Nie spotkałem się jeszcze z odmową, a nawet w kilku firmach zainstalowano je globalnie po mojej interwencji myślę, że to dobra alternatywa dla małych aplikacji, takich na kilka dni roboty, gdzie pisałbyś wszystko od zera. W takiej sytuacji nawet do stronek dla typowego Kowalskiego się nadaje.

@by_ikar: Node jest faktycznie innowacyjny a wyniki benchmarków podbijają całe środowisko php. Niemniej jednak Node to tylko narzędzie, podobnie jak Phalcon, za jednym i drugim stoi jakiś język programowania, a jeżeli już mamy porównywać to PHP ma bardziej przejrzystą (dla większości programistów) idee i składnię, Javascript ma tę wadę, że nie ma dobrej "konkurencji" na rynku przez co jego prototypowe podejście i składnia są obce dla przeciętnego dewelopera, który nie tworzy w nim pełnych aplikacji na co dzień. Ciekawe jak wypadnie Node w porównaniu z innowacyjnym php-ng. Przebić - nie przebije, bo to by wymagało zmiany idei całego php, ale może sporo namieszać

Node nie jest innowacyjny przez swój model współbieżności. Model ten już nawet przeszedł do innych języków (netty /vert.x dla Java), ale nie nadaje się do typowego tworzenia aplikacji. Benchmarki z node.js robią wrażenie tylko przy małych aplikacjach a node się jednak kiepsko skaluje. Wystarczy spojrzeć jak wyglądała sprawa w Pythonie - ani twisted ani tornado się nie przyjęło, a byli długo przed node.js razem ze spektakularnymi sukcesami jak gry mmo z twisted.py na stackless pythonie.

już widzę tą odpowiedź od home "nie, ale za to mamy tanie certyfikaty". A dlaczego uważam że właśnie tak odpowiedzą ? a no dlatego że zawsze tak mi opowiadają :/

Mogłeś pisać, że masz jakieś problemy życiowe, zrobilibyśmy zrzutę na forum, z home można się wyleczyć.

@sazian: rozwaliłeś mnie tym komentarzem, prawdziwy! Ale hosting dla dev jednak przejmuje się takimi duperelami a wcale nie są gorsi, można się dogadać często.

@solificati: Znasz jakiś wydajny język do tworzenia aplikacji webowych, który dobrze się skaluje i nie ma takich problemów?

Platforma .NET

W jakim sensie słabo się skaluje? Jakieś przykłady ?

.NET też ma swoje wady - środowisko bardziej wymagające, generalnie kobyła. Może jakiś bardziej przyziemny przykład ?

O i dobre pytanie, by_ikar! Również jestem ciekaw w jakim sensie kiepsko się skaluje. Jakieś artykuły na potwierdzenie?

tyle lania wody co tu się pojawiło to już dawno nie widziałem ;p

a co do oryginalnego pytania w temacie, to jak ktoś robi aplikacje typu 'Hello World' to powinien wziąć sobie te testy do serca i tworzyć aplikacje webowe w oparciu o Falcon'a.

Do "Hello world" framework potrzebny nie jest, gratulacje dla tych którzy potrzebują
Pisze się w nim przyzwoicie ale chaos widać już po kilku dniach pracy, szkoda myśleć co jest po roku..

Node.js nie idzie dalej ze swoim modelem współbieżności. Zakłada uruchomienie na jednym rdzeniu, co powoduje problemy w wypadku zadań polegających na CPU a nie oczekiwaniu na dysk/sieć. Uruchamianie na kilku rdzeniach nie jest pzyjemne, bo nie ma współdzielenia danych a przekazywanie wiadomości nie jest najwyższych lotów (lepsze jest stosowanie wartości niemodyfikowalnych jak Clojure, wspieranie bogatszych typów danych jak Erlang, albo używanie STM).

Dodatkowo dochodzą wszelkie problemy z pamięcią podczas ładowania modułów. To co w stylu CGI jest załatwiane przez autoloadery i usuwane po requescie, tutaj musi być lepiej zarządzane.

W każdym razie, node.js świetnie się nadaje do aplikacji o prostej logice, gdzie łatwo nam prześledzić drogę requesta i faktycznie jest to proces ograniczony przez I/O. Idealnym przykładem takiej aplikacji jest chat. Ogólnie real-time - gry, boty, edytory z równoczesnymi użytkownikami.

A dlaczego .NET nie jest przyziemny ? Kobyła ? Na jakich podstawach wysuwasz takie stwierdzenia ?
Po przesiadce z PHP na technologie .NETowe poczułem niezłego kopa jeśli chodzi o wydajność aplikacji , nie wspominając już o tym jak przyjemnie się pisze np w C#. Wygoda serwowana przez MS jest na bardzo wysokim poziomie. Postawienie na Azure stronki to kilka klików aby stworzyć stronę i przycisk deploy to Azure w Visualu.

Kobyła ? Jak można robić tego typu porównania ? Czy pisząc w PHP uruchamiasz na raz wszystkie rozwiązania które on oferuje ? - NIE. W przypadku ASP też tego nie robisz więc moim zdaniem to raczej powinno być porównanie możliwości które daje język a nie "kobyła" - "nie kobyła". Ta "kobylastośc" w przypadku ASP.NET to tylko kolejny atut.
Przy tworzeniu większych projektów środowisko .NET jest o wiele bardziej oszczędne niż np PHP (zasobożerność).
Co do małych projektów, masz rację nie opłaca się stawiać tego na .NET... ale tu właśnie odzywa się możliwość łatwego i przyjemnego skalowania aplikacji. W PHP / node to już nie jest takie kolorowe.

Tak więc konkludując, przepraszam za wyrażenie ale Twój komentarz dotyczący technologii MS'u jest trochę "z dupy". Co do wad, też są, jak we wszystkim z czego korzysta człowiek

I tutaj się nie zgodzę, bo node cluster, czy inne pakiety takie jak PM2 są w stanie bez problemu odpalić node w wielu procesach (w ilu chcesz). Współdzielenie danych może się odbywać poprzez np redisa, czy inną bazę danych (widziałem przykłady z mongodb). W przypadku pm2 jest też opcja loadbalancingu. Jeżeli chodzi o problemy z pamięcią, no jak jakiś czas temu przeglądałem jakieś informacje na temat node, trafiłem na prelekcje devów ubera, którzy pierwotnie mieli napisaną apkę w php+mysql: https://www.youtube.com/watch?v=Jups7FveC1E a moje doświadczenia z pamięcią wyglądają tak: https://dl.dropboxusercontent.com/u/3624937...4/pm2.monit.png jest to status dla około 2.5-3k połączeń (120~140 req/s), a sama aplikacja jest czymś w rodzaju monitoringu (zapis każdej wizyty, każdego odświeżenia strony etc). Tak czy inaczej, IMO pamięć w przypadku node to jest najmniejszy problem, bo tego w porównaniu do php zużywa dużo mniej.

Nie myśl że piszę to złośliwie, bo tak nie jest, a fajnie by było mieć opinię od kogoś kto ma większe pojęcie o node odemnie, chyba że się mylę i brałeś udział w jakimś większym projekcie i mógłbyś się podzielić wiedzą/doświadczeniem ?

Sorry za OT, jeżeli ktoś uzna za takowy mój post.

No ale to jest poza platformą. Nie rozwiązuje to problemów bo defacto masz współdzielenie przez kopiowanie i do tego przez inną aplikację, czyli tracisz zasoby i semantykę obiektów. Może się coś zmieniło, ale node cluster nie rozwiązywał problemów z requestami związanymi z cpu. Mając izolowane procesy nie musisz się tym martwić, w wypadku node może to spowolnić rdzeń w ogromnym stopniu.


Nie chodzi o ilość zużywanej pamięci, tylko zarządzanie nią. Oczywiście PHP zużyje więcej, bo więcej do pamięci ładuje. Chodzi o ten moment, w którym masz na tyle skomplikowane modele i kod, który sam ładujesz i zbliżasz się do poziomu PHP a musisz się martwić, bo te modele żyją na serwerze. Po obsłudze requesta musisz zadbać, żeby utworzone obiekty były wolne dla GC. W PHP robisz po prostu exit. Chodzi o komfort pracy.


Brałem udział w projektach, do których nadaje się node, ale go nie wybrano. Ale kilka projektów zostało opartych o node i były omawiane wady i zalety.
Przy wyborze technologii do projektu ważne jest pytanie o język. Jeśli dla kogoś JavaScript jest zaletą, albo najmniejszym złem, to polecam, ale przy odrobinie dowolności są lepsze rozwiazania, zarówno dla lekkich platform real-time, jak i samego Reactor Pattern.

No z tym "walczę" właśnie za pomocą promisse, które przerywa ciąg "then" jeżeli będzie błąd, lub dane których nie chcę. No tak, jest to trudniejsze do osiągnięcia niż w php, ale coś za coś..



W node od jakiegoś czasu jest wbudowany cluster, można napisać jego własną obsługę (która nie jest IMO skomplikowana) lub skorzystać z czegoś gotowego. Niby się traci na tym że jakieś dane współdzielone między procesami są trzymane w czymś pokroju redisa, ale podobnie trzeba robić w php, jak się go stawia za loadbalancerem, więc nie widzę tutaj jakiś różnic.



U mnie jest właśnie tak, że pierwotnie aplikacja została napisana w typowym php stacku (zend+mysql), ale no wydajność niestety strasznie niedomaga, i jak zostanie to w końcu w całości przepisane, to wtedy mogę się podzielić jakimiś swoimi spostrzeżeniami pomiędzy szybkością tworzenia takiej aplikacji, a jej wydajnością. Bo na chwilę obecną już mi się to podoba, i już widać różnicę, pomimo tego że nie działa to jeszcze na produkcji. Ale faktycznie, możesz mieć racje odnośnie tego że w innym przypadku lepiej by wypadł php.

Bardziej chodzi mi o to, że jak przychodzi request to go po kolei analizujesz, ładujesz odpowiednie klasy, by reprezentować rozpakowane dane, może nawet ORMa. Chodzi o to, że jak się skończy request to te wszystkie dane wraz z opakowującymi je obiektami muszą zniknąć z pamięci. Trzeba zadbać, żeby w żadnych obiektach, które istnieją cały czas nie pojawiły się referencje, bo wtedy GC ich nie wyczyści. Trzeba uważać, żeby jakiś singleton nagle nie był obserwatorem ulotnego modelu.


No ja porównywałem bardziej do Javy na netty, czy Erlanga, albo Clojure, też na netty. Względem PHP czy Django/RoR nie ma zbytniej różnicy (Python i Ruby nawet mają GILa, który w ogóle utrudnia sprawy).

Dopóki aplikacja ma mieć nieskomplikowaną, lekką obsługę requestów i zależy Ci na dużej ilości jednoczesnych połączeń to node jest dobrym wyborem, chyba, że chcesz zainwestować w inne języki: Jave albo nawet Erlanga. Po prostu ten model ma swoje ograniczenia.

V8 który jest sercem node.js ma kilku poziomowy GC, jeden jest puszczony w interwale a drugi wywala daną funkcje z pamięci po jej wykonaniu. Czyli twoje obawy że sam musiałbym zadbać o to aby nie było wycieków pamięci (w sensie że zawsze) są niesłuszne. Gdzieś kiedyś nawet widziałem cały artykuł opisujący dokładnie jak działa GC w V8. A jeżeli już jest nawet jakiś wyciek, są odpowiednie od tego pakiety którymi można analizować w czasie rzeczywistym co się dzieje w pamięci.

Nie bardzo też rozumiem co masz na myśli nieskomplikowana aplikacja. IMO paypal czy ebay raczej nie mają "prostych" aplikacji, a z przejścia na node są zadowoleni, więc nie bardzo tutaj widzę sens twierdzenia że tylko dla prostych aplikacji.

Jeśli GC by usuwał obiekty utworzone w funkcji, do których są referencje poza funkcją, po jej zakończeniu to działałby źle. A taki scenariusz ma prawo się pojawić w aplikacji i Ty musisz go obsłużyć.
Dlaczego ma prawo się pojawić? Bo dużo bibliotek przetwarzających dane przechowuje referencje, by niepotrzebnie nie kopiować danych. Czy chociażby ORMy (czy odpowiedniki dla noSQL) muszą trzymać referencje jeśli obsługują na nich zdarzenia w stylu "after_update".
To nie jest nowy problem, ten sam problem mają programiści gier, gdzie aplikacja to jeden wielki event loop i ładowane moduły. Trzeba uważać na alokacje.
Zresztą zobacz sobie właśnie na narzędzia - Joyent, który tworzy platformy głównie pod node.js sam pisze poradniki jak używać dtrace do szukania wycieków pamięci. To jest realny problem.


Bo idea Reactor Pattern zasadza się na jednym fakcie - normalnie zadanie czeka na I/O, więc można w tym czasie wykonywać inne zadanie, które zawiśnie na I/O. W sytuacji gdy więcej czasu zajmuje wykonanie kodu, nie ma czasu na obsługę I/O i zadania czekają coraz dłużej, aż w końcu dojdziemy do wydajności jak w CGI.
Więc wątpię, żeby w kodzie node.js ebaya było dużo zadań polegających na CPU i to dla mnie jest nieskomplikowana aplikacja. Skomplikowane by było na przykład pobieranie kilku megowych JSONów i scalanie ich w określony sposób a'la JOIN w mongo. W node.js musisz wszystkie ciężkie obliczenia pchnąć dalej, a nie zawsze jest to pożądane. Na przykład im więcej obliczasz w bazie danych tym bardziej obniżasz jej możliwości działania wielowątkowego bo blokujesz tabele.

ale temat zboczył ;p

Akurat przesiadam się teraz od pewnego czasu na phalcona i klepie w nim całkiem spory projekcik. Pierwsza rzecz jaka jest mega to jego początkowa konfiguracja, którą piszesz sam ! Sam sobie ustalasz jaką strukturę katalogów przyjmie Twoja apka. Podobnie jest z ładowaniem komponentów, Dependency Injection świetnie odgrywa tutaj swoją rolę. Biorąć pod uwagę chociażby tylko te 2 rzeczy, komfort tworzenia aplikacji pod swoje potrzeby rośnie 100krotnie. Inaczej jest w przypadku gdy musisz ogarnąć czyjś projekt, wtedy każda apka może wyglądać zupełnie inaczej. Ale jak piszesz sam dla siebie to polecam.

Pod względem baz danych, nie mam zastrzeżeń, wszystko śmiga aż miło. To nie żart, że phalcon ma najszybszego ORM'a. Jak ktoś miał doświadczenie z innymi FW to pierwszą rzeczą jaką zauważy to mega wydajność. Wadą na pewno jest mała ilość wbudowanych narzędzi, zwalony wg mnie form biulder, niektóre słabo rozbudowane komponenty, ale w bardzo łatwy sposób możesz rozszerzać sobie dowolne klasy. Dodatkowo problem z composerem - gryza się autoloadery, ale mają ponoć coś z tym zrobić w wersji 2.0.

Na początek polecam naukę na projekcie vokuro https://github.com/phalcon/vokuro

Ogólnie rzecz biorąc, mi przypadł do gustu a wybrałem go głównie ze względu wydajności oraz kompatybilności z najnowszymi wersjami php'a. Nauka jednak nie jest taka łatwa i polecam we wszystkim śledzić dokumentacje aby później czegoś nie przepisywać ; ) Po 2-3 tygodniach idzie ogarnąć - jeśli ktoś tak jak ja przesiada się ze starszych FW.

Większość szkieletów to nakładki na PHP z systemem szablonów. Phalcon do nich należy. Kontener zależności mógłby być wbudowany w PHP tak jak wiele innych wzorców projektowych. Przyjrzyjmy się bliżej kilku komponentom Phalcona:

* Validation - obiektowa nakładka na strlen(), is_numeric(), filter_var(), ===, <, >. Przy okazji ustalamy komunikaty błędów. To ma sens tylko w dużych aplikacjach, gdzie wczytujemy listę walidatorów dla poszczególnych pól bądź dodajemy je w klasach formularzy. Podejście 100% obiektowe z czołgu na muchę. Ułatwi lub utrudni pisanie kodu.
* Session - nakładka na sesje PHP. Dodatkowo ma obsługę innych komponentów i umożliwia izolację sesji.
* Security - nie musicie się przejmować algorytmami szyfrującymi, bo kontrolę nad bezpieczeństwem przejmuje Phalcon. Aby działał getToken() do ochrony przed CSRF, trzeba ręcznie włączyć sesje.
* Image - obiektowa nakładka na GD / ImageMagick.
* Forms - największa bolączka Phalcona, wcale nie ułatwia pracy z formularzami, a jedynie wymaga pisania więcej kodu - można użyć do budowania prostych formularzy i stworzyć szablon uniwersalny.
* MVC - najważniejszy zbiór komponentów Phalcona - czasami trzeba stosować haki, szczególnie gdy przyjdzie pracować z JSON i skomplikowanymi bazami danych. ORM ma duże możliwości, ale powiązania między encjami totalnie skopali. W odpowiedzi dostajemy klucze obce jako ID, datę i czas jako ciąg znaków, a gdy chcemy odwołać się do powiązanych encji, należy odwołać się po jej nazwie lub ustawionym w initialize() aliasie. Gdy dochodzi do konfliktu nazw, Phalcon nie wie, czy wyświetlić ID czy encję. Systemy ORM z wyższej półki same utworzą i zmodyfikują tabele. Phalcon ORM nie. Za to pobierze sobie sam strukturę tabel.

Tyle narzekania. Największą zaletą Phalcona jest wydajność, bo napisano go w C/C++ jako moduł PHP. Nie narzuca układu katalogów. Komponenty można skonfigurować przed wywołaniem Application::handle(). Ciekawe są też mikroaplikacje do wywołań REST.

Odpowiadając na pytanie tytułowe, musisz spróbować sam. Phalcon to młody projekt, a zyskał rzeszę zwolenników. Niestety w biznesie liczy się tylko Symfony i czasami inne FW.

9 grudnia 2015

Podnoszę temat. Na których płatnych polskich hostingach jest obsługa Phalcona? Mam do wykonania projekt na zlecenie. Technologie wybieram sam i najlepszy byłby Phalcon. Nawet jeśli zaangażuję AngularJS, usługi muszą siedzieć po stronie serwera. Symfony to za ciężka kobyła na ten projekt, natomiast nie umiem już pisać strukturalnie.

@up http://symfony.com/blog/new-in-symfony-2-8...-microframework

Co do angularjs to polecam sam napisalem juz 2 aplikacje android/ios/wp8/wp10 za pomoca ionic z czego jednak ma ponad 50k download

Napisalem tez 3 projekty firmowe w tym z czego 1 bardzo rozbudowany tzn. aplikacja robi wiele zadan w tle rownolegle za pomoca gearman sam front-end ma pelno bajerow, teraz przesiadam sie na typescript i poki co bede go uzywal razem z angularem 1.4.x a jak wyjdzie jakas bardziej stabilna wersja branch-u 2.x to przesiade sie calkowicie poki co na produkcje sie nie nadaje bo API sie ciagle zmienia a dokumentacja kuleje.

Mialem tez stycznosc z ReactJS ale to juz inne zastosowania.

Wiesz, jest takie powiedzenie - młody programista chce robić wszystko samemu, a starszy szuka gotowych rozwiązań.

Czytając Twoje pierwsze posty dziwnie przekrzywiała mi się głowa, teraz już wiem dlaczego - ale napisze o tym później. Mówisz, że FW są złe, że lepiej Ci się pisze Twój własny kod. Mówisz też, że gdy Twoi doświadczeni koledzy mają problemy, to jednak jesteś od nich sprytniejszy, bo Ty zawsze masz rozwiązanie na swoje problemy.

A ja Ci teraz zadam pytanie - powiedz mi, czy pracowałeś kiedyś w większym zespole? Mam tutaj na myśli projekt, który ciągnie się przez kilka lat i jest pisany przez kilkunastu-kilkudziesięciu programistów? Powiedz mi jak wyobrażasz sobie kooperację kilkunastu ludzi, którzy pisząc wyznają zasady "dzikiego zachodu", czyli... każdy orze jak może.

Bo ja Ci powiem, że sobie tego nie wyobrażam. Frameworki są po to, aby narzucić jakieś standardy. Frameworki są stworzone do pracy zespołowej. Gdy przykładowo powstaje jakiś projekt, wtedy wybiera się jakiś popularny FW, który znają wszyscy, który ma jakieś ustalone standardy, następnie do tego projektu dochodzi grupa 10 programistów, którzy się w życiu nie widzieli na oczy, jednak każdy wie co gdzie może znaleźć.

Wyobraź sobie grupę 10 programistów, w której każdy robi co chce i rozwiązuje problemy po swojemu. Póki pracujesz SAM, to możesz sobie tworzyć cuda na kiju, sam to tworzyłeś, sam się w tym połapiesz. Gdy ktoś zacznie zabierać się za Twoją rzecz, wtedy będziesz mu tłumaczył długo co jest jak zrobione. Z całego serca nie życzę Ci pracy nad projektami innych ludzi, którzy postanowili nie trzymać się standardów. W swojej karierze widziałem kilka takich projektów, z czego jeden naprawdę OGROMNY.

Ale nie zrozumiesz tego, dopóki nie zdobędziesz doświadczenia. Do pewnych rzeczy trzeba po prostu "dorosnąć" - pamiętam doskonale, gdy na tym forum pojawił się chłopak, który nie potrafił zrozumieć po kiego ch*** są interfejsy. Koledzy próbowali mu to wyjaśnić, ale on nie potrafił tego zrozumieć. Pisał, że ta idea jest dupna. Koledzy się prężyli, niektórzy tak, że prawie bobka zrobili. Ale to nie miało sensu. Jak wytłumaczyć młokosowi na czym polega polimorfizm, skoro on dopiero niedawno skończył pisać "Hello World".

Wydaje mi się, że jak na razie jeszcze żyjesz w słodkim świecie kreatywności i uczenia się (chcesz robić wszystko samemu, aby zrozumieć jak wszystko działa, pisanie rzeczy, które zostały napisane 100 lat temu sprawia Ci przyjemność). Gdy dojdziesz do momentu, że pisanie 10 razy tego samego przestanie Ci sprawiać przyjemność, wtedy będziesz już dochodził do pierwszego stopnia wtajemniczenia. Gdy zamiast pisać i utrzymywać swoje aplikacje zaczniesz szukać gotowych i znanych bibliotek, wtedy będziesz już w drugim stopniu wtajemniczenia. A gdy w końcu zaczniesz pracować w firmie, gdzie będą duże zespoły projektowe, wtedy zobaczysz co oznacza stwierdzenie "współpraca programistów" i prawdopodobnie kiedyś w końcu trafisz na jakiś autorski system, zobaczysz jak kreatywni potrafią być programiści - i wtedy zatęsknisz za standardami, stworzysz sobie w domu ołtarzyk frameworkowy, będziesz wieczorami polował na nietoperze, zabijał je i składał w ofierze... Bogowi Standardów i Frameworków, możliwe, że napiszesz nawet list do SensioLabs z przeprosinami, że w przeszłości wątpiłeś w Symfony i ideę frameworków.

Tego Ci życzę szczerze. ; >

Co do Phalcona - fajny, nawet nieźle rozbudowany, jednak nie jest tak popularny jak Laravel/Symfony/Zend - czyli gorsze wsparcie (biblioteki/społeczności).

Nie do końca tak jest. Oczywiście FW narzucają pewne zasady, jednak zezwalają na dużą elastyczność. Na przykład Phalcon. I tak trzeba poznać standardy stosowane w firmie.

FW powinien upraszczać i przyspieszać tworzenie aplikacji, ale w przypadku Phalcona tego nie zauważam. Może Phalcona 3 będzie się dało używać. Potrzebuję napisać mały projekt w PHP. W podejściu strukturalnym wystarczyłoby kilka plików z niewielką ilością kodu, w czystym OOP nieco więcej, zaś zaprzęgnięcie Phalcona to jak zapolować z czołgu na muchę. Po kolei:

1. Moduł Forms to najsłabsze ogniwo. Bezużyteczny bez napisania własnych nakładek i szablonów. Nie ma nawet takiej błahostki jak automatyczne generowanie klucza CSRF, a co dopiero generowania <form> i prawidłowej walidacji pól.
2. Kontener zależności wydawał się potęgą Phalcona, ale po dłuższym czasie wychodzą wady takiego rozwiązania. Podoba mi się wiązanie komponentów zastosowane w Springu - wystarczą adnotacje @Component i @Autowired. Używane komponenty dodaję jako pola klasy, IDE mi podpowiada ich metody i wiem, co kryje się pod this.userDAO ($this->userDAO).
3. Brak mechanizmu autoryzacji.
4. System szablonów Volt niewiele różni się od Smarty. Podoba mi się idea tagów w JSP.
5. ORM jest mocno niedopracowany. Zastanawiam się, czy mogli napisać go lepiej.
6. Wszystkie poprzednie uwagi aktualne.
7. User::find() chyba nie do końca zgodne z zasadami OOP (magiczna metoda statyczna)

2. To da się szybko i łatwo napisać w PHP wiec z Phalcon też pewnie podobnie

Ubuntu byłby dobry, gdyby Canonical bardziej o niego dbał. O ile dobrze pamiętam, to Arch linux bardzo ładnie śmigał.

Panie mrc chyba nie tan temat