Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell. I'm your host. And today I continue my interview with Ryan Stout. Ryan is the creator of the Vault framework. If you haven't listened to the first part of the interview, it's probably worth going back and listening to. Ryan talks about the framework itself and how it's made. Vault is basically a web framework that allows you to write Ruby once. And that Ruby translates into both front-end and back-end code for your web application. It takes care of the front-end MVC stuff as well as the back-end. So if you haven't listened to that first part, make sure you go back and listen to it. I hope you enjoy the second part of the interview with Ryan Stout. So another thing that is kind of baked into Vault that I'd like to hear a little bit of your thoughts, thinking on it and why you decided to do it this way, is the persistent connection. So I know a lot of people don't have a full understanding of this. And I would say I'm actually included in that group of all of the benefits that come along with persistent connection in terms of a lot of people say, well, it's about performance. And some people say, no, it's about clarity of data transfer or whatever. So why did you choose to go with the socket connection? What was the biggest part of that model? Yes. So there's a couple of reasons for it. Just one thing to keep in mind, too, is that if you're not using, Vault provides you these different places you can persist your data. And so one of those is the store. We call it the store, which basically syncs back to your database and syncs to other clients based on some rules you set up. So only if you're using the store does it actually set up that persistent connection. And that's MongoDB, right? The database at the moment is MongoDB. We have plans to build sort of a, we're calling it a data provider API to let you let other people or myself add any sort of database that they want. But yeah, at the moment we're using Mongo for a couple of reasons. Sure. So the interesting thing with the WebSocket connections, one thing, it gives you kind of real-time updates. I think that's nice, but I actually don't think that's something that that many people need. For us, it is partly a performance thing. So when you already have that connection, so when you're doing any sort of data transfer, TCP has these windows. It basically gets faster the more data you send through it. And so with things like Keep Alive, it's not a huge issue anymore, but there is a little bit of performance in having that TCP connection always open. It also, I guess the other thing too, is the push side of it. So we can actually have it where someone drops the connection and it kind of waits around. And then when they reconnect, things kind of sync back. And that's something we could do over Ajax or XHR or something like that. But it actually, it's nice because then we can go and send those changes out. And then everyone is kind of always working with up-to-date versions of the models, if that makes sense. Yeah, absolutely. And I think the other thing too is that there might be a little bit of, sort of a perceived performance hit by keeping a socket connection open. But it's actually really nice nowadays. You have things like Nginx has built-in WebSocket support, so it can kind of keep, you know, do all the heavy lifting for you. And, you know, there's actually not much of a performance penalty nowadays to it, to keep that connection open all the time. Yeah, I mean, I would imagine that people are trying to optimize this because it's not going anywhere anytime soon. Yeah. It's probably... They're going to continue to grow. Yeah, it's also nice. You know, I've done quite a few projects in the past where we'd end up using something like Pusher. And it's surprising how many projects nowadays you end up needing some sort of push from the server. It may not be that you necessarily need real-time, but there's a lot of things where, okay, I'm uploading a file. I need to, you know, after I've processed it, I need to tell something that it's done. Right. Right. And things just become a lot simpler when you're not dealing with things like, you know, XHR timeouts and things like that. Yeah, yeah. Polling or whatever. Right, yeah, exactly. So kind of having that as a base feature, I think really opens up a lot of doors. Yeah, I agree. I agree. This is awesome. I'm really excited about this direction because... So another thing about Volt is that basically, out of the box, it's ready for, like, and partially because of this persistent connection, it's ready for high input output. And that's also partially due to the document store kind of model, right? So you've got, like, fast inputs, fast outputs. It makes it ready for high interaction, like kind of shallow interaction to where your app isn't doing a ton of processing. But very quickly, you know, you can have a bunch of messages passing through the app. So that's exciting. And I think that we, people in the Ruby land, have been kind of plagued with systems that are not so much optimized for that. And I just, I'm looking forward to the things that are going to be built and the conversations that are actually just naturally going to happen because of that. Mm-hmm. Yeah, I think having... You know, it's interesting. There's kind of a couple schools of thought on framework design. And, you know, I think of it as kind of the micro framework versus batteries included. And I would definitely say Vault is not, you know, we don't want to be sort of perceived as, like, the monolithic framework, right? But I think we do err more on the side of batteries included. And I think especially for the core web framework, you get some really interesting things where once you have these features, standardized into the framework, people can build other things on top of them. So, for example, we're baking authentication into the framework. And it's one of those, yes, not every project needs authentication, but the majority of them do. And so once we have authentication in the framework itself, all of these extra plugins, or we call them components, can be built assuming the authentication. And so I think we're going to see, hopefully, a pretty good ecosystem around, these reusable components that we have where you can go and say, okay, I want image upload for the user, you know, and then it automatically ties in. And Rails kind of did that with some conventions, but having that actually standardized in the framework, I think, makes it even easier. I agree entirely, actually. The Ruby community has adopted the idea of gems, of course, because, I mean, it's natural that that plug-in ability of... of gems is a powerful feature of Ruby, but sometimes it ends up being like, well, I've got 100 authentication gems to choose from, and I have this stack of dependencies where if I'm using this authentication gem, then that narrows the other gems that have authentication that makes sense with that, or that is compatible with that gem, and it just becomes kind of... what's the word I'm looking for? Convoluted. Right. And as a gem maintainer, it becomes really hard to, you know, you have to support all of those, or you ideally want to support all of those, and it, you know, becomes a pretty difficult thing to... And then everybody's writing alias methods for, you know, authorization, and it's like, gosh, man, I just wish, you know, if it's authenticated through Rails, then it's just, you know, current user, period, and everybody uses that, you know? Yeah, and they've sort of settled on that, but it took a long time, and I'd say it was almost a little painful in the early days. And so we're hoping that sort of, you know, picking some of the things that 90% of projects need and baking them in, or baking them in at least as an officially sanctioned gem, you know, will help with that. Yeah, absolutely. Well, Ryan, I'm running out of time here, so I appreciate your time so much, and I appreciate the work you're doing on Vault. Is there anything else... Any other thoughts that you want to kind of share with... Oh, I do need to ask you. So if you had just 30 seconds to provide some kind of advice to both seasoned and brand-new developers who are just getting into this field, what would you tell them? That's a good question. I guess I would say, you know, as developers, we have a lot of things we try to prioritize. At least for me, in the last few years, I've really realized how important, how important readability in code is. And, you know, it's something that there's sort of always a trade-off, but it seems like, at least for me, the project where I've really traded off on readability has kind of come back to bite me. So I guess I would say, you know, always be thinking about readability, especially in a project where you're not going to be the only one working on it, I guess. Yeah, that's great. I actually recently talked on the show about the hardest parts of computer science, and somebody mentioned it really should have been called the hardest part of programming. But in any case, one of them is naming things, right? Right, yeah. So, yeah, absolutely. Well, that's great advice, Ryan. I appreciate your time. And if anybody's interested in Vault, I guess the best place for them to start would be those office hours and the GitHub repo, or? Yeah, and we also have, you can go to vaultframework.com. We have kind of links to, and links to everything from there. But yeah, I'm always on Gitter if anyone has any questions getting started. Yeah, and then we're doing office hours tomorrow from, I think, four to six Eastern time. So every Friday, so. Perfect. Thanks so much, Ryan. Yeah, thanks for having me. And thank you so much for listening to the show. You are the reason this show is created. So the fact that you are here and listening to it, I couldn't be more. I appreciate it both. If you are enjoying the show, please take just a few minutes, drop into iTunes, and leave us a review and a rating. It really is a personal favor to me, but it also helps other people just like you, other developers, find Developer Tea. You can always get in touch with me on Twitter at at Developer Tea, or you can email me at developertea at gmail.com. You can also find the show at developertea.com. And in the nav at the very top of the site, there's a contact link where you can fill out a form, and that comes directly to me as well. As always, until next time, enjoy your tea.