[x.....x]

#php #naukaprogramowania

jestem w trakcie pisania pewnej stronki. front cały w vue + oddzielnie backend w php. Php sprawdza tam co minutę, czy ktoś jest online, zapisuje tam do bazy i tak dalej. Chcę to później wyświetlić na froncie, dane mają się aktualizować jeżeli coś się zmieni.

Lepiej będzie pukać ajaxem np. co 30s do api czy wykorzystać do tego websockety? Od początku planowałem zrobić to ajaxem, a przypadkowo wpadłem gdzie indziej na podobną funkcjonalność, gdzie są używane web sockety. Albo bez różnicy? ( ͡° ʖ̯ ͡°)

[Ponc3k]

@xoxxox websockety, działają szybciej i sprawniej niż pooling no I masz wszystko na bieżąco.

[paziu]

@xoxxox: ws albo sse

[Ponc3k]

@paziu zapomnialem o see całkowicie, ciekawe czy ktoś tego w ogóle uzywa

[Jurigag]

@xoxxox: sse imho bo łatwiejsze w implementacji i nie potrzebujesz podwójnej komunikacji, tylko aby zrobić to jak się powinno skorzystaj z shared worker + tabex na przeglądarkach nie wspieranych + https://github.com/clue/php-sse-react znaczy to ostatnie to już twoja decyzja, zależy od ruchu, ale na pewno shared worker + tabex bo inaczej bardzo łatwo szybko zapchać sobie procesy php-fpm @Ponc3k:

[Jurigag]

@xoxxox: @Ponc3k: no i też php-fpm + nginx często ma problemy aby ubić taki proces potem, tj nie wykrywa sobia zawsze że użytkownik zakończył połączenie, jakiś #!$%@? musiałem szukać dziwacznych rozwiązań aby w końcu działało poprawnie, z php-sse-react nie powinno być takowych problemów bo będziesz miał tylko jeden proces dla wszystkich użytkowników, ewentualnie kilka działających przez cały czas

[x.....x]

@Jurigag: łoo xD. dużo informacji. Zapoznam się z tematem. Jeżeli chodzi o wydajność to wiadomo, dużego ruchu się nie spodziewam. Albo to wrzucę na serwer, albo po skończeniu zakopię na githubie/dysku. Ale dzięki wielkie, przyda mi się to.

[Jurigag]

@xoxxox: sam ostatnio to robiłem, pominąłem jedynie react sse i na początku miałem zbugowane procesy bo się nie ubijały i po kilku dniach zapychało serwer xD

[Ponc3k]

@Jurigag: tym bardziej jak są takie problemy, to po czorta się pchać w tę archaiczną technologię kiedy mamy websockety.

[Jurigag]

@Ponc3k: po to że jak wyżej napisałem 1 łatwiejsze w implementacji 2 niepotrzebna nam dwustronna komunikacja, to nie jest archaiczna technologia, po prostu technologia do innych zastosowań