Vox

Leitura de 14 min

17: Volt and Isomorphism with Ryan Stout, part two

Summary

In this second part of the interview, host Jonathan Cottrell continues his conversation with Ryan Stout, creator of the Volt framework. They delve into the technical decisions behind Volt’s architecture, particularly focusing on the use of persistent WebSocket connections.

The discussion explores the rationale for using WebSockets in Volt, with Ryan explaining that while real-time updates are a benefit, the primary advantages are performance-related due to TCP window sizing and the simplicity of push-based communication. He notes that Volt uses MongoDB as its database currently but plans to create a data provider API to support other databases. The persistent connection enables features like automatic reconnection and data synchronization across clients.

Ryan and Jonathan discuss Volt’s design philosophy, which leans toward “batteries included” rather than a micro-framework approach. They talk about how baking common features like authentication into the core framework can foster a healthier ecosystem of reusable components, avoiding the fragmentation seen in other Ruby communities where multiple competing gems create compatibility issues.

Toward the end of the interview, Ryan offers advice to developers, emphasizing the critical importance of code readability, especially in collaborative projects. He shares from personal experience that sacrificing readability often comes back to haunt developers. Jonathan relates this to the common programming challenge of naming things appropriately.

The episode concludes with Ryan sharing resources for those interested in Volt, including the VoltFramework.com website, documentation, Gitter chat for questions, and weekly office hours held on Fridays.

Recommendations

Communities

  • Volt Gitter chat — Ryan mentions he’s always available on Gitter to answer questions from developers getting started with Volt.

Events

  • Volt office hours — Weekly office hours held every Friday from 4-6 PM Eastern time where developers can get help and ask questions about the Volt framework.

Tools

  • Volt Framework — A web framework that allows writing Ruby once for both front-end and back-end code, featuring persistent WebSocket connections and a batteries-included approach.
  • MongoDB — The database currently used by Volt’s store persistence layer, though Ryan mentions plans to create a data provider API for other databases.
  • Nginx — Web server with built-in WebSocket support that Ryan mentions can handle the heavy lifting of maintaining persistent connections with minimal performance penalty.
  • Pusher — A service for adding real-time functionality to web applications that Ryan references as something he’s used in past projects before building similar capabilities into Volt.

Topic Timeline

  • 00:00:48 — Introduction to persistent connections in Volt — Jonathan introduces the topic of persistent WebSocket connections in Volt and asks Ryan to explain his thinking behind this architectural choice. He acknowledges that many developers, including himself, don’t fully understand all the benefits of persistent connections beyond performance considerations.
  • 00:01:29 — Ryan explains WebSocket benefits and Volt’s data persistence — Ryan explains that Volt’s persistent connection is specifically for the “store” data persistence layer, which currently uses MongoDB. He discusses the performance benefits of keeping TCP connections open due to window sizing, the push capabilities for real-time updates, and how modern infrastructure like Nginx makes maintaining WebSocket connections practical with minimal performance penalty.
  • 00:04:25 — Practical applications of server push — Ryan shares from his experience that many projects eventually need some form of server push, even if not strictly real-time. He gives examples like file upload processing notifications, noting that having WebSockets as a base feature simplifies development compared to dealing with XHR timeouts, polling, and other workarounds.
  • 00:05:08 — Volt’s suitability for high I/O applications — Jonathan observes that Volt’s persistent connections and document store model make it well-suited for high input/output applications with lots of message passing. He expresses excitement about this direction for Ruby developers who have traditionally worked with systems less optimized for such interactive applications.
  • 00:06:20 — Framework design philosophy: batteries included — Ryan discusses Volt’s design philosophy, positioning it between micro-frameworks and monolithic frameworks but leaning toward “batteries included.” He explains how standardizing core features like authentication enables a richer ecosystem of reusable components that can assume those features exist, avoiding the fragmentation seen in the Ruby gem ecosystem.
  • 00:09:11 — Advice for developers and conclusion — As the interview concludes, Jonathan asks Ryan for advice for both new and experienced developers. Ryan emphasizes the critical importance of code readability, sharing that projects where he sacrificed readability have come back to haunt him. Jonathan relates this to the programming adage about naming things being one of the hardest problems.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2015-02-13T13:30:00Z
  • Duration: 00:12:04

References

Podcast Info

Transcript

[00:00:00] Hey, everyone, and welcome to Developer T. My name is Jonathan Cottrell. I’m your host.

[00:00:06] And today I continue my interview with Ryan Stout. Ryan is the creator of the Volt framework.

[00:00:14] If you haven’t listened to the first part of the interview, it’s probably worth going

[00:00:17] back and listening to. Ryan talks about the framework itself and how it’s made. Volt is

[00:00:24] basically a web framework that allows you to write Ruby once. And that Ruby translates

[00:00:30] into both front end and back end code for your web application. It takes care of the front end

[00:00:37] NVC stuff as well as the back end. So if you haven’t listened to that first part, make sure

[00:00:42] you go back and listen to it. I hope you enjoy the second part of the interview with Ryan Stout.

[00:00:48] So another thing that is kind of baked into Volt that I’d like to hear a little bit of your

[00:00:58] thinking on it and why you decided to do it this way is the persistent connection. So I know like

[00:01:05] a lot of people don’t have a full understanding of this. And I would say I’m actually included

[00:01:09] in that group of all of the benefits that come along with persistent connection in terms of like

[00:01:16] a lot of people say, well, it’s about performance. And some people say, no, it’s about like clarity

[00:01:20] of data transfer or whatever. So why did you choose to go with like the socket connection model?

[00:01:29] Yes. So there’s a couple of reasons for it. Just one thing to keep in mind too is that if you’re

[00:01:35] not using, Volt provides you these different places you can persist your data. And so one of

[00:01:44] those is the store. We call it the store, which is basically syncs back to your database and

[00:01:49] syncs to other clients based on some rules you set up. So only if you’re using the store does it

[00:01:55] actually set up that persistent connection. And that’s MongoDB, right? The database at the moment

[00:02:02] as MongoDB, we have plans to build sort of, we’re calling it a data provider API to let you let other

[00:02:11] people or myself add any sort of database that they want. But yeah, at the moment we’re using

[00:02:16] Mongo for a couple of reasons. So the interesting thing with the WebSocket connections, one thing,

[00:02:26] it gives you kind of real time updates. I think that’s nice, but I actually don’t think that’s

[00:02:30] something that that many people need. For us, it is partly a performance thing. So when you already

[00:02:37] have that connection, so when you’re doing any sort of data transfer, TCP has these window sizes

[00:02:49] and it basically gets faster the more data you send through it. And so with things like keep alive,

[00:02:58] it’s not a huge issue anymore, but there is a little bit of performance in having that TCP

[00:03:04] connection always open. It also, I guess the other thing too, is the push side of it. So we can

[00:03:10] actually have it where someone drops the connection and it kind of waits around and then when they

[00:03:17] reconnect things kind of sync back up. And that’s something we could do over Ajax or XHR or something

[00:03:25] like that. But it actually, it’s nice because then we can go and send those changes out

[00:03:34] and then everyone is kind of always working with up-to-date versions of the models,

[00:03:39] if that makes sense. And I think that the other thing too is that there might be a little bit of

[00:03:48] sort of a perceived performance hit by keeping a socket connection open, but it’s actually

[00:03:54] really nice nowadays you have things like Nginx has built-in web socket support so it can kind

[00:04:00] of keep, do all the heavy lifting for you. And there’s actually not much of a performance

[00:04:05] penalty nowadays to it to keep that connection open all the time. Yeah, I mean I would imagine

[00:04:10] that people are trying to optimize this because it’s not going anywhere anytime soon, it’s probably

[00:04:19] going to continue to grow. Yeah, it’s also nice, you know, I’ve done quite a few projects

[00:04:25] in the past where we’d end up using something like Pusher and it’s surprising how many projects

[00:04:32] nowadays you end up needing some sort of push from the server. It may not be that you necessarily

[00:04:38] need real-time, but there’s a lot of things where, okay, I’m uploading a file, I need to,

[00:04:43] you know, after I’ve processed it, I need to tell something that’s done. Right. And things just

[00:04:48] become a lot simpler when you’re not dealing with things like, you know, XHR timeouts and

[00:04:56] things like that, you know. Yeah, polling or whatever. Right, yeah, exactly. So kind of having

[00:05:01] that as a base feature I think really opens up a lot of doors. Yeah, I agree, I agree. This is

[00:05:08] awesome. I’m really excited about this direction because, so another thing about Volt is that

[00:05:17] basically out of the box it’s ready for like, and partially because of this persistent connection,

[00:05:24] it’s ready for high input output and that’s also partially due to the document store kind of model,

[00:05:30] right? So you’ve got like fast inputs, fast outputs, it makes it ready for high interaction,

[00:05:39] like kind of shallow interaction to where your app isn’t doing a ton of processing, but very quickly

[00:05:47] you know, you can have a bunch of messages passing through the app.

[00:05:51] So that’s exciting and I think that we, people in the Ruby land have been kind of plagued with

[00:06:00] systems that are not so much optimized for that and I just, I’m looking forward to the things

[00:06:08] that are going to be built and the conversations that are actually just naturally going to happen

[00:06:13] because of that. Yeah, I think having, you know, it’s interesting there’s kind of a couple schools

[00:06:20] of thought on framework design and you know, I think of it as kind of the micro framework

[00:06:25] versus batteries included and I would definitely say Volt is not, you know, we don’t want to be

[00:06:33] sort of perceived as like the monolithic framework, right? But I think we do air more

[00:06:37] on the side of batteries included and I think especially for the core web framework you get

[00:06:42] some really interesting things where once you have these features standardized into the framework,

[00:06:48] people can build other things on top of them. So for example, we’re baking authentication into

[00:06:56] the framework and it’s one of those, yes, not every project needs authentication, but the majority of

[00:07:01] them do and so once we have authentication in the framework itself, all of these extra plugins,

[00:07:09] or we call them components, can be built assuming the authentication and so I think we’re going to

[00:07:14] see hopefully a pretty good ecosystem around these reusable components that we have where you can go

[00:07:20] and say, okay, I want image upload for the user, you know, and then it automatically ties in and

[00:07:27] Rails kind of did that with some conventions, but having that actually standardized in the framework

[00:07:33] I think makes it even easier. I agree entirely actually. The Ruby community has adopted the idea

[00:07:41] of gems, of course, because, I mean, it’s natural that that plug-in ability of gems is a powerful

[00:07:49] feature of Ruby, but sometimes it ends up being like, well, I’ve got 100 authentication gems to

[00:07:55] choose from and I have this stack of dependencies where if I’m using this authentication gem,

[00:08:02] then that narrows the other gems that have authentication that makes sense with that

[00:08:07] or that is compatible with that gem and it just becomes kind of, what’s the word I’m looking for,

[00:08:15] convoluted. And as a gem maintainer, it becomes really hard to, you know, you have to support all

[00:08:22] of those or you ideally want to support all of those and it, you know, becomes a pretty difficult

[00:08:28] thing. And then everybody’s writing alias methods for, you know, authorization and it’s like,

[00:08:33] gosh, man, I just wish, you know, if it’s authenticated through Rails and it’s just,

[00:08:39] you know, current user, period, and everybody uses that, you know. Yeah, and they’ve sort of

[00:08:44] settled on that, but it took a long time and I’d say it was almost a little painful in the early

[00:08:49] days and so we’re hoping that sort of, you know, picking some of the things that 90% of projects

[00:08:56] need and baking them in or baking them in at least as an officially sanctioned gem, you know,

[00:09:04] will help with that. Yeah, absolutely. Well, Ryan, I’m running out of time here, so I appreciate

[00:09:11] your time so much and I appreciate the work you’re doing on Volt. Is there anything else that you

[00:09:17] want to kind of share with, oh, I do need to ask you. So if you had just 30 seconds to provide some

[00:09:25] kind of advice to both seasoned and brand new developers who are just getting into this field,

[00:09:33] what would you tell them? That’s a good question. I guess I would say, you know, as developers,

[00:09:40] we have a lot of things we try to prioritize. At least for me in the last few years, I’ve really

[00:09:45] realized how important readability in code is and, you know, it’s something that there’s sort of

[00:09:52] always a trade-off, but it seems like, at least for me, that the project where I’ve really traded

[00:09:57] off on readability has kind of come back to bite me. So I guess I would say, you know, always be

[00:10:04] thinking about readability, especially in a project where you’re not going to be the only one working

[00:10:08] on it, I guess. Yeah, that’s great. I actually recently talked on the show about the hardest

[00:10:16] parts of computer science and somebody mentioned it really should have been called the hardest part

[00:10:20] of programming, but in any case, one of them is naming things, right? Yeah, absolutely. Well,

[00:10:28] that’s great advice, Ryan. I appreciate your time, and if anybody’s interested in Volt,

[00:10:34] I guess the best place for them to start would be those office hours and the GitHub repo or…

[00:10:42] Yeah, and we also have, you can go to VoltFramework.com. We have kind of links to docs

[00:10:47] and links to everything from there. But yeah, I’m always on Gitter if anyone has any questions

[00:10:53] getting started. Yeah, and then we’re doing office hours tomorrow from, I think, four to six Eastern

[00:11:00] time, so every Friday. Perfect. Thanks so much, Ryan. Yeah, thanks for having me.

[00:11:07] And thank you so much for listening to the show. You are the reason this show is created,

[00:11:12] so the fact that you are here and listening to it, I couldn’t be more appreciative of.

[00:11:19] If you are enjoying the show, please take just a few minutes and drop into iTunes and leave us

[00:11:24] a review and a rating. It really is a personal favor to me, but it also helps other people just

[00:11:31] like you, other developers, find Developer Tea. You can always get in touch with me on Twitter

[00:11:38] at at developertea, or you can email me at developertea at gmail.com. You can also find

[00:11:44] the show at developertea.com, and in the nav at the very top of the site, there’s a contact link

[00:11:49] where you can fill out a form, and that comes directly to me as well. As always, until next time,

[00:11:56] enjoy your tea.

Visão de gráfico