Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell, I'm your host and today I continue my interview with Ryan Stout. Ryan is the creator of the Volt 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. Volt 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 and VC 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 Volt that I'd like to hear a little bit of your thinking on it and why you decided to do it this way is the persistent connection. So I know like 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 like a lot of people say well it's about performance and some people say no it's about like clarity of data transfer or whatever. So why did you choose to go with like the socket connection model? Yeah, so there's a couple of reasons for it. Just one thing to keep in mind too is that if you're not using Volt provides you you know these different places you can persist your data and so one of those is the store. We call it the store which is basically syncs back to your database and syncs to other clients based on some rules you set up. So if you 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 as MongoDB we have plans to build sort of we're calling it a data provider API to let you let other people or myself add any sort of database they want but yeah at the moment we're using Mongo for a couple of reasons. So yeah so the interesting thing with the WebSocket connections you know 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 you know TCP has these window sizes and 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 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 up and that's something we could do over you know Ajax or XHR or something like that but it actually it's nice because then you know we can go and send those changes out and then everyone is kind of working always working with up to date versions of the models if that makes sense. Yeah absolutely. Yeah 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 Engine X as built in Web Socket 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 it's probably going to continue to grow. Yeah it's also nice you know I've done quite a few projects in the past where we ended 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's done. Right and things just become a lot simpler when you're not dealing with things like you know XHR timeouts and things like that you know yeah pulling 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 it's ready for like impartially 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 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 it you know you can have a bunch of messages passing through the app. So that's 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 that 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 Vult is not you know we don't want to be sort of perceived as like the monolithic framework right but I think we do air 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 we're making 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 everyone all of these extra plugins are we called in components can be built assuming the authentication and so I think 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 standardize in the framework I think makes it even easier. I agree entirely actually there's the Ruby community has adopted the idea of gyms of course because I mean it's natural that that plug-in ability of gyms is a powerful feature of Ruby but sometimes it ends up being like well I've got 100 authentication gyms to choose from and I have the stack of dependencies where if I'm using this authentication gym then that narrows the other gyms that have authentication that makes sense with that or that is compatible with that gym and it just becomes kind of what's the word I'm looking for convoluted. Right. And as a gym maintainer it becomes really hard to you know you have to support all of those are 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 authorization and it's like gosh man I just wish you know if it was if it's authenticated through rails and 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 at least as a officially sanctioned gym you know we'll help with that. Yeah absolutely. Well Ryan I am running out of time here so I appreciate your time so much and I appreciate the work you're doing on volt. Is there anything else 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 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 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 that the project where I've really traded off on readability haven't 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. Actually recently talked on the show about 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 absolutely. Well that's great advice Ryan I appreciate your time and if anybody is 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 docs 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 the show is created so the fact that you are here and listening to it I couldn't be more appreciative of. If you are enjoying the show please take a just a few minutes drop into iTunes and leave us a review and a rating. It really is a personal favorite 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 Developer Tea 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.