Live notifikationer er, hvor Websockets trives og giver en enorm fordel i forhold til AJAX.
Som du ved, blev dette allerede diskuteret før, både når vi diskuterede AJAX's rolle (fantastisk til CRUD, ikke så meget ved afstemning) og når man sammenligner Websockets ydeevne vs. AJAX-ydeevne (Websockets er altid hurtigere, når det drejer sig om liveopdateringer).
Ja... du kan spare ressourcer og forbedre ydeevnen (såvel som fremtidige problemer med kodevedligeholdelse) ved at tilføje on_update "hooks" til databaseadgangspunktet.
Ideen er enkel:hver gang et funktionskald opdaterer MySQL-databasen, sendes opdateringsanmodningen også til et tilbagekald. Det tilbagekald er ansvarlig for at udgive opdateringen til den korrekte kanal.
På denne måde poller du ikke MySQL-databasen.
Nogle databaser tilbyder opdateringstilbagekald, og andre gør ikke. Det tror jeg, MySQL gør. Jeg undgår dog disse databaselinkede tilbagekald, fordi de er databasespecifikke. Det er bedre (IMHO) at tilføje tilbagekaldet til databaseadgangspunktet i applikationen, så udskiftning af en database påvirker ikke kodebasen.
Jeg synes ikke, AJAX er en god tilgang.
HTTP/2 hjælper med at afbøde AJAX-manglerne, men det løser ikke dem alle.
Jeg ved ikke, hvor mange klienter du forventer skal være forbundet samtidigt, men at tvinge en klient til at sende en anmodning hvert sekund eller andet er meget tæt på et selvforskyldt DoS-angreb.
Overvej dette:Hvis en klient sender en AJAX-anmodning hvert andet sekund, end ved 2.000 samtidige klienter, skal din server svare på 1.000 req/sek. - disse inkluderer godkendelse, databaseforespørgsler og al den jazz.
På den anden side, ved at bruge Websockets, med 2.000 tilsluttede klienter, har du 2.000 vedvarende forbindelser, der ikke gør noget, indtil en besked ankommer. Ingen CPU eller arbejde påkrævet, kun forbindelsens hukommelse. Der er ingen stress på serveren, før de faktiske data er pushet.
Ja, de er mere komplekse at implementere, men de er ikke så svære, når du først starter. Der er også en masse biblioteker og hjælpeværktøjer, der fjerner meget af arbejdet fra dine skuldre.
Almindelige problemer relateret til Websocket-tilgangen omfatter håndteringen af den horisontale skalering (ofte ved at tilføje en pub/underdatabase eller tjeneste, såsom Redis), meddelelsesbestilling (som bedre ignoreres, når det er muligt) og bekymringer om dataudbredelse (hvornår markerer vi data som "set"? sender vi hele data eller bare en notifikation om, at data er tilgængelige? hvor mange kanaler bruger vi, og hvordan deler vi abonnementer?).
Normalt er svarene applikationsspecifikke og afhænger af den funktion, du forsøger at rulle ud, samt den forventede størrelse af dit datasæt (hvis hvert svar, jeg gav på SO var en kanal, ville det være urealistisk at vedligeholde).
Anyway... Held og lykke!