Som ni kanske vet är Rails 5 här, och har en spännande sidekick! Mina damer och herrar, låt oss sätta ihop våra händer och välkomna Åtgärdskabel, det nyhetliga ramverket som integrerar WebSocket kommunikation med Rails.
Idag vill jag dela några tankar om detta ramverk, starta med WebSockets, gå vidare till Action Cable och sedan linda mitt huvud runt problemen som WebSockets är svaret på och den mängd lösningar man kan sätta på plats.
Den stora finalen kommer att vara på strukturen och dynamiken hos vår hjälte av dagen - Action Cable.
Vad är WebSockets? Om du försöker hitta det svaret på internet kan du få uttalanden som:
”WebSockets är de coola sakerna som Node-folket får använda”
eller
”Jag hörde att WebSockets är framtiden”
WebSockets är i princip ett annat lager av kommunikation mellan klient och server, men till skillnad från HTTP-förfrågningar är deras anslutningar statlig. Detta innebär att länken mellan klient och server förblir konstant och ansluten.
WebSocket-anslutningar möjliggör samtidig och dubbelriktad kommunikation, så att både klient och server kan skicka meddelanden när som helst via kanalen.
En annan fördel med att använda WebSockets är När du har upprättat anslutningen behöver du inte utbyta mycket metadata (http-rubriker). Eftersom det finns en WebSocket per klient du behöver inte identifiera dig själv varje gång du skickar data till servern, eftersom servern redan vet vem du är eftersom den vet vem som öppnade kanalen.
Den sista (och uppenbara) fördelen är att du kan ha verkliga realtidsfunktioner, som chattrum eller aviseringar, utan att till exempel behöva använda polling, som lägger till belastningar på servrarna.
Å andra sidan, den stora fördelen med att använda HTTP istället för WebSockets är att det finns många saker som redan är implementerade för http, till exempel cachning, routing och multiplexing, som fortfarande inte är det WebSockets redo.
Vad är Action Cable? På sin egen Github-sida:
Action Cable integrerar sömlöst WebSockets med resten av din Rails-applikation. Det gör att realtidsfunktioner kan skrivas i Ruby i samma stil och form som resten av din Rails-applikation, samtidigt som de är skalbara och bibehåller prestanda. Det är ett fullstack-erbjudande som tillhandahåller både ett JavaScript-ramverk på klientsidan och ett Ruby-ramverk på serversidan. Du har tillgång till din fullständiga domänmodell skriven med Active Record eller din valda ORM.
Det låter fantastiskt. Action Cable är ett kraftfullt tillskott till Rails, ger ett rent gränssnitt för både Javascript-kod på klientsidan och Rails-kod på serversidan. En sak som jag tyckte var särskilt intressant är Rails 5 levereras med Redis som standard eftersom Action Cable använder den som en pub-sub-tjänst för kanalens abonnenter.
Det här är mycket intressant men vi som företag använder teknik för att lösa våra kunders problem. Så varför behöver vi WebSockets och Action Cable? Jag hittade tre huvudskäl.
Den första är när man behöver skicka och ta emot data snabbt med servern, till exempel i webbläsarbaserade spel online som behöver utbyta flera meddelanden per sekund med servern, eller information om aktiemarknaden, som ständigt förändras.
En annan är streaming. WebSockets är ett bra alternativ, även om jag tror att Rails inte ofta används för strömmande applikationer. Detta kan förändras inom en snar framtid med hjälp av WebSockets och Action Cable.
Och sist men inte minst, levande element, såsom kommentarsfält som automatiskt uppdateras när nytt innehåll läggs till utan en siduppdatering och, naturligtvis, chattrum. Här vill vi att sidan ska uppdateras när data ändras på servern utan användarens ingripande, vilket gör det mesta av Action Cables funktioner.
Men det finns alternativ till WebSockets.
Polling är en populär lösning!
Polling gör att klienten frågar servern regelbundet om det finns några nya data. Fördelen? Det är bergfast och väldigt enkelt att installera. Den största nackdelen är att lägga till belastning på servrarna. HTTP-caching är mycket bra för att lindra den belastningen.
Polling är ok för saker som kommentaravsnitt, men inte för snabba kommunikationsbehov. Ett exempel är Basecamp chattapp, som använde 3-sekunders omröstning i 10 år, men med Basecamp 3 gick vidare till Action Cable.
Andra ”inte så populära” alternativ är Long-Polling och Server-Sent Events.
I Lång omröstning klienten skickar en begäran till servern om nya data och, om servern har nya data, skickar den ett svar tillbaka som en vanlig HTTP-förfrågan; om inte, håller den begäran och slutför svaret när nya data visas.
Detta faller snabbt isär om data ändras ofta. Långpollingstekniker är också mycket mer komplicerade att implementera än omröstning.
Serverskickade händelser är enkelriktade anslutningar från server till klient. Dessa saknar inte bara ordentligt stöd, men tillåter inte heller klienten att skicka data tillbaka till servern.
Bara för att få känslan av Action Cable i aktion byggde jag en enkel chattapp. Det är inloggningsbaserat, har ett rum för att utbyta meddelanden, och du kan se användarna som är online. Jag ska nu prata om huvuddelarna relaterade till Action Cable.
När du skapar din Rails 5-applikation har du nu ytterligare en mapp i appkatalogen, kanaler mapp.
Under mappkanalerna har du applikationskabel mapp som innehåller kanal.rb filen och anslutning.rb fil.
Den anslutning.rb filen ärver form actionCable: :Anslutning: :Base och det används för allmän autentisering. Vi kan använda den här modulen för att fråga databasen efter en specifik användare som gör anslutningen och se till att användaren får lyssna på kanalen.
Den kanal.rb ärver från actionCable: :Channel: :Base och det liknar ApplicationController i vår vanliga Rails-applikation.
Sedan har vi två kanaler under mappen, utseende_kanal.rb och rum_kanal.rb. Det var kanalerna som jag
skapad. Kanalerna har samma prenumerations- och avprenumerationsmetoder:
UtseendeKanal har också ytterligare två metoder som kan åberopas av klienten. Rumkanal har ytterligare en metod, tala metod, som också används av klienten för att skicka meddelanden till kanalen.
Från kundsidan har vi kabel.kaffe fil som är ansvarig för att skapa anslutningen mellan klient och server.
Sedan har vi kanalens prenumeranter. I det här fallet har vi den utseendeabonnent som gick med i utseendekanalen, och vi har rumskanalabonnenten som gick med i rumskanalen.
Vi kan se på bilden ovan hur kanalprenumerationen görs.
Prenumeranterna har några metoder gemensamt:
Sedan kan varje kanal implementera olika metoder som interagerar med kanalen de prenumererar på serversidan. Så är fallet med tala, dyka upp och bort metoder som kan skicka data och anropa motsvarande metoder på serversidan.
Rails lever och ger oss fler (och bättre) ramverk för att hjälpa till att skapa produkter mer effektivt.
Action Cable är ett av dessa ramverk och jag tror verkligen att det kan vara mycket användbart att bygga levande element som är så populära i dagens webbapplikationer.
Jag är också nyfiken på pärlorna som kan bygga ovanpå Action Cable, och ser fram emot hur samhället kommer att omfamna detta nya verktyg.
Vid Imaginärt moln vi arbetar med en bred teknisk stack, inklusive Ruby on Rails. Om du behöver hjälp med denna teknik eller liknande i ditt mjukvaruutvecklingsprojekt har vi ett team av experter som väntar på dig! Skicka oss en rad här!
Hittade den här artikeln användbar? Du kanske gillar dessa också!
Professionell med erfarenhet av programvaruteknik och informationssystem, med fokus på full-stack web engineering.
Människor som läste det här inlägget tyckte också att dessa var intressanta:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
