Pracował ktoś w Spiral Framework https://spiral.dev/? Wygląda na ciekawą konkurencję dla Symfony, ma bardzo podobne developer experience, ma zaimplementowanych sporo rozwiązań z innych języków jak coroutines czy integrację z temporal. Wg ich testów wydajnościowych wypadają dużo lepiej niż Symfony czy Laravel, bo nie musi za każdym requestem budować całej aplikacji do pamięci. Co sądzicie?
Wg ich testów wydajnościowych wypadają dużo lepiej niż Symfony czy Laravel, bo nie musi za każdym requestem budować całej aplikacji do pamięci.
@Jurix: jeśli dla kogoś takie różnice wydajności są istotne, to znaczy że robi coś w dużej skali, a zatem nie użyje PHP tylko języków które do tego się lepiej nadają (np. Rust, albo w ostateczności Go).
@Jurix: mylisz framework z całym stackiem od Spirala. Jak chcesz obsługiwać requesty long running procesem, masz samego RoadRunnera. Sam framework boosta ci nie daje, ale jest napisany z myślą o RR, tj. Z troską o memory leaki, kontrolę stanu aplikacji itp.
U nas na razie wdrażamy RR, potem będziemy testować Cycle ORM zamiast Doctrine, a potem resztę frameworka być może.
Tworzenie nowych frameworków moim zdaniem nie ma już żadnego sensu, bo te 2 zbudowały wokół siebie taki ekosystem i społeczność, że nikt o zdrowych zmysłach z tego nie zrezygnuje
@nowiutki: Octane bazuje zwykle na Roadrunnerze, a Spiral Framework jest tworzony przez tę samą firmę i stworzony z myślą o współpracy z tym narzędziem, no i patrząc na wyniki wydajnościowe - mnie przekonuje. Poza tym, Laravel raczej nie jest pierwszym wyborem do poważnych projektów, mimo ogólnej większej popularności to Symfony jest uważany za lepszy wybór do projektów o dużej skali, a znów Spiral odzwierciedla developer experience Symfony. No ale mówię
@Jurix: Po co skoro 99% czasu apka czeka na bazę danych? Albo działasz na taką skalę że dołożenie więcej maszyn nie wchodzi w grę i musisz optymalizować, ale wtedy wybierasz technologie które są wydajniejsze pod każdym względem od PHP, albo masz 5 requestów na minutę, wydajność nie ma znaczenia i piszesz w czym chcesz, a w razie czego postawisz 3 maszyny zamiast jednej.
@Jurix: bardziej na Swoole, który jest wydajniejszy i daje większe możliwości.
Poza tym, Laravel raczej nie jest pierwszym wyborem do poważnych projektów, mimo ogólnej większej popularności to Symfony jest uważany za lepszy wybór do projektów o dużej skali, a znów Spiral odzwierciedla developer experience Symfony
@Jurix: tutaj nie zamierzam się kłócić bo ja robię tylko małe projekty, ale wydaje mi się, że jeśli
@Jurix: Boost jest duży ze względu na to, że duża część to ładowanie aplikacji + cache'y. Natomiast zobaczymy jeszcze jak tym się będzie zarządzać, bo wbrew pozorom, mając PHPa na kilkuset serwerach czasami ciężko to utrzymać w ryzach. Póki co zdarzają się memory leaki, szczególnie w zewnętrznych modułach, które mają własny mechanizm alokacji pamięci i po sobie nie sprzątają. Jak się okaże, że trzeba
Ten wszędzie tą mordę zdziwioną wkleja, żeby przypadkiem widzowie nie zapomnieli jak wygląda xD Normalnie mi przypomina atora z tymi nagłówkami i miniaturkami
#php #programowanie #symfony #laravel
@Jurix: jeśli dla kogoś takie różnice wydajności są istotne, to znaczy że robi coś w dużej skali, a zatem nie użyje PHP tylko języków które do tego się lepiej nadają (np. Rust, albo w ostateczności Go).
@Krolik: Mało widziałeś miras
U nas na razie wdrażamy RR, potem będziemy testować Cycle ORM zamiast Doctrine, a potem resztę frameworka być może.
@Jurix: https://laravel.com/docs/10.x/octane
Tworzenie nowych frameworków moim zdaniem nie ma już żadnego sensu, bo te 2 zbudowały wokół siebie taki ekosystem i społeczność, że nikt o zdrowych zmysłach z tego nie zrezygnuje
https://phalcon.io/en-us
@Jurix: bardziej na Swoole, który jest wydajniejszy i daje większe możliwości.
@Jurix: tutaj nie zamierzam się kłócić bo ja robię tylko małe projekty, ale wydaje mi się, że jeśli
Komentarz usunięty przez autora
@Jurix: Boost jest duży ze względu na to, że duża część to ładowanie aplikacji + cache'y. Natomiast zobaczymy jeszcze jak tym się będzie zarządzać, bo wbrew pozorom, mając PHPa na kilkuset serwerach czasami ciężko to utrzymać w ryzach. Póki co zdarzają się memory leaki, szczególnie w zewnętrznych modułach, które mają własny mechanizm alokacji pamięci i po sobie nie sprzątają. Jak się okaże, że trzeba