Liveaviseringar är där Websockets frodas och ger en enorm fördel jämfört med AJAX.
Som ni vet diskuterades detta redan tidigare både när man diskuterade rollen som AJAX (bra för CRUD, inte så mycket vid omröstning) och när man jämför Websockets prestanda kontra AJAX-prestanda (Websockets är alltid snabbare när det gäller liveuppdateringar).
Ja... du kan spara resurser och förbättra prestanda (liksom framtida problem med kodunderhåll) genom att lägga till on_update "hakar" till databasens åtkomstpunkt.
Tanken är enkel:närhelst ett funktionsanrop uppdaterar MySQL-databasen skickas även uppdateringsbegäran till en återuppringning. Den återuppringningen är ansvarig för att publicera uppdateringen till rätt kanal.
På så sätt pollar du inte MySQL-databasen.
Vissa databaser erbjuder uppdateringsåteruppringningar och andra gör det inte. Jag tror att MySQL gör det. Jag undviker dock dessa databaslänkade återuppringningar eftersom de är databasspecifika. Det är bättre (IMHO) att lägga till återuppringningen till databasåtkomstpunkten i programmet, så att byte av en databas inte påverkar kodbasen.
Jag tycker inte att AJAX är ett bra tillvägagångssätt.
HTTP/2 hjälper till att mildra AJAX-bristerna, men det löser inte alla.
Jag vet inte hur många klienter du förväntar dig ska vara anslutna samtidigt, men att tvinga en klient att skicka en förfrågan varannan eller varannan sekund är mycket nära en självförvållad DoS-attack.
Tänk på detta:om en klient skickar en AJAX-förfrågan varannan sekund, än vid 2 000 samtidiga klienter, kommer din server att behöva svara på 1 000 req/sek - dessa inkluderar autentisering, databasfrågor och all den där jazzen.
Å andra sidan, med hjälp av Websockets, med 2 000 anslutna klienter, har du 2 000 beständiga anslutningar som inte gör något förrän ett meddelande kommer. Ingen CPU eller arbete krävs, bara anslutningens minne. Det finns ingen stress på servern förrän faktiska data skickas.
Ja, de är mer komplexa att implementera, men de är inte så svåra när du väl börjar. Dessutom finns det många bibliotek och hjälpverktyg som tar bort mycket av arbetet från dina axlar.
Vanliga problem relaterade till Websocket-metoden inkluderar hanteringen av den horisontella skalningen (ofta genom att lägga till en pub/underdatabas eller tjänst, såsom Redis), meddelandeordning (som bättre ignoreras när det är möjligt) och problem med dataspridning (när markerar vi data som "sedda"? skickar vi hela data eller bara ett meddelande om att data är tillgänglig? hur många kanaler använder vi och hur delar vi upp prenumerationer?).
Vanligtvis är svaren applikationsspecifika och beror på funktionen du försöker rulla ut såväl som den förväntade storleken på din datauppsättning (om varje svar jag gav på SO var en kanal skulle det vara orealistiskt att behålla).
Hur som helst... Lycka till!