Som du måske ved, er Rails 5 her, og har en spændende sidekick! Mine damer og herrer, lad os lægge hænderne sammen og byde velkommen Handlingskabel, nyhedsrammen, der integrerer WebSocket kommunikation med Rails.
I dag vil jeg dele nogle tanker om denne ramme, starte med WebSockets, gå videre til Action Cable og derefter vikle mit hoved rundt om de problemer, som WebSockets er svaret på, og den række løsninger, man kan sætte på plads.
Den store finale vil være på strukturen og dynamikken i vores dagens helt - Action Cable.
Hvad er WebSockets? Hvis du forsøger at finde det svar på internettet, kan du få udsagn som:
„WebSockets er de seje ting, som Node-folk får brug for“
eller
„Jeg hørte, at WebSockets er fremtiden“
WebSockets er dybest set et andet lag af kommunikation mellem klient og server, men i modsætning til HTTP-anmodninger er deres forbindelser tilstandsdygtig. Dette betyder, at forbindelsen mellem klient og server forbliver konstant og forbundet.
WebSocket-forbindelser muliggør samtidig og tovejskommunikation, så både klient og server kan sende beskeder til enhver tid gennem kanalen.
En anden fordel ved at bruge WebSockets er Når du har oprettet forbindelsen, behøver du ikke at udveksle meget metadata (http-overskrifter). Da der er en WebSocket pr. Klient du behøver ikke at identificere dig selv, hver gang du sender data til serveren, fordi serveren allerede ved, hvem du er, da den ved, hvem der åbnede kanalen.
Den sidste (og åbenlyse) fordel er, at du kan have virkelig realtidsfunktioner, som chatrum eller meddelelser, uden behov for for eksempel at bruge polling, der tilføjer belastninger til serverne.
På den anden side er den store fordel ved at bruge HTTP i stedet for WebSockets, at der allerede er en masse ting implementeret til http, såsom caching, routing og multiplexing, som stadig ikke er det WebSockets klar.
Hvad er Action Cable? På sin egen Github-side:
Action Cable integrerer problemfrit WebSockets med resten af din Rails-applikation. Det giver mulighed for, at realtidsfunktioner skrives i Ruby i samme stil og form som resten af din Rails-applikation, mens de stadig er skalerbare og opretholder ydeevnen. Det er et full-stak-tilbud, der giver både en JavaScript-ramme på klientsiden og en Ruby-ramme på serversiden. Du har adgang til din fulde domænemodel skrevet med Active Record eller din valgte ORM.
Det lyder fantastisk. Action Cable er en kraftfuld tilføjelse til Rails, der giver en ren grænseflade til både Javascript-kode på klientsiden såvel som Rails-kode på serversiden. En ting, som jeg fandt særligt interessant, er Rails 5 leveres med Redis som standard, fordi Action Cable bruger det som en pub-sub-tjeneste for kanalens abonnenter.
Dette er alt sammen meget interessant, men vi som virksomhed bruger teknologi til at løse vores kunders problemer. Så hvorfor har vi brug for WebSockets og Action Cable? Jeg fandt tre hovedårsager.
Den første er, når man har brug for sende og modtage data hurtigt med serveren, for eksempel i online browserbaserede spil, der har brug for at udveksle flere meddelelser i sekundet med serveren, eller information om aktiemarkedet, der konstant ændrer sig.
En anden er streaming. WebSockets er en god mulighed, selvom jeg tror, at Rails ikke ofte bruges til streamingapplikationer. Dette kan ændre sig i den nærmeste fremtid ved hjælp af WebSockets og Action Cable.
Og sidst, men ikke mindst, levende elementer, såsom Kommentar sektioner der automatisk opdateres, når nyt indhold tilføjes uden en sideopdatering og, selvfølgelig, chatrum. Her ønsker vi, at siden skal opdateres, når dataene ændres på serveren uden brugerens indgriben, hvilket får mest muligt ud af Action Cables muligheder.
Men der er alternativer til WebSockets.
Afstemning er en populær løsning!
Polling får klienten til at spørge serveren med jævne mellemrum, om der er nye data. Fordelen? Det er stenfast og meget enkelt at sætte op. Den største ulempe er at tilføje belastning til serverne. HTTP-caching er meget god til at lindre denne belastning.
Afstemning er ok til ting som kommentarsektioner, men ikke til hurtige kommunikationsbehov. Et eksempel er Basecamp chat-app, der brugte 3-sekunders afstemning i 10 år, men med Basecamp 3 gik videre til Action Cable.
Andre „ikke-så-populære“ muligheder er Long-Polling og Server-Sent Events.
I Lang afstemning klienten sender en anmodning til serveren om nye data, og hvis serveren har nye data, sender den et svar tilbage som en normal HTTP-anmodning; hvis ikke, holder den anmodningen og afslutter svaret, når nye data vises.
Dette falder hurtigt fra hinanden, hvis data ændres ofte. Langpollingsteknikker er også langt mere komplicerede at implementere end afstemninger.
Serversendte begivenheder er envejsforbindelser fra server til klient. Disse mangler ikke kun ordentlig support, men tillader heller ikke klienten at sende data tilbage til serveren.
Bare for at få følelsen af Action Cable i aktion byggede jeg en simpel chat-app. Det er loginbaseret, har et rum til at udveksle beskeder, og du kan se de brugere, der er online. Jeg vil nu tale om de vigtigste dele relateret til Action Cable.
Når du opretter din Rails 5-applikation, har du nu endnu en mappe inde i appmappen, kanaler mappe.
Under mappens kanaler har du applikationskabel mappe, der indeholder kanal.rb fil og forbindelse.rb fil.
Den forbindelse.rb fil arver form ActionCable: :Tilslutning: :Base og det bruges til generel godkendelse. Vi kan bruge dette modul til at forespørge databasen efter en bestemt bruger, der opretter forbindelsen og sikre, at brugeren har lov til at lytte til kanalen.
Den kanal.rb arver fra ActionCable: :Kanal: :Base og det ligner ApplicationController i vores normale Rails-applikation.
Derefter har vi to kanaler under mappen, udseende_kanal.rb og den room_channel.rb. Det var de kanaler, jeg
skabt. Kanalerne har de samme abonnementsmetoder og afmeldte metoder:
UdseendeKanal har også to flere metoder, der kan påberåbes af klienten. RoomKanal har endnu en metode, tal metode, der også bruges af klienten til at sende beskeder til kanalen.
Fra klientsiden har vi kabel.kaffe fil, der er ansvarlig for at oprette forbindelsen mellem klient og server.
Så har vi kanalens abonnenter. I dette tilfælde har vi den udseendeabonnent, der sluttede sig til udseendekanalen, og vi har den rumkanalabonnent, der sluttede sig til rumkanalen.
Vi kan se på billedet ovenfor, hvordan kanalabonnementet oprettes.
Abonnenterne har nogle metoder til fælles:
Derefter kan hver kanal implementere forskellige metoder, der interagerer med den kanal, de abonnerer på serversiden. Det er tilfældet med tal, komme til syne og væk metoder, der kan sende data og kalde de tilsvarende metoder på serversiden.
Rails lever og bringer os flere (og bedre) rammer for at hjælpe med at skabe produkter mere effektivt.
Action Cable er en af disse rammer, og jeg tror virkelig, at det kan være meget nyttigt at bygge levende elementer, der er så populære i nutidens webapplikationer.
Jeg er også nysgerrig efter de perler, der kan bygge oven på Action Cable, og ser frem til, hvordan samfundet vil omfavne dette nye værktøj.
Ved Imaginær sky vi arbejder med en bred teknisk stak, inklusive Ruby on Rails. Hvis du har brug for hjælp til denne teknologi eller lignende i dit softwareudviklingsprojekt, har vi et team af eksperter, der venter på dig! Send os en linje her!
Fandt du denne artikel nyttig? Du kan måske også lide disse!
Professionel med erfaring inden for software engineering og informationssystemer, med fokus på full-stack web engineering.
People who read this post, also found these interesting:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
