HUR MAN BYGGER EN CHATT-APP I REALTID MED NODE OCH REACT MED WEBSOCKETS

Lär dig hur du bygger en chatt-app i realtid med Node och React med WebSockets.

Introduktion - 00:00
HTTP -protokoll - 00:17
Skapa en chattapp - 03:01
Skapa servern - 04:09
Skapa klienten -07:00
Implementera en inloggningsfunktion - 11:52
Implementera användargränssnitt - 13:45
Slutsats - 19:57

Webben har gått långt för att stödja full duplex (eller tvåvägs) kommunikation mellan en klient och server. Detta är den huvudsakliga avsikten med WebSocket-protokollet: att tillhandahålla ihållande realtidskommunikation mellan klienten och servern via en enda TCP-uttag.

diah coin kryptopris

WebSocket -protokollet har bara två agendor: 1.) för att öppna ett handslag och 2.) för att hjälpa dataöverföringen. När både servern och klienten har sina handtryck in kan de skicka data till varandra med mindre omkostnader efter behag.

WebSocket -kommunikation sker över ett enda TCP -uttag med antingen WS (port 80) eller WSS (port 443) protokoll. Nästan alla webbläsare utom Opera Mini ger beundransvärt stöd för WebSockets i skrivande stund, enligt Kan jag använda .

Historien hittills

Historiskt sett krävde det att skapa webbappar som behövde data i realtid (som spel- eller chattappar) missbruk av HTTP -protokoll för att upprätta dubbelriktad dataöverföring. Det fanns flera metoder som används för att uppnå realtidskapacitet, men ingen av dem var lika effektiva som WebSockets. HTTP -polling, HTTP -streaming, Comet, SSE - de hade alla sina egna nackdelar.

HTTP -undersökning

Det allra första försöket att lösa problemet var genom att polla servern med jämna mellanrum. HTTP: s långa undersöknings livscykel är följande:

Klienten skickar ut en förfrågan och väntar på svar.
Servern avviker från sitt svar tills det finns en ändring, uppdatering eller timeout. Begäran stannade tills servern hade något att återvända till klienten.
När det är någon ändring eller uppdatering på serveränden skickar det ett svar tillbaka till klienten.
Klienten skickar en ny långfrågeförfrågan för att lyssna på nästa uppsättning ändringar.

Det fanns många kryphål i långa omröstningar - rubrik över huvudet, latens, timeout, caching, och så vidare.

HTTP -streaming

Denna mekanism sparade smärtan av nätverkslatens eftersom den första begäran hålls öppen på obestämd tid. Begäran avslutas aldrig, även efter att servern har skickat data. De tre första livscykelmetoderna för HTTP -streaming är desamma vid HTTP -polling.

När svaret skickas tillbaka till klienten avslutas dock aldrig begäran; servern håller anslutningen öppen och skickar nya uppdateringar när det ändras.

Server-skickade händelser (SSE)

Med SSE skickar servern data till klienten. En chatt- eller spelapplikation kan inte helt förlita sig på SSE. Det perfekta användningsfallet för SSE är t.ex. Facebook News Feed: när nya inlägg kommer in, skjuter servern dem till tidslinjen. SSE skickas över traditionell HTTP och har begränsningar för antalet öppna anslutningar.

Dessa metoder var inte bara ineffektiva, koden som gick in i dem gjorde också utvecklare trötta.

Varför WebSocket är prinsen som utlovades

WebSockets är utformade för att ersätta befintlig dubbelriktad kommunikationsteknik. De befintliga metoderna som beskrivs ovan är varken tillförlitliga eller effektiva när det gäller realtidskommunikation i full duplex.

WebSockets liknar SSE men triumferar också i att ta tillbaka meddelanden från klienten till servern. Anslutningsbegränsningar är inte längre ett problem eftersom data serveras över en enda TCP -sockelanslutning.

Praktisk handledning

Som nämnts i inledningen har WebSocket -protokollet bara två agendor. Låt oss se hur WebSockets uppfyller dessa agendor. För att göra det ska jag snurra bort en Node.js -server och ansluta den till en klient som är byggd med React.js.

Agenda 1: WebSocket upprättar en handskakning mellan server och klient

Skapa ett handslag på servernivå

Vi kan använda en enda port för att rotera HTTP -servern och WebSocket -servern. Kärnan nedan visar skapandet av en enkel HTTP -server. När den väl skapats knyter vi WebSocket -servern till HTTP -porten:

const webSocketsServerPort = 8000; const webSocketServer = require('websocket').server; const http = require('http'); // Spinning the http server and the websocket server. const server = http.createServer(); server.listen(webSocketsServerPort); const wsServer = new webSocketServer({ httpServer: server });

När WebSocket -servern har skapats måste vi acceptera handskakningen när vi mottar begäran från klienten. Jag upprätthåller alla anslutna klienter som ett objekt i min kod med ett unikt användar-id när jag får deras begäran från webbläsaren.

// I'm maintaining all active connections in this object const clients = {}; // This code generates unique userid for everyuser. const getUniqueID = () => { const s4 = () => Math.floor((1 + Math.random()) * 0x10000).toString(16).substring(1); return s4() + s4() + '-' + s4(); }; wsServer.on('request', function(request) { var userID = getUniqueID(); console.log((new Date()) + ' Recieved a new connection from origin ' + request.origin + '.'); // You can rewrite this part of the code to accept only the requests from allowed origin const connection = request.accept(null, request.origin); clients[userID] = connection; console.log('connected: ' + userID + ' in ' + Object.getOwnPropertyNames(clients)) });

Så, vad händer när anslutningen accepteras?

Medan den vanliga HTTP -begäran skickas för att upprätta en anslutning, skickar klienten i förfrågningsrubrikerna | _+_ |. Servern kodar och haschar detta värde och lägger till ett fördefinierat GUID. Det ekar det genererade värdet i | _+_ | i den server skickade handskakningen.

När begäran har accepterats på servern (efter nödvändiga valideringar i produktionen) uppfylls handslaget med statuskoden | _+_ |. Om du ser något annat än statuskod | _+_ | i webbläsaren har WebSocket -uppgraderingen misslyckats och den normala HTTP -semantiken kommer att följas.

Den | _+_ | rubrikfältet anger om servern är villig att acceptera anslutningen eller inte. Om svaret saknar en | _+_ | rubrikfältet, eller | _+_ | inte lika med | _+_ |, betyder det att WebSocket -anslutningen misslyckades.

fladdra toppnavigeringsfältet

Det framgångsrika serverhandslaget ser ut så här:

*Sec-WebSocket-Key*

Skapa ett handslag på klientnivå

På klientnivå använder jag samma WebSocket -paket som vi använder på servern för att upprätta anslutningen till servern (WebSocket API i Web IDL standardiseras av W3C). Så snart förfrågan accepteras av servern ser vi | _+_ | på webbläsarkonsolen.

Här är det första stället för att skapa anslutningen till servern:

*Sec-WebSocket-Accept*

Följande rubriker skickas av klienten för att upprätta handslaget:

101

Nu när klienten och servern är anslutna med ömsesidiga handskakningar kan WebSocket -anslutningen överföra meddelanden när den tar emot dem och därmed uppfylla den andra agendan för WebSocket -protokollet.

Agenda 2: Överföring av meddelanden i realtid

Jag kommer att koda en grundläggande dokumentredigerare i realtid där användare kan gå ihop och redigera ett dokument. Jag spårar två händelser:

Användaraktiviteter: Varje gång en användare går med eller lämnar, sänder jag meddelandet till alla andra anslutna klienter.
Innehållsändringar: Varje gång innehållet i redigeraren ändras sänds det till alla andra anslutna klienter.

Protokollet tillåter oss att skicka och ta emot meddelanden som binär data eller UTF-8 (N.B., sändning och konvertering av UTF-8 har mindre overhead).

Att förstå och implementera WebSockets är mycket enkelt så länge vi har en god förståelse för sockethändelserna: | _+_ |, | _+_ | och | _+_ |. Terminologierna är desamma på både klient- och serversidan.

GitHub -repo: https://github.com/kokanek/web-socket-chat

#node-js #reactjs #javascript #websockets

www.youtube.com