Vladimir Dementyev

AnyCable - Universal Action Cable
Vladimir Dementyev • October 12, 2017 • Selangor, Malaysia

Speaker: Vladimir Dementyev (@palkan_tula)

Website: http://rubyconf.my

Produced by Engineers.SG

RubyConf MY 2017

00:00:06.990 thank you how is its work great yeah
00:00:13.679 cool so I don't know what to sales involved
00:00:19.590 myself and about any cable so let's start first of all let me introduce
00:00:25.320 myself oh I forget yeah so my name is Vladimir which is not so
00:00:32.399 is it to spell and to pronounce because that's why I told you just call me Vlad or John let's see this wait I use it
00:00:39.660 everywhere in Starbucks and other places where someone asked me how what's your name well and my iPhone is called Jones
00:00:47.399 iPhone if you want to send me something through a drop use it I came here all
00:00:53.340 the way from Moscow with a little stop in Bangkok not so long flight as from
00:01:00.150 other speakers and I'm leaving the same continent actually but very far and then
00:01:06.689 Malaysia you can find me on github and on Twitter well try to post some
00:01:11.750 programming late related stuff and sometimes gets I can resist well and
00:01:19.580 continue I want to continue to them Acuras talk with this kind of
00:01:25.310 description of myself so I'm a rubbish that's why I'm here I'm a rails commuter
00:01:30.360 well it's oh do not be so fast and I'm
00:01:35.640 not a Rubicam eater yet but I am Rubicon meter if you know what is it if you don't know feel free to ask me after my
00:01:42.600 talk I'm not going to talk about M Ruby now maybe someday later I'm walking into
00:01:48.390 emotions our original logo is like that not like that it's my own it's a only
00:01:54.869 one like this and we work in on commercial projects that's not interesting and we're working on open
00:02:01.260 source projects a lot of them some of them are on this slide maybe you know
00:02:06.750 something I hope you know at least one and if you're not are going to talk about one of these today
00:02:13.099 so enough introduction let's go and before a start I have to drink sorry
00:02:21.099 I know do you know what this guy
00:02:28.750 that's the first servo man in the space
00:02:34.140 okay any cable Oh wrong button sorry
00:02:40.170 that that's it what is any cable well any cable sounds
00:02:46.030 very similar to action cable yeah and it's weighted to it actually it was
00:02:51.600 built to solve some problems of action cable but if I start about my project I
00:02:59.260 would like to remind you what is action cable by the way who knows what is it
00:03:04.720 who try it not so much who tried to do WebSockets and Ruby and other languages
00:03:13.080 okay try to explain you what is going on here so action cable action cable was
00:03:22.570 introduced by DHH turn 1/2 years ago at railsconf atlanta and it was kind of
00:03:28.570 surprised nobody knows that they're gonna be new feature a new framework
00:03:34.720 within rails even rails core team members didn't have an idea that it
00:03:40.900 exists well yeah I mean I didn't ask you
00:03:48.190 about using your tweets but they're gonna be a couple of more so what is the
00:03:54.489 action cable action cave it allows you to connect to your rails application through WebSockets it consists of
00:04:00.700 several parts the main part which works with WebSocket connections let's go it
00:04:06.010 server then we get a broadcaster that's part which is responsible for routing
00:04:12.010 messages between clients between sockets using abstract streams and channels
00:04:20.200 framework as a code so it's some kind of frameworks which is also to write
00:04:26.140 business logic for your WebSocket connections and the typical channel looks like this it's really simple but
00:04:32.910 let's give you an interview what is it like it's very similar to controllers
00:04:37.990 but you don't want to work with request response cycle you want to render anything course but you can actually you just
00:04:45.220 manage how clients connect to streams which streams they can connect way and
00:04:51.220 cannot chat so on and so forth so it's kind of abstract controlling
00:04:56.590 framework channels and so surprisingly announced action cable was held accepted
00:05:03.370 by the community a lot of Wow sit schoolteacher we waited for a tails five
00:05:08.680 rules not but everyone of course and I'm not going to tell about whether I'm live
00:05:15.490 action cable I hate you're gonna figure out it in the end of my talk and I know not gonna convince you and being a hater
00:05:21.580 a lover I'm just want to discuss the bad parts and the good parts of action cable
00:05:26.909 so the good parts explains why it's so popular and the bad parts explains why I
00:05:33.099 don't use it in this in the row in the wait is now so good parts the first good
00:05:42.129 part actually is the fact that action cable is just built in into your rails application you don't need anything
00:05:48.400 almost zero configuration choose to start running your WebSocket server to
00:05:54.699 bring real-time functionality into your application wow that's cool because
00:06:00.520 previously we had some solutions written in Ruby but set required some hacks some
00:06:06.279 additional coding to set up and run the second good part is channels framework
00:06:12.370 because I already mentioned because it allows you to communicate not chemically but to access your business logic you
00:06:19.750 owe your application your model services etc from within WebSockets so it's not
00:06:25.690 only to broadcast messages to clients like Carol some pass services like
00:06:32.080 Buescher and so on it also allows you to accept messages from sockets and do some
00:06:38.729 meaningful stuff that's great so we get full access and the third kind of good
00:06:46.210 part it's J's client that just works and so we can just include it into a page
00:06:52.360 and use and if you do not want to modify it it's okay if you want to fired its CoffeeScript and caucus
00:06:58.059 creepers for me dead I don't know what's written in CoffeeScript it's hard to do
00:07:04.449 some changes within the framework but do what we have what that framework will
00:07:10.149 work it handles disconnections half dead connections and so all so it's ok but
00:07:17.740 what about the bad parts well let's
00:07:23.379 start with simple one action cables WebSockets only and you may say well it's ok everyone has WebSockets actually
00:07:31.029 not even now in 2017
00:07:36.999 WebSockets already eight years old but we still do not have the full support
00:07:42.639 and in Malaysia for example it's only about 92 percent of browser support
00:07:48.240 WebSockets that means that you cannot use WebSockets for some crucial part of the
00:07:54.520 application because some users might have not support and typically web
00:08:00.039 socket frameworks support some fallbacks for long polling for example but action cable does not and the bad part here is
00:08:07.180 not said no callbacks okay that it's internals highly coupled with web socket
00:08:12.879 implementation it's not easy to just write long pole and adaptor for action
00:08:18.279 cable it's going to be complicated that's not a big problem this non Y
00:08:23.649 action any cable was born but the next program the first one of meaningful
00:08:29.529 problems memory usage well I'm going to
00:08:34.569 explain it with a simple chart which compares similar applications written in
00:08:40.510 a rail section cable and other languages such as Galang and airlock they all
00:08:48.850 doing the same thing we just connects 20,000 connections to the server do not message do not broadcast messages
00:08:57.250 nothing else just connect and handle so as you can see
00:09:03.100 we need much more memory when we use Ruby action cable to handle too many
00:09:11.699 WebSockets and 20 thousands it's not that big for high load application
00:09:16.779 actually I compare two configurations of action cable because well of course we
00:09:24.220 can scale action cable by multiplying the number of workers and we needed to
00:09:29.680 make it real time and I'll show you in the next item and we talked about performance what doesn't mean performance here I
00:09:37.690 want to assess real-time features of action cable how it how real time is action cables real time how it's real
00:09:45.370 how slow how small is that message broadcasting latency because for me in
00:09:54.009 real time I've been working on video conferencing pod for many years so that
00:09:59.319 that time those days real time meant for me less than half a second that was real
00:10:05.050 time what is more it's not real time of course not everyone needs such a small
00:10:11.980 Levin seat but let's go to benchmarks I'm gonna use ready to run benchmark
00:10:19.240 from hash rocket company called WebSocket shootout they build a
00:10:25.839 benchmark and run it against about the dolls and implementations of WebSocket applications written in different
00:10:31.959 languages from C+ pass to go and no GS and of course action cable
00:10:38.589 what is the benchmark about we measure the time it needs a WebSocket server to
00:10:47.079 broadcast a message to everyone so let's
00:10:52.209 try to be simpler let's imagine I'm a server and you all are WebSockets you
00:10:57.730 connect it to me when someone of you tells me a message say ruby school I had to tell this
00:11:07.360 message to everyone else to you Ruby school Ruby's school Rubisco and so on so forth it will take him an hour for me
00:11:13.690 I think so the amount of time I need to rebroadcast this message to everyone
00:11:19.300 that's way what we measures that's our main metrics so the less time we need
00:11:28.120 the better our performance from the real time point of view so let's go to
00:11:36.220 benchmarks please keep Siri because they're not so they can shock you so
00:11:45.690 what's going on here first of all election cable running on only using two workers is definitely not real-time
00:11:54.899 we're more than 10 seconds on 3,000 of connections well it's not real time at
00:12:00.850 all you can't communicate with for example in chat with someone when there is 10 seconds delay with 16 workers if
00:12:09.399 you can't afford it it's not cheap I run it and on 16 core virtual core on Emma's
00:12:17.860 on well it's better but it's gross kind of linearly on the number of connections
00:12:24.310 although Ellen can go long implementations feels feel quite good
00:12:30.610 only about a second on 10 thousands of connections and I hope to notice that
00:12:35.800 they're all connected to the same stream so we measure the broadcasting time well
00:12:41.410 that's how it explained what's going on here and it can be explained in in this way I don't want to say that action
00:12:47.649 cable was bad don't use it no it's not like that action cable force you to choose between
00:12:54.129 low latency and crowded channels so if you want to look at messages when your
00:13:02.529 stream and so serves about all dozen of glands so maybe hundred it's okay it's
00:13:09.129 going to be low latency it's normal but if there are thousands of simultaneous connections latency grows and it can be
00:13:17.709 not suitable for your application so that's one of the problems I want to
00:13:22.779 solve with any cable and last but not least let's consider a CPU usage because
00:13:28.629 we pay for that and just show you this it is up and down no messages
00:13:35.259 broadcasting messages no messages broadcasting messages kind of no room
00:13:40.419 for anything else on this server so how
00:13:46.179 to solve this problem there is one way
00:13:52.049 we can choose just which were rails will be free you know it's gonna be pretty
00:13:57.399 cool better concurrency models think less memory consumption I don't know how
00:14:06.189 long should we wait as I know it's gonna be 2020 at least as I know so two years
00:14:16.859 for someone maybe that's a solution but I want to talk about
00:14:22.810 the solution I came up and Weez about a year ago and it's called any cable no that's the
00:14:31.690 beginning of the main part of the talk just to remind you so action cable is just four blocks server streams
00:14:39.220 broadcasting art channels just abstract logic and the client which actually is
00:14:46.630 just a protocol you can implement it in any language but there is a protocol and
00:14:52.110 we already know that the server itself is not so good when you're doing with
00:14:58.029 high load applications other parts are good they use full they they easy to use
00:15:04.750 the rails way you know etc what if we can move this part out of action cable
00:15:12.339 to somewhere else to handle WebSockets differently and to handle our business
00:15:19.810 logic and our good old action cable that was the initial idea I came to my might
00:15:26.910 many years ago well those years I was programming in Erlang we already have
00:15:35.670 WebSocket server I was thinking about something like this so we somehow
00:15:41.649 broadcasting messages to along kids can be just plain HTTP or ready sub pops up or whatever and the airline server which
00:15:49.149 is handle all the clients somehow translate action cable commands just
00:15:55.360 action cable protocol to our rails application well that's the problem how
00:16:00.670 to solve this part I had no idea well I had an idea or building my own
00:16:06.819 binary protocol over TCP but I thought it wasn't easy to come pleat in a
00:16:13.089 meaningful time and then I found this project
00:16:18.240 this process called GRP see which can be stated as google RPC but officially
00:16:25.980 people from google denies this version no no it's not about Google but I think
00:16:31.800 it's about you go because it's built within Google and is already used in
00:16:37.019 some api's it's Universal RPC framework
00:16:43.019 what does mean Universal well the idea behind it is to connect server and
00:16:48.389 clients written in different languages easily so we don't have to use specific
00:16:53.759 language to use their PC you only have to be able to compile your messages
00:17:01.139 using protobuf and transport transfer transfer it them using HTTP 2 so that's
00:17:08.130 exactly what is j RPC is based on and if
00:17:13.230 we're talking about ruby gem for g RPC it's actually a lot of C code wrapped
00:17:19.909 with a small amount of Ruby which make
00:17:25.140 is it fast but hard to change to fix to
00:17:30.750 modify to do anything if you don't know C well okay I found UPC I thought let's
00:17:37.860 do that but then I realized no not every language is supported where is my
00:17:43.440 favorite language called airlock favorite after Ruby of course so no no
00:17:49.140 airlock so I had to learn go and that's final
00:17:54.950 diagram which shows how any cable works what is it so we still have our rails
00:18:01.919 application database and we got WebSocket server with an in goal and
00:18:08.100 which connects using gyre PC to our PC server server which is sexually your
00:18:17.010 Royals application with different endpoint GRC endpoint and we also use
00:18:24.570 for now ready to broadcast messages back to WebSocket service when we need to
00:18:29.700 do broadcasting actually so let's the final diagram okay why did I do that
00:18:37.859 what's the reason was let's consider some benchmarks for now I have two
00:18:47.809 implementations of WebSockets servers compatible with any cable two projects
00:18:54.419 one in go long and finally invented Jerry PC for airline can build their own
00:19:00.570 commercial because I'm more comfortable with and then who is going let's start
00:19:07.409 with memory and we can see that memory which we need to run our PC server and
00:19:15.739 for example go or go server to handle web socket is less than memory mean for
00:19:24.149 action cable much less and it's about only twice more than we need for native
00:19:30.269 goal and application without anything like I proceed so on so it's pretty good I mean it doesn't grow fast CPU usage
00:19:41.719 well I think it's much more better for a lung
00:19:48.269 it even much more preachy because Ireland scheduler is better than golang scheduler it's uniformly distribute the
00:19:55.710 work and just to remind you how it was resection cable so we save a lot of
00:20:01.590 resources we don't need actually the 16 course we I think for course is enough
00:20:06.629 for doing the same thing and it's about four times cheaper what about broadcasting time actually
00:20:14.429 that was the reason why I was doing all that that Chester okay well it's almost
00:20:21.149 the same as using simply WebSocket written in go and or web second reading
00:20:26.519 airlock and I was surprised when I first surround this benchmark I was afraid that well I introduced your PC and maybe
00:20:32.999 they're going to be bottleneck maybe they'll be not better than action cable because it's just Ruby and here we got
00:20:39.169 for every message we just passing it through Jerry PC to Ruby but it turned
00:20:45.239 out that it's works and works pretty good and it solves our problems actually
00:20:52.440 so looks like we solve all problems let me demonstrate I got a live
00:20:57.960 demonstration I don't I don't want to run and rerecord it what does it mean in
00:21:03.419 terms of comparison the same kind of fake chat the right side is connected to
00:21:10.889 any cables the left side is connected to action cable so here we can see the lag between the messages so any cable works
00:21:19.320 almost real-time it's less than half seconds every time an action cable is
00:21:24.720 not so good and the good part of any cable is that it's easy to use as almost as easy as
00:21:31.669 action cable because all we have to do is just to add a few lines into your
00:21:37.340 configuration and jam file and run required servers that's it
00:21:42.840 and now you have the same application working much faster and consuming much less resources and
00:21:49.460 action cable now we still use action cable channels we do not rewrite any
00:21:54.500 business logic code that's the idea behind any cable we don't want to write
00:21:59.540 WebSockets differently completely we just want to remove low-level stuff to somewhere else and when I say that you
00:22:08.630 can still use your action cable channels I should tell about some compatibility
00:22:15.590 issues not all features are supported currently we're going to eliminate all
00:22:20.630 this - minuses in the future but for most application that works well you can
00:22:29.690 read more on our website it's got beautiful animation which explains how
00:22:35.900 it works and find all the great information on github and Twitter that's
00:22:42.170 not the end so although initially any cable was built to make action cable better the
00:22:50.180 first question I was asked on github well cool how to use it without action
00:22:57.020 cable with Sinatra or whatever I don't want to use rails I want to but I want to use WebSockets in my Ruby application
00:23:04.780 hmm I didn't think about it initially but I decided to well close this issue
00:23:11.290 by adding support for non rails project but to add support on on Rails project
00:23:18.380 means that you have to rewrite action cable channels part and that's how light
00:23:24.770 cable was born so what is it it's actually a kind of refactored and
00:23:29.810 reimplemented action cable channels framework with no dependencies at all even active support
00:23:35.030 and it's comparable with an affection cable protocol so we can use the same
00:23:40.550 J's client and it's out-of-the-box compatible with any cable without any market watching actually the result of
00:23:48.470 my work on action cable itself there are several proposed pull requests with
00:23:54.020 action cable refactoring to reduce hi coupling not here at marriage I got I
00:24:00.629 think never marriage because oh that's another problem I won't talk about well that's why I build a live cable and it's
00:24:06.719 already been used yeah that's how it look with just wreck
00:24:13.109 so replication with cable and it's already used by people who for example
00:24:18.989 use Konami they integrated light cable and any cable to Konami building such
00:24:26.369 theme plays another cable networks in production it's cool it's project leaves
00:24:34.889 under my profile and some more cool
00:24:41.009 stuff so as I told you the performance was the main reason why I decided to
00:24:46.080 build any cable but while building it I realized that there are other
00:24:51.859 possibilities to improve action cable
00:24:57.690 with any cable using any cable is much easier to do with any cable for example
00:25:04.460 the problem I was stated in the beginning of the talk a lack of transport for pullbacks is easy to do
00:25:10.889 when you use separate web socket service which handles all the communication
00:25:16.739 between the server and user because from the rails our cable app point of view
00:25:22.889 it's gonna quack like a circuit it it won't be necessary web socket it can be
00:25:28.200 anything and any anything you can choose TCP socket you can choose long polling
00:25:34.979 and connect it to any cable WebSocket server which translate this message is using their PC into action cable
00:25:41.999 protocol and there is no difference between the way to connect so this way we can solve this problem currently my
00:25:50.820 implementations doesn't support fallbacks because I don't need it but if I will need for example support old old
00:25:57.570 browsers on mobile browsers I will just add ready to go solution for long polling unconnected to
00:26:04.710 any cable and that's it that's all we have to do so this problem we can so
00:26:12.059 there is one more problem with section cable which I gonna demonstrate using
00:26:17.520 this example projects which use action cable in production no no no this cable
00:26:23.640 the problem of this consistency action cable doesn't have anything to make your
00:26:32.750 kind of message passing consistent and
00:26:38.240 this can be situation when in two
00:26:44.400 different windows yeah we see we got different comments this one is not here because while we were load in the page
00:26:50.789 there was a transmission into action cable but we not yet connected to action
00:26:57.390 cable and we subscribed only after the page has been loaded and it doesn't contain this message the same thing
00:27:03.240 happens when you're for example walking on the streets and going to the metro and the underground you lose connection
00:27:09.780 for a second then some message is passing in you come up on the ground and
00:27:14.789 you don't see that action cable doesn't provide any tools for that and I think it is because it's not easy to handle
00:27:21.929 this just using Ruby without introducing external dependencies for storing messages it won't be effective efficient
00:27:29.370 but using airline go along whatever we can do that and we do not have to
00:27:36.630 disturb action cable at all we can do this our side at any cable side this is
00:27:42.090 way I gonna do a little bit later I think in the end of the next year if I
00:27:47.549 had time I already have idea how it Hey okay oh oh yeah so an idea of
00:28:00.759 history streams which allows you to store some messages and I automatically push them to newly connected clients to
00:28:07.779 avoid this situation of with temporal disconnect it's it's about features what
00:28:15.850 we can do now I got about one minute I think and oh
00:28:27.029 sorry okay I once all about one idea that came into my mind while I was
00:28:32.259 flying here I was thinking about well what happens when you deploy a new
00:28:39.009 version of your code yes so for example say Heroku I got just get boots and it's
00:28:44.710 to start all the application instances include an action cable instances so
00:28:50.110 what happens oh all clients connected to the assistances are disconnected and they had to reconnect and Reese absque
00:28:55.899 ribe again which can cause some stressful situation to your server but
00:29:01.960 with any cable you don't have to reload WebSocket server because it's logic
00:29:08.559 class it's just a proxy server kind of which translates everything into action
00:29:15.100 cable so it make it can make your deployment I told disconnect less so your WebSocket
00:29:23.740 client should not disconnect to access your new version of your code and if you
00:29:30.009 had a lot of deployments and we had a lot not lot compared to Shopify but
00:29:36.480 enough enough every hour at least so on deployment to sometimes 10 20 so it's
00:29:43.929 not good to ask our website clients to disconnect so with any cable you don't
00:29:49.119 have to do that you have to implement something within WebSocket server to know sometime
00:29:58.809 somehow queue the requests before you connect it as a new version of that but
00:30:04.120 this part shouldn't it be disconnected well and
00:30:10.410 quick list of other features which can be implemented again WebSocket server
00:30:16.750 side without needing to touch Ruby
00:30:21.840 looking at compression we can add better instrumentation currently working on providing different metrics of what is
00:30:28.840 going on within your web socket service how many messages past how many data transferred how many connections how
00:30:35.860 many many many many many so I'm working on it right now because we need it for our project
00:30:41.159 that's a future of any cable and another future feature that you can actually
00:30:47.919 share with sockets several different different applications so because it's logic less it just had to know where to
00:30:54.909 trance to wrote your commands and it could be different applications actually so this way you can consume less
00:31:05.470 resources use one any cable server for different Ruby applications that's also
00:31:11.789 can be a good feature and I think that's all I had to say
00:31:28.000 ago a good answer the first question by myself because I know no question what
00:31:35.000 is the usual question yes the usual question is do you use it in production and I had to answer not yet for a long
00:31:43.760 time but actually we finally launched it in production about a couple of months
00:31:50.240 ago all right and the second question no
00:31:56.630 we do not have millions of connections yet so it's about thousands so actually
00:32:03.110 what what feature we use it's not lower broadcasting time but low memory and CPU
00:32:08.330 usage which is necessary for us because we're running a containerized environment where every container
00:32:14.559 shouldn't consume too much resources well I hope I have faced the problem of
00:32:21.350 high load travelers from the broadcasting point of view of a message
00:32:26.450 trade and so on there's two questions I already answered waiting for your questions okay
00:32:32.240 those are their important ones any more questions sure
00:32:37.650 do you have some built-in analytics for it to solve how many connections you have this what sir was my last slide
00:32:44.370 about I'm working currently working on it so it's I just actually I haven't
00:32:49.950 begun and we just discussing with our DevOps guys what what they want and how they
00:32:57.150 want to take it and I think it's till the end of the year currently I'm
00:33:03.420 working on the pre-release of version out 5 with some features and then I'm
00:33:08.430 gonna start to work on feature on new features not fixing bugs and compatibility issues so yes that's in a
00:33:15.929 roadmap number one I think any other
00:33:21.360 questions on any cable sure
00:33:29.550 hi so I'm currently building a real-time messaging app using action cable and
00:33:36.150 after your talk with I'll definitely consider I mean using any cable but the
00:33:41.530 question is how do I determine when my app goes to production how do Turman how many connections and
00:33:48.940 when it comes to radius about the latency how do I set up all that without just waiting see if the app falls down
00:33:55.300 and then okay I need more I don't want to fall into that I wanted to be prepared about my app requirements so
00:34:04.030 again you're talking about how do I know whether I should switch from action
00:34:09.220 cable giant cable to something else okay yep
00:34:18.919 well yeah according to memory so we can
00:34:24.559 just go back to the slide with memory there is of course it depends on your
00:34:30.859 application because when you load an instance of here with it of action cable
00:34:37.250 you load the whole application for race application actually you don't need a whole maybe we can reduce this amount of
00:34:43.309 memory but for connection well I don't
00:34:49.190 remember how much the same the application itself costs memory but I
00:34:56.089 think it's about so we got about three thousand megabytes for twenty thousand
00:35:03.859 of connections for sixteen workers so suppose that rails itself loads about
00:35:09.789 two hundred megabytes extract this you can reach no think too much no
00:35:17.440 and then divide by 20 thousands and you got something I don't remember I used to
00:35:24.010 count this amount actually how does it cost to handle one connection and don't
00:35:29.980 remember sorry I I should do some maths here it's not so easy and it's going to
00:35:35.530 memory CPU is always always almost always not good when you're broadcasting to many customers so it depends on your
00:35:43.030 work for do you have one channel to which everyone is connected to so for example your trans transmitting some
00:35:50.260 life events for supporting passports so you got one page everyone connected to
00:35:56.890 the same stream and you have to handle a lot of people then you hardly do that
00:36:03.940 with action cable if you your flow is to use you know a stream per user that's
00:36:11.650 okay that's no problem with CPU and broadcasting time only memory limits so
00:36:17.530 we can see it when we run even then you can you can simulate actually so you can
00:36:22.560 take this benchmark just write another scenario which is your app scenario and
00:36:30.420 see what's going on with your server and I have some tools to help you to benchmark you can find it in my github
00:36:38.590 with too right you know declarative scenarios for WebSocket communication
00:36:44.800 and to run it against servers so you can use it for benchmarking - oh well so we
00:36:50.980 can talk about it a little bit later so if you want to estimate how much resources we need there are some ideas I
00:36:59.800 have in my advance too long to talk here now that is a question yep also any more
00:37:09.500 questions okay I'm on guess is anybody
00:37:15.020 else using action cable raise of hands anyone using action cable sir
00:37:21.440 you have any questions any pressing questions nope all right thank you very
00:37:27.260 much another round of applause thank you for adding here
Explore all talks recorded at RubyConf MY 2017
+16