ActionCable for Not-Another-Chat-App-Please
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 59 | |
| Number of Parts | 89 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/31495 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
RailsConf 201659 / 89
1
2
3
5
7
8
11
12
19
22
28
29
30
31
33
45
47
50
52
53
58
62
67
71
74
76
77
78
79
80
81
84
85
86
88
89
00:00
GodClient (computing)EmailSocket-SchnittstelleProcess (computing)Semiconductor memoryHoaxGroup actionWeb 2.0Meta elementMultiplication signMedical imagingOnline chatEndliche ModelltheorieSystem callMobile appCodeTelecommunicationLoop (music)Connected spaceMathematicsServer (computing)Home pageNetwork socketQuicksortWebsiteDependent and independent variablesMessage passing2 (number)CuboidTwitterDialectObject (grammar)Traffic reportingRight angleView (database)DebuggerTrailPattern languageData storage deviceSet (mathematics)Dynamical systemMereologyFormal languagePresentation of a groupPoint (geometry)Strategy gameDiagramError messageWater vaporGoodness of fitStructural loadTable (information)Rule of inferenceBitExecution unitBuildingDemosceneBlock (periodic table)WordComputer animation
07:59
WordCollaborationismBlock (periodic table)Source codeProcess (computing)QuicksortPlastikkarteRight anglePropositional formulaPole (complex analysis)CausalityMathematicsComplete metric spaceNumberGroup actionReal numberWindowDiagramCASE <Informatik>CodeLevel (video gaming)WebsiteRow (database)BuildingMobile appDivisorTable (information)Structural loadFigurate numberInstallation artServer (computing)Revision controlHome pageLink (knot theory)Dependent and independent variablesHypermediaBit rateACIDVaporProbability density functionElectric generatorSocket-SchnittstelleBit3 (number)Game controllerTurbo-CodeFacebookTask (computing)Ocean currentExistenceSoftwareBeta functionDifferent (Kate Ryan album)Scripting languagePropagatorTelecommunicationWeb 2.0Inheritance (object-oriented programming)Online chatPatch (Unix)Film editingINTEGRALCore dumpClient (computing)Lecture/Conference
15:48
Line (geometry)Mobile appMessage passingObject (grammar)Group actionRight angleCartesian coordinate systemConnected spaceTemplate (C++)Module (mathematics)Game controllerHash functionQuicksortDifferent (Kate Ryan album)Streaming mediaClient (computing)HTTP cookiePay televisionServer (computing)System callFunctional (mathematics)Process (computing)Multiplication signMultilaterationBroadcasting (networking)InformationExistenceInheritance (object-oriented programming)Interactive televisionDecision tree learningLatent heatWeb browserEndliche ModelltheorieControl flowConnectivity (graph theory)Standard deviationProduct (business)Rule of inferenceEvent horizonConfiguration spaceSummierbarkeitScripting languageQuery languageTable (information)PasswordPoint (geometry)BitSheaf (mathematics)Socket-SchnittstelleLibrary (computing)VolumenvisualisierungFacebookOcean currentSoftware testingEmailMereologyTask (computing)Food energyComputer science
23:34
Message passingMobile appPay televisionVideo gameGame controllerSlide rulePattern languageMechatronicsTask (computing)Local ringRight angleClient (computing)Process (computing)Functional (mathematics)Musical ensemblePoint (geometry)Standard deviationData conversionBroadcasting (networking)Home pageScripting languageTraffic reportingLibrary (computing)Table (information)Event horizonSystem administratorServer (computing)QuicksortMathematicsLaptopBit rateComputer configurationDecision tree learningContext awarenessProteinStreaming mediaMereologyState of matterDifferenz <Mathematik>Cartesian coordinate systemWeb pageOpen setRead-only memorySynchronizationLine (geometry)Web browserAsynchronous Transfer ModeCASE <Informatik>CollaborationismWordProduct (business)WebsiteElectronic mailing listGraph (mathematics)Reading (process)Probability density functionGroup actionPresentation of a groupHookingString (computer science)VolumenvisualisierungTemplate (C++)2 (number)Ocean current
31:20
Streaming mediaServer (computing)Message passingType theoryGame controllerBroadcasting (networking)Event horizonGroup actionConnected spaceData conversionBitMathematicsProcess (computing)QuicksortTwitterSoftwarePhysicalismSoftware developerConfiguration spaceSocket-SchnittstelleMechanism designScaling (geometry)Online chatMereologySemiconductor memorySynchronizationGoodness of fitTask (computing)Queue (abstract data type)Physical systemWebsiteUniform resource locatorAsynchronous Transfer ModeHome pageProduct (business)ScalabilityDefault (computer science)CollaborationismRevision controlComplete metric spaceElectric generatorPlastikkartePay televisionExtreme programmingLine (geometry)Projective planeReading (process)Operator (mathematics)Directed graphMultiplication signTable (information)Domain nameLevel (video gaming)HTTP cookieStandard deviationKey (cryptography)Computer configurationLocal ringRight angle
39:06
Computer animation
Transcript: English(auto-generated)
00:10
Welcome to in Rails 5 track. I'm extremely proud to be part of it. I'm excited for all other talks today.
00:23
I think this is a really cool release. So let's dive into cable boxes. So this was the first cable box I ever saw. And look, it's got a cable. I don't know if any of you are old enough to have seen one of these things. But this would sit and connect to your TV.
00:44
And you'd be like, OK, to get to 33, I find that. And I've got to do the dial. But that's not the cable we're talking about. Obviously, for this presentation, I made several high-quality 8-bit art, not 2-bit, not 4-bit, but diagrams throughout this presentation.
01:03
You're welcome in advance. Here, we see our intrepid user connecting to Rails through a cloud. Yeah, so again, you're welcome. I'm pretty good.
01:21
So how can action cable sort of change this up? So what we're going to do is we're going to talk about the history of action cable and WebSockets. We're going to talk about what it is, what it's not. We'll talk about building blocks, like what actually,
01:40
what code is there for you to use, and then some patterns. We'll also talk about deployment strategies, how to actually make use of this today. My name is Jesse Walgamont. You can on JWO, on Twitter, and the GitHubs. If you've got questions, comments on this talk, I don't think we're going to have time for Q&A. So tweet at me, and I'll do my best to get you an answer.
02:05
So I found that the best way to look forward at changes that we're going to take place is to look back and to see where we stand in this march of time. So let's start at our F5 refresh, or our command R.
02:25
So in general, this is how we would update a page for a lot of times. So checking your email was frustrating. You had to click refresh. And then you had to make sure that your 2 meg of storage
02:42
didn't get taken up by someone sending you like a 300 by 300 JPEG. And then you had to call, because texting wasn't really a thing yet. You had to call your friend and be like, check your email. It is full. Kids today with your gigs upon gigs upon gigs of storage,
03:00
just don't understand. So other than that, if you're going to get a page to update itself, maybe you could just have it auto refresh. So you could have a meta tag that would say, hey, refresh yourself every 3 to 10 seconds. Drudge report did this for a long time, I think still does.
03:23
And since sites were being paid by the ad impressions, this is a pretty good story. You just leave your site up and it would just refresh, refresh, refresh. I don't know why that model didn't work. But this would be the code that would make that work. So by the time that 2002, 2003 came along,
03:45
we wanted better. And so we got polling. Polling would be, in that time, like Gmail. Gmail came out and did its, hey, you've got two new messages. It didn't update the page.
04:01
And at the time, that's like, what? OK, now this is in 2012. But DHH said, campfire to this day still uses a three second poll. Chat was supposed to be the poster boy for web sockets and friends. Now, that's 2012.
04:22
Times have changed. I'm glad that we can move on. But this was DHH's view. And he said, polling remains a great way to make your app dynamic. If you don't require sub-second responses, live updates in Basecamp are polling. So this works on a very large set of websites
04:44
where you can just have it every three seconds. Fetch my new stuff. So there are apps that don't need sub-second responses. Having your JS poll for changes on an interval is like an extremely good idea in many circumstances.
05:01
So this can be what that looks like. jQuery pops up. You say, set an interval. Make an Ajax recall every three seconds. And sort of set it and forget it. But then we get to web sockets, which are so hot right now. So I first saw web sockets be used with Pusher app.
05:25
They're here. And it made everything very easy. They took care of everything for you. So you'd process an image in the background, and then post to Pusher's API when you're done. And your front end listened to Pusher and updated when it was done.
05:43
So this came about, as far as I can tell, by RFC 6455 in 2011. It says, basically, it's two-way communication between the client and the server, and that the remote host has to opt into the communication. Whereas HTTP calls just go and are taken.
06:03
But the client has to request a web socket. The server has to say yes. So some examples. Socket.io made things pretty simple in node land to push updates from the server out to the client.
06:23
Patrick McKenzie, patio 11, built a pretty sweet fake stock market. I don't know if you've played with this or not, but it is pretty sweet. So it sends trades out via web sockets. Or you can constantly ask via an API call, like,
06:40
do you have any new trades that have been made? But the thing is, you'd have to do that on a loop. Is there any trades? Is there any trades? You're making a new connection every time. And when you're trying to do high-frequency trading, which is what it's all about, you want to get at the trade as soon as it possibly can.
07:03
And so connecting via web sockets was a way that you can actually get it almost as it happens, rather than making a call in an infinite loop. So the trouble is, how can a server keep track of all these connections?
07:21
Scaling up in a big server can sort of work in a language like Elixir and others like it. But what about our dear friend Ruby? If every connection lives, and there's got to be an object that's listening for connections from client to server, that has to be taken up in memory.
07:42
And Ruby loves its memory. So you're probably like, I'm uncertain about 2,000 connections, let alone 2 million connections. So with Ruby and with Rails, there's got to be a story about scaling out, not just scaling up. And spoiler alert, there is.
08:02
So is the future just real time? Probably not. I doubt that we're going to default to building every feature with action cable. But I think it can add sort of pizazz and fun and really fast updates.
08:20
For certain apps that require that low latency, website cuts is how I would describe treat yourself good, my philosophy. So let's take a look at what action cable is
08:43
and what's not. So if we know where the possible warts are, but we also know where the awesome is, we can decide if it fits in our tool belt. So first, let's start with the what it's not. In general, it's not just a silver bullet
09:00
that will make everything super fantastic, great, awesome sauce. So let's talk about what it's not. So it's very much made to work inside of Rails. I could see a future where it's lifted out, but from what I've seen, we're not there yet. I don't consider this a bad thing,
09:21
but it does sort of want to be in a request, or it wants to connect with a controller. It wants to be in Rails. That's fine. It's not like people are gonna NPM install action cable. It's also not necessarily a step forward for Rails
09:42
into more JavaScript integration. Like there is JavaScript here, but I saw this and I was like, I think this makes sense. It's not, it is just a feature. It's the next JBuilder.
10:01
It's the next Turbolinks. It's not the next AssetPipeline. It's not the next ActiveRecord. It's just a feature. So let's talk about what it is. So it's a solid feature. Like it works, it's fun, it adds value to your app.
10:25
I don't think it needs to be any more than this, but like this is sort of the scope. It's a nice feature to have for Rails apps. So like Turbolinks and JavaScript responses, it's a way to like snappify Rails. It's a way to make it faster.
10:42
Like there is a certain wow factor where you've got like two windows up and you make a change on one, it like propagates to the other. Like people are, so like wow, that's cool. It's also easy and fun, which like big props on that.
11:02
So why no chat apps? Like why did I specifically come here and say, we're not gonna talk about chat apps? So when I came up with the idea for this talk, I was somewhat dread, like I was dreading the talk that I might hear if I attended. I think it'd be about chatting between users,
11:21
maybe like an intercom.io style integration, but there's so much more that we can do with sockets. Because chat apps are the hello world of web sockets. They don't add to, like they don't add anything. Like there are features where like if it's a chat app,
11:41
you probably want a chat app. But just adding chat to an app doesn't make it awesome. And so as we show people, hey you can use action cable, here's a chat app. It's sort of like, but that's not where the real value proposition is.
12:02
Because most apps don't need chat between two different users. Like Facebook, sure, another social network, maybe? But like I implore you, when you go and you try this out, don't just add chat to your existing apps as a way to check out action cable.
12:21
But some apps do need communication between the server and the client. Like if we're building unsocial apps, there's big wins on what action cable can get us. Use case number one as I see it is collaboration. So this can be as complete as a big Trello style
12:43
where we're both editing the same document or the same card or somebody adds a card and it shows up on my page. Or maybe a price changes on a website, inventory changes, stuff like that. It'd be nice if I'm viewing everything, if it did update rather than later on on another page load.
13:03
Use case number two, asynchronous tasks. So if you were to implement a task that the server needed to do, say like fetch all new data from a third party or something. Maybe it's something like create a PDF from an invoice. You'd likely throw it on an action job and poll for when that's complete.
13:22
It's not easy, it's not rocket science either, but it's doable, but action cable can make that fun. Okay, so the first action cable beta. So again, more with the history and then we'll get to code, I promise.
13:42
Okay, so last year, action cable was announced as vaporware. It was announced with a diagram, but no code. This is the diagram. Now not too much later, July of 2015,
14:00
we got our first look at the code. That's only a couple months, so as far as vaporware existence, that's not all that long, but it was a non-rails experience. Now, it was only version 0.0, but trying it out was a little bit rough.
14:23
So there are no generators, no deployment story, no standalone, no in-app version. And again, this is version 0, and here I'm complaining about it. I was able to get it to work, but it was a pain, sort of like diving into the source code pain
14:41
to try and figure stuff out. And that's not necessarily the rails way. So I'm glad it existed, and I bring this up to say that if you tried it then and didn't like it, now is a much better experience. The core is still there,
15:01
but it's got the nice sugar, too. So the current beta version, 5.0.0 beta 3, which syncs across rails versions was released in February 2016, and I was sort of like this.
15:24
True story. So it made all the things that I had enumerated about for this talk, like do this, don't do this. If you want unauthenticated users, you have to monkey patch this, and it made them all just go away. It was great, and I was happy.
15:44
So finally some code. Let's talk about building blocks. So the modules. So what makes action cable action cable? There are four distinct modules. So the first is the cable.
16:02
So this is the actual connection from client to server. So it's what is connected to. So it's like it lives on messages go back and forth without having to reconnect. So then you've got a channel.
16:21
All right, so you've got your cable. That's the actual connection. Then you've got a channel. The channel is the thing that is sort of a room. It's what you listen for events. So a channel is on the rail side, and it has a stream name that can be like all products, or it can be scoped down to a specific user
16:40
like cart underscore, like that user's ID. Broadcasting is sending information out from rails through the channel to the client. And then you have a subscription. Subscriptions on the client side. Generally this is just JavaScript. Doesn't have to be, but an action cable is JavaScript.
17:02
And it's the client side. You listen and you receive data from the server. Let's dive into each of these. So the cable, the actual connection. My examples in these are gonna be in JavaScript, not CoffeeScript.
17:20
So you can easily make these go to coffee at like js.coffee, but these are gonna be JavaScript. So what we do here is we require the action cable library, all the channels, and then we create like a big app object. If it doesn't exist. And then we slide the cable onto the app global object.
17:42
So in general, like this is what exists, app dot cable on your JavaScript side. On the rails side, we tell it to process sockets in process. So this is async at slash cable. This is sort of the easy way to do it.
18:01
The slash cable's configurable, but this is sort of assumed to be the convention that you'll use. That's the actual connection between the two. So let's look at channels. On the rail side, a channel is like a controller.
18:21
So it groups sort of ideas together. So you might have a products controller, maybe an inbox, a stream that's like specific to that user of updates. Think about this as like on Facebook, maybe you've got a stream on the right for like all your updates of what people do,
18:41
and then maybe you've got a stream in the middle for your newsfeed. So they group together. So each channel has a connection, and it inherits from application connection. So this is very much controller inherits from application controller.
19:03
So here's where you would tell this connection that you have a current user object. So identified by current user enables you to use this later on. It enables you to be able to say that your channel is only for a specific user.
19:21
And on line seven here, we see what happens when the channel's connected to. So when the channel is connected, we find the user. So user.findby id of cookies.signed user id. So we'll come back to this in a little bit, but notice that it's cookies.signed, not session id.
19:40
So you don't have a session, but you do have cookies. But since you have cookies, this could be in application controller if you're using like your password, what you might do here. So you would say on line nine, cookies.signed of user id is the user.id,
20:03
and then on line five, user.findby id is cookie.signed. So you would switch from a session of user id to cookies.signed of user id. I have a Devise example later, for like the 90% of you who are wondering how to do this with Devise.
20:21
So just hold on, it's coming. So let's talk about broadcasting. So here I am using an action job to broadcast out the message to a JavaScript channel. That'll send it up to the client. So line six shows how to send it out, so actioncable.server.broadcast.
20:42
And then you give it a stream name and a hash. So that hash would be the data that's gonna be sent up. That hash, you'll send it out as a hash, it'll be received later in JavaScript as just a JavaScript object. So this can be done anywhere, break tasks, action jobs, controllers, model callbacks,
21:04
like anywhere in Rails has the ability to send out broadcasts, which is cool. Also here, I'm doing the actioncontroller.render, which is super awesome, I think we're gonna look back and see this as a very cool feature.
21:21
We'll go into that a little bit later. Finally, you've got a subscription. That's the JavaScript listener. So when you create a subscription, it listens for all broadcasts for that channel. So when the server broadcasts a message,
21:40
it calls the received function, and that's where you get your data. So app.product is equal to app cable subscriptions create, and then you've got connected if you wanted to log that, disconnected if you wanted to log that, and then received. Received is sort of magic function, like that's what you need to call it. That's when I broadcast from Rails up to JavaScript,
22:02
that's what it calls. And then you can do whatever you want with that data. So here it's like data.product.id, but you can do whatever you needed to with this. Here I'm saying let's find a product with the data.product.id of that ID and replace it with a template. So in this example, Rails is sending up the updated template for that product,
22:23
and it's just gonna re-render right on top of it. So let's walk through a standard action cable interaction. We'll start on the client side this time. So by requiring action cable, the cable cables to the Rails cable.
22:44
The browser then upgrades the cable connection to a WebSockets connection. When the subscription's subscribed, a connection connects. And then to start listing for updates,
23:01
you create a subscription with the received function. That's what it gets called. So you can have many subscriptions in like many different places. So what I mean by that is like, app.channel or app.cable.channel is this global thing. So anywhere in JavaScript, you can access it.
23:23
So it could be your standard jQuery style, like listen for the event, or it could be in React, like on the component it mount. It could be in Angular, it could be in Ember, on the setup controller. Any of these things can create a subscription
23:42
and start using it. So the subscription calls receive data when the subscription receives the data, and that's it. This is a Tron DeLorean. I love Giphy.
24:02
So let's talk about patterns, like how we might set up for specific scenarios. First, we'll talk about data updates. So this is what I basically call collaboration. But we can keep data in sync across tabs and users.
24:26
In sync, I'm sorry, not sorry. So here we're looking at a pretty sweet browser setup. It's got four tabs. Up in the top right is the cart button.
24:42
That's a cart. And we're selling tennis balls, so those are tennis balls. So that's your add to cart button. I'm telling you, I'm pretty good. But we're looking at like four tabs because the middle two are like on this site. Because I don't know about you, but I'll go to Amazon and I'll do a search and they'll be like, open a new tab, open a new tab,
25:01
open a new tab, open a new tab. So I've got like all of these open that I can flip through. So if we add the cart on tab three, there's now one item in our cart. But what about tab two?
25:20
It's typically not updated, right? It's typically sort of, it was, it'll show whatever was on that page as it loaded, but not update itself, even though tab three updated itself. It's not a huge thing, but like what could we do to make this experience even slightly better?
25:41
So after the update happens, like in a controller or a job, you would broadcast a message. The message can be data, or it can be a rails rendered template partial for you to update with.
26:00
So this is the application controller dot render. So when I heard about application controller dot render, I was basically like dancing the dance of joy. So I've wanted this for so long. The use case that I have for it is like creating reports. So each month you'd want to create reports using whenever, like a rake task,
26:22
and I'd want to be able to use wicked PDF to take HTML and convert it to PDF. But it's not in a request cycle. Like there is no request at that point. So I had to do some like weird things, man, to like make that work, but now it's easy.
26:41
You can just render an entire part, like a partial or a page. You just hand it what locals you think this partial should have. And they can be the same partial that you would use if you're like rendering your cart or rendering out like a list of products. I think it's gonna be really awesome.
27:02
Here's how you could send out new cart partial to a current user only. So you would broadcast to cart underscore current underscore user dot ID. So that would be scoped to just that user. It would only go out on channels where that's subscribed, where you are that user.
27:20
So it's not that like the cable has all of the message. It only has the messages that it's actually subscribed to. Here's the channel setup that would set up the stream. So the channel would have subscribed and it would say streamed from cart underscore current user.
27:40
Both of these have been on the Rails side. So you've got broadcast to a channel and then JavaScript listens for that message. So app cable subscriptions create cart underscore the current user ID. It receives the data, replaces up the template.
28:06
Now tab two's happy. We can also sort of hook into existing JavaScript libraries. So maybe like you change a graph, update some options. Can action cable be used to send messages to the server?
28:21
Did something happen on the client? Yes, it can. So if you want to send a message to the server and then out to other clients, here's an example for you. So the example that I've got is like an HTML five slides presenter mode. So imagine that this is like reveal JS
28:43
and we're all looking at it. So you'd be looking at sort of like a read only state. I'd have the ability to change the slides. And so what we would do is you'd add an event listener.
29:04
So you'd add an event listener to the slide change. Now that's reveal specific. So all of this is predicated on your JavaScript libraries having hooks that you can tie into. But what gets sent from client to server when you say app dot slides notification
29:22
dot advanced slide and then you send it some data. So the slides notification, that's the channel name. And then you've got a channel method on advanced slide and then you send it the data. So app dot slides notification dot advanced slide. So advanced slide is the method
29:42
that JavaScript will call to tell Rails that something happened. So here we say app dot slides notification is the app cable subscriptions. So this is setting up the subscription. The previous slide was using it. And so we say advanced slide. So that's the function that we called
30:01
when we said app dot slides notification dot advanced slide. This does this dot perform slides data. Back on the Rails side, we have a slides channel. So this streams from slides. That slides string is the name of it.
30:23
So earlier, one too many. So on line six here we say perform, perform on slides and send it the data.
30:41
That slides becomes line three here, stream from slides. And calls the line six slides method. So that is what comes in from JavaScript back to Rails. So there's the broadcasting out and then the receiving message back. So line six here, slides of data. We're, I'm just gonna say, if current user dot admin,
31:02
admin, then action cable server broadcast, like broadcast it out again. So what's interesting about this is messages go from client to server. It's not peer to peer. So like this makes sense when we think about it, but if I wanted, if we were all on a server, right,
31:22
and I wanted to send a broadcast message out to all of you I would not send it directly to you. I would send it to the server and the server would send it to you and vice versa as you reply back. So let's talk about collaboration. So Trello, we talked about cards, like that's sort of what it would be.
31:42
Pivotal Tracker, also the cards. But then on GitHub, they do a neat thing where it's sort of complete with yes, no, you can merge, with Trello CI comes back, and then it updates all the other users viewing the page. So this is a neat way that if I like click and merge,
32:03
it's going to other people viewing that page, remove the ability to merge. I think that that's the type of thing that we can very easily get huge wins out of with action cable. Finally, asynchronous tasks.
32:22
So let's imagine that we have a system where we use like mechanize to go out and fetch the latest data. This can take quite a bit of time, so let's throw it in an action cable job, or an action job. So the first thing we do is we generate a channel. So each channel is going to have many streams
32:41
based on like a UUID. So each task that we do would have its own stream. From the JS, you post it up, give it the UUID that defines this job, you would then create a subscription on that stream with that UUID for when messages come back from Rails.
33:02
Maybe you have a site search job that performs search with a UUID, so you have your stream that you broadcast, hey, I'm starting, and then snip, you do all the stuff, and then action cable server broadcast the stream that it's complete, and along with the template.
33:23
And yeah, let's go ahead and discuss chat. I read that there's this concept of iMessage on iPhones, lock-in, that people really love seeing the bubble like when people are typing,
33:41
that it makes it feel sort of instant, that you're connected to someone, like there's an actual person that's actually typing right now. So, oh, come back, come back. So Aziz Ansari talks about this in Modern Romance.
34:01
So, he asked someone out, he saw the bubble, but then nothing, like the bubble just went away after a while, and he never got a reply. Sad face for Aziz. But there's this sort of emotional thing with this. Okay, so what would you do? So you could listen for the keyup event on a text area,
34:21
and then tell the server that you're typing in, that you're typing in the conversation between you and Taylor Swift. Then, when the message is sent, you would stop the bubble, and render the message text, and maybe you would handle if you haven't typed in a while.
34:40
End of chat. Let's talk about deployment. So, in-app mode is basically easy mode. Think of it like you'd use Sidekiq, not inline jobs. So you're not doing Sidekiq, it's just inline. It works, but scalability is a thing. So, it can be done with only one server,
35:01
no rescue Sidekiq, like you can just say that everything is inline, everything is async. So, you would tell it, my queue adapter is async, and then my config, cable.yaml, async, async, async. Everything is done async, so that's just threaded. It connects to slash cable on the rail server,
35:23
and generally can work pretty well. But, if you've got more than one server, like you've got multiple dynos or whatever, then you wanna use Redis. So you wanna have server, server, Redis, and Redis will keep it in sync. Otherwise, everything's just gonna be in memory
35:40
on each server, and that's no good. Because if I connect to one server, that's a physical connection, you connect to another dyno, we have to have some way that I can actually pass messages back and forth. Redis would be that. Standalone is basically hard mode. It's slightly more involved.
36:01
It's the same scale as sort of moving from async to Sidekiq. You connect via Redis. You've gotta have an actual, like sockets.domain.io. You gotta configure where it is so it knows how to connect.
36:20
More with our person. So, our green person connects to Rails. Again, you're welcome. When you broadcast, it sends the message to Redis. Action cable is listening for that, and then action cable sends it back out. So, quick likes and gotchas. So what about missed messages?
36:41
Like, I don't think we know yet what this story sounds like. But I think we have to think about the idea that if I'm just sending update, update, update, update, and you miss some messages, you go offline. Like, what does that look like? In a physical, like it's a physical network connection to somewhere in the world.
37:01
So, you wanna use action job, don't inline, like just broadcast it out in your controller. Because it would have to send like somewhere along the world. Don't wait for that. Also, no session, only cookies. So here is your devised version.
37:21
You're welcome. You have to configure your request origins to allow or disallow people to be able to connect to you. Fun fact, don't leave a trailing slash in the host, because it will not work. And finally, the config.cable.yaml default setup.
37:44
This is what gets generated. The production URL for Redis is localhost. You'll need to change that. So where do you go from here? So I've got a simple example that you can look at.
38:01
JoO slash inventory cable. There is also action cable examples. These are very good. There's documentation on this URL. But, so action cable's part of the Rails standard,
38:20
just like action controller. Finally, I wanna give some many thanks. So thanks to DHH for having the idea, announcing it, making it happen. Like, this is very cool. The 42 plus contributors on the action cable project, you all rule also. And thanks to the Iron Yard for paying for me
38:42
to come here, spend today with you. So we're hiring developers across the US that wanna learn how to teach, make the world better, change lives, improve diversity. So if you're interested, tweet at me, come talk to me. I'm Jawa, thank you very much.