Live-meldingen zijn waar Websockets gedijen en een enorm voordeel bieden ten opzichte van AJAX.
Zoals u weet, is dit al eerder besproken tijdens het debat over de rol van AJAX (ideaal voor CRUD, niet zozeer bij polling) en bij het vergelijken van Websocket-prestaties versus AJAX-prestaties (Websockets zijn altijd sneller als het om live updates gaat).
Ja... u kunt middelen besparen en de prestaties verbeteren (evenals toekomstige problemen met het onderhoud van de code) door on_update toe te voegen "haakt" aan het databasetoegangspunt.
Het idee is simpel:wanneer een functieaanroep de MySQL-database bijwerkt, wordt het updateverzoek ook naar een callback gestuurd. Die callback is verantwoordelijk voor het publiceren van de update op het juiste kanaal.
Op deze manier poll je de MySQL-database niet.
Sommige databases bieden update-callbacks en andere niet. Ik denk dat MySQL dat wel doet. Ik vermijd deze aan de database gekoppelde callbacks echter omdat ze databasespecifiek zijn. Het is beter (IMHO) om de callback toe te voegen aan het databasetoegangspunt in de toepassing, zodat het vervangen van een database geen invloed heeft op de codebasis.
Ik denk niet dat AJAX een goede benadering is.
HTTP/2 helpt de tekortkomingen van AJAX te verminderen, maar lost ze niet allemaal op.
Ik weet niet hoeveel clients u verwacht gelijktijdig verbonden te zijn, maar een client dwingen om elke seconde of twee een verzoek te verzenden, komt heel dicht in de buurt van een zelf toegebrachte DoS-aanval.
Overweeg dit:als een client elke twee seconden een AJAX-verzoek verzendt, dan bij 2.000 gelijktijdige clients, moet uw server reageren op 1.000 req/sec - dit omvat authenticatie, databasequery's en al die jazz.
Aan de andere kant, als u Websockets gebruikt, met 2000 verbonden clients, heeft u 2000 permanente verbindingen die niets doen totdat er een bericht binnenkomt. Geen CPU of werk vereist, alleen het geheugen van de verbinding. Er is geen stress op de server totdat de werkelijke gegevens worden gepusht.
Ja, ze zijn ingewikkelder om te implementeren, maar ze zijn niet zo moeilijk als je eenmaal begint. Er zijn ook veel bibliotheken en hulptools die je veel werk uit handen nemen.
Veelvoorkomende problemen met betrekking tot de Websocket-benadering zijn onder meer de afhandeling van de horizontale schaling (vaak door het toevoegen van een pub/sub-database of service, zoals Redis), berichtvolgorde (die indien mogelijk beter genegeerd kan worden) en zorgen over gegevenspropagatie (wanneer markeren we gegevens als "gezien"? sturen we de volledige gegevens of alleen een melding dat de gegevens beschikbaar zijn? hoeveel kanalen gebruiken we en hoe verdelen we abonnementen?).
Meestal zijn de antwoorden toepassingsspecifiek en hangen ze af van de functie die u probeert uit te rollen en van de verwachte grootte van uw dataset (als elk antwoord dat ik op SO gaf een kanaal was, zou het onrealistisch zijn om te handhaven).
Hoe dan ook... Veel succes!