Speakerline
Speakers
Proposals
Events
Tags
Edit a proposal
Adam Cuppy
Ahmed Omran
Alan Ridlehoover
Amit Zur
Andrew Mason
Andrew Nesbitt
Andy Andrea
Andy Croll
Asia Hoe
Avdi Grimm
Ben Greenberg
Bhavani Ravi
Brandon Carlson
Brittany Martin
Caleb Thompson
Caren Chang
Chiu-Ki Chan
Christine Seeman
Cody Norman
Devon Estes
Eileen Uchitelle
Emily Giurleo
Emily Samp
Enrico Grillo
Espartaco Palma
Fito von Zastrow
Frances Coronel
Hilary Stohs-Krause
Jalem Raj Rohit
Jemma Issroff
Jenny Shih
Joel Chippindale
Justin Searls
Katrina Owen
Kevin Murphy
Kudakwashe Paradzayi
Kylie Stradley
Maeve Revels
Maryann Bell
Matt Bee
Mayra Lucia Navarro
Molly Struve
Nadia Odunayo
Nickolas Means
Noah Gibbs
Olivier Lacan
Ramón Huidobro
Richard Schneeman
Rizky Ariestiyansyah
Saron Yitbarek
Sean Moran-Richards
Shem Magnezi
Srushith Repakula
Stefanni Brasil
Stephanie Minn
Sweta Sanghavi
Syed Faraaz Ahmad
Tekin Suleyman
Thomas Carr
Tom Stuart
Ufuk Kayserilioglu
Valentino Stoll
Victoria Gonda
Vladimir Dementyev
Title
Tags (comma-separated, max 3)
Body
# Abstract Modern web applications actively use real-time features. Unfortunately, nowadays Ruby is rarely considered as a technology to implement yet another chat – Ruby performance leaves much to be desired when dealing with concurrency and high-loads. Does this mean that we should betray our favorite language, which brings us happiness, in favor of others? My answer is NO, and I want to show you, how we can combine the elegance of Ruby with the power of other languages to improve the performance of real-time applications. # Details I want to start this talk with the brief overview of the history of the real-time web concerning Ruby (from Bayeux (Faye) to ActionCable, from long-polling to WebSockets, from EventMachine to nio4r). This part of the talk answers the following questions: What is real-time web? What tools/techniques/protocols have been developed? What is the current state? Then I state the main theme of the talk: although there is a lot of Ruby solutions we more often choose other technologies (Golang, Elixir, NodeJS, whatever) to build real-time applications. Why? First of all due to the well-known Ruby (MRI) limitation – Global VM Lock – and how it affects concurrency (which is the key of real-time). Here I show benchmarks (different Ruby implementations vs. Erlang/Golang/NodeJS implementations) based on WebSocket Shootout by HashRocket. That should make the problem clear to everyone. After stating the problem I should propose a solution, shouldn't I? And that's exactly what I'm going to do. I want to introduce a tool which aims to solve the problem – AnyCable. AnyCable allows to extract low-level WebSockets manipulations into a separate service (written, for example, in Go) and to leave all the business-logic in your favorite language – Ruby! There is a secret ingredient – gRPC – which provides blazingly fast and effective communication between languages (in our case – Ruby and Golang/Erlang). I'm going to tell the story of AnyCable: How did this idea come into my mind? Why did it take so long to build a prototype? etc. So, this talk shows how can we use Ruby with friends to improve overall performance (and that's I'm considering it to be in "Ruby and its' Friends" track). Although AnyCable sounds like Rails's ActionCable, it is completely Rails-free, it's just Ruby! It uses Action Cable communication protocol – just to not re-invent the wheel and be interoperable with Rails. To summarize, this talk: - Sheds light on the history of real-time applications in Ruby - Shows the way to effectively combine different technologies/languages. The first, retrospective, part of the talk is for everyone from the newcomers to Ruby-ninjas. The second part is more technical and requires some knowledge (networking, resources usage). So, it's for advanced users struggling with performance limitations. # Pitch The key idea of the talk is not to promote the tool (AnyCable), but to share the way of building hybrid (symbiotic) applications. The idea is spiced with a real-life example and a bit of history – just to provide the context. The talk is focused on one of the most "popular" Ruby "weakness" – performance. And performance matters, doesn't it? This talk is also about gRPC – an evolving technology born in Google and used by, for example, Netflix and CoreOS. And, in my opinion, it's still underestimated. That's why I want to show, how we, Ruby devs, can use it. My personal goal as a speaker to convince Ruby developers not to give up their favorite language in favor of hype-ful superperformant things (unfortunately, such bad things happen) but to learn how to use the best of both worlds.
Back to Speaker Directory