In this episode of Ruby Rogues, guest Jonathan Reinink joins the Rogues to talk about what Inertia.js is and why Rails developers would want to use it.

Hello, and welcome to Ruby Rogues. I'm John Epperson, and we are we have a couple panelists today. We have Luke. Hi. Welcome.

And we have Jonathan Reiny. Reiny. Your thing like cut off and gave me the dots right as I was looking at it. And I was like, oh my gosh, Reiny. Welcome.

Jonathan is the author or creator, however you wanna say that, of inertia JS, and we just have him here today to yap about it. Can you just give us a little bit just to start out about your background and how why you might be famous, and then we can go ahead and get into inertia after that? Yeah. For sure. I am a web developer, and I've been doing, web development for almost 2 decades by now.

And I hang out mostly in the Laravel community. So I contribute to that framework and kinda like doing all things PHP. And, yeah, my main projects have been some libraries and p some PHP libraries. I was also involved early on in the tailwind CSS framework. If you're familiar with that, me and my buddy Adam Weven built that.

And more recently, I have focused on inertia as well as a bunch of, database stuff. I'm I'm a big fan of databases and optimizing databases and active record. And so I put out a course recently about that. So those are kind of the the things I mostly work on. I work for myself outside of that.

I run a small SAS business, solo SAS, and that's fun. That's pretty much me. Awesome. So since we were planning to talk about inertia, let's go ahead and dive in. What exactly is inertia?

Yeah. So it's always fun when you come up with a new project that's a little bit different than other things. It's a it's certainly been one of the most challenging things. It's just explaining what inertia is. And kind of the simplest way to describe it is it's a way to build single page applications without needing an API.

Meaning, you can build a single page app using a classic server side framework such as Rails or Laravel and you can use classic server side routing, classic server side controllers. But the only difference is with inertia, there is no server side views. All the views are done with Vue or they're done in React or done using Svelte. And, what happens is you basically return some data from our controller and where you'd normally return a view and output that data, you instead return a JavaScript page component. So just imagine a JavaScript page component being rendered on the page instead of, like, an ERB template, I guess, is what they would be considered in rails.

And, obviously, that's client side rendered, so it's not server side rendered. But what happens is every single time you navigate from 1 page to the next, inertia intercepts any page clicks so that you don't do full page reloads. But instead, when you click a link, inertia will intercept that link click. And instead of doing a full page reload, it'll run off to the server making what's called an inertia request, and the server will pick it up, say, okay. This is inertia request and it'll fire back the data needed for the next page.

And the data is the JavaScript page component, the Vue or React or whatever, and the data, the props for that component. And then what happens is client size, so that's made as an AJAX request. That data comes back, that response comes back, and then dynamically client side, the page component is swapped out and that's using, dynamic components, which is a feature of all 3 of the popular client side frameworks, Vue, React, and Svelte. So it's dynamically swapped out and it's given its new page props. And the big, big, big benefit there is 1, when you're navigating from 1 so there's like 3 key benefits.

1, you're navigating page to page and not doing full page reload. So there's a performance benefit to that. 2, when it's doing that because you're not doing the full page reload, it's not having to reboot, view, or react every single time. So it's like really like silky smooth kind of experience. It's just like a it's like you're working with an SPA, except you're not.

You're just navigating from one page to the next, and it's just swapping out those components, those page components dynamically. And 3, and I knew this was gonna happen. I don't remember my 3rd benefit, but, oh, the 3rd one is the obvious one. You get to build an app using client side technology. And really kinda what pushed me down this road is I was building more and, like, in my applications that I've built and I build, I always use Laravel, which is very similar to Rails.

So for this audience, just kinda think of them more or less as the same thing. I was you know, much of my apps were starting to contain more and more, like, rich UI and more client side functionality, more JavaScript requirements to basically make the UIs work a certain way that just kinda wasn't possible using classic server side rendering. And what I was basically doing is I was in my page responses. I was returning server side render view, which would then have Vue components mixed into the page. So what would happen is the response would come back from the server, then Vue would kick into gear and any of the Vue components on the page, there'd be like a little flicker and then they would show up.

Right? And then you'd have those individual components would be reactive and whatnot. Right? And so by going but that kinda comes with a whole bunch of interesting problems. I mentioned the flicker and just kinda having to manage each one of those separate components.

So by going this way with inertia, you're really, like, fully committing to client side render views. So you give up server side render views. That is a that is a trade off. But what me that means is anytime you're working with any of the templates within your application, you have the power of JavaScript, you have the power of Vue or React, and you can do whatever you need to do. And it's just a really, really nice way of working it.

Yeah. So that's kinda a longer description. I I would say that, like, I definitely built it for people who have traditionally worked with server side rendered applications, like frameworks like, again, Laravel, Ruby, Django, that kind of stuff. People who are familiar with creating controllers and getting data from the database and then passing that data to a view. The whole paradigm is very, very similar and much different than the classic the more standard SPA approach where you have some separate API, some separate app that provides, like, a REST API or GraphQL API.

So it's it's definitely targeted at that audience. And kinda as I was I've said to people before, I kinda joke that inertia is like the gateway drug to creating single page applications. Because if you're coming from a monolith background, inertia just it so easy to get up and running with creating, like, what essentially feels exactly like a client side single page app, but kinda using the technology that you know and love already. Yeah. I actually find it super interesting.

I mean, I've been for at least the past day or so kind of checking out some of the stuff on the site and things like this, and there's a lot of so it kinda sounds just to make sure that I understand this the way that I think that I understand this, you're more or less going to obviously, being familiar with Rails here, you're gonna create, like, this kinda high level sort of meta layout as you will or whatever. And then instead of creating a whole bunch of views for all of my pages, I'm just returning this inertia thing, which has a props attribute or whatever, and then I'm just basically returning data as JSON. So kind of a bit like an inline API kind of thing almost. Like, I'm just kinda rendering JSON almost there. And that's more or less how my page is gonna run, and that that's how my back end's gonna run.

And then I basically just have a single page app on the page. That's it. Yeah. And, all these props get passed down, and I just do with it what I want to in that single page app. Yep.

Yeah. So a couple interface, as you will, if you will. Yes. I like yeah. So a couple of things to be aware of.

Like, I like to compare inertia in a lot of ways to almost React router or Vue router because in a way, all inertia is is a specialized router, like client side router that lives between your server and your controllers, which is returning data as JSON and your client side page components. So it's the piece that connects the 2. But unlike with a classic app, you know, with Vue router, React router, whatever, you don't have any client side state management at all. So you're not using any client side like Vuex or whatever the React equivalents are. You're not using any of that stuff because all your data and all your state is essentially at the server.

So it's not like you're making requests to the API client side, saving that in your client sites, view x library or or or database or whatever you wanna call it, and then rendering components based on that. Basically, every single time you visit the page, the data is coming straight from your controller and go into your your client side page component. Alright. I got a dumb question. You're gonna have a few of those from me.

So I wanted to kind of have a go at this and I've been building this Vue app. And the way I populate my Voo, is it Voo or Voo? Voo. It's the accent, isn't it? I can't, I can't even tell.

I think I'm trying to make it English. The way I populate my component is I go off my herb, my ERB template downloads, and then I do a get to get the initial data from the page. And then it drops in when the get returns, you've got your view building. Yeah. Now, in the examples on the inertia JS site, then it uses Laravel and we could take a nice divergence here because I'm starting to get Laravel envy.

Some of the tooling, some of the tooling that you show off on the inertia JS website. I didn't I didn't think the Ruby or Rails community have. I'm sure John know more, but there's a there's a plugin where you can see the database queries being done on that page, like the SQL. And I saw that, oh, you know, the would have been useful. I mean, for years, if I could just see what the what the page was hitting, you know.

Does that exist for Rails? I'm pretty sure I've seen various things, and you can definitely see it in your logs. I know. I know. I can see it in my logs, but, you know, to have it have it there, you know.

Hang on. I mean, maybe I could go find this. I don't know if it's a good use of my time, but maybe I could go find this. But I'm pretty sure that I've seen something somewhere that does something like that. However, regardless, you do know that you can switch those Laravel things to rails to see the the rails examples on the inertia site.

No. I didn't actually no. I didn't find the tab. Where's the tab? There's a tab.

Code snippet every code snippet there is on the site, it defaults to Laravel, but you can switch it over to rails. Oh, no. There's some basic fail going on here. No worries. So what you're saying is you're very appreciative of how awesome Laravel is on a Ruby podcast.

Alright. Listen, I'll be honest. This is not the first time this has happened. That's a nice workflow. You know, I like the tool.

Is it I can't find this thing. You do it now. I don't believe it exists. I'm looking at it right now. I'll take a screenshot.

Yeah. So the, the the tool in Laravel and the PHP community, it's called the it's called the PHP debug bar and there's a Laravel debug bar version built on top of that. And it's fantastic because it's it's exactly you can, you know, you can figure out all your database queries and your logs and whatnot. But what the Laravel debug bar does is it just puts them right in the bottom of your screen just like a it's almost like a a Chrome console, right, where it shows you exactly what database queries you're making and what models you're loading from the database and how much memory you're using. It's super, super helpful.

Helps you to identify n plus one issues and slow queries and stuff. Where's my Rails debug bar? That's what I wanna know. Moving swiftly on from my basic inability to use a website. So I was asking about the the way you hook it in.

What does for for the benefit of people who can't use website like me, how does RAIL send down that lump, that because there's two things on there. There's the kind of layout and there's the and the props. Yes? Yep. Yeah.

So I'll walk you through that. I I often fail to kind of explain this just because, you know, you forget sometimes kind of where to start after you've talked about something for long enough. But so what essentially happens, and I'll explain as best I can kind of using rails lingo, but I'm not super familiar with with it all, but, like, work with me. So basically, a request is gonna come in. So through the very first time that someone hits your inertia application, your inertia rails application, what's gonna happen is it's gonna notice that it's just it's a standard full page visit.

Right? And what it's gonna do is it's going to hit rails and it's gonna see that it's not an inertia request. So it's not gonna return some JSON. It's just gonna go through the normal flow. And what it's gonna do is it's going to return your base ERB template.

So your layout file. Right? And that layout file is just like a standard layout file that has your head, which is gonna have the your script tags, and it's gonna have your style tags, kind of just your standard layout. The difference is what it's not gonna do is it's not gonna so and keep in mind that someone may land on your app on any different page. It doesn't have to be the homepage, of course, the index page.

It could be any page in your application. Right? So it's gonna see that request coming in. So it's gonna return or it's gonna server side render that layout, except the only difference is within the body of that server side rendered HTML file, it's not gonna have any page content. So the page content will not exist.

So you landed on, say, the user's page within your application. It's not gonna have a bunch of HTML, server side HTML generated and rendered. What it's gonna do instead is there is a base div that it's gonna that you need to put in your base layout. And that's the div that your client side application is going to mount to. So what happens is that base div, your client side app view react, whatever, mounts to that.

But what happens is server side, it passes this page object. So a JSON encoded page object as one of the attributes within that div. So I think it's called data dash page is the page attribute. I I should probably double check and know that offhand, but I'm pretty certain. Yeah.

It's a data dash page. That's the attribute on the div. So imagine a div has an idea of app, which is what your Vue or React apps gonna mount into, and then it has an attribute called data dash page. And the the contents of that data dash page attribute is just a string, but it's actually a JSON encoded string. And what it's including is all the necessary information that inertia needs in order to boot up that particular client side page component.

So it's gonna include 2 main things. The the most important things to know are 1, the component name. So the component name's gonna be the view or react component page component name. So in this case, it might be the user page, which is gonna have a corresponding user page dot view file or or user page dot react file. And then the second piece of information that's gonna be in that JSON payload is the props, which is the data.

I call them props because they're considered when you're working with Vue or React, props are the properties, the the attributes, the the data that gets passed to that component. So it's essentially the data. So if you imagine now, if we we hit the rails app, it's the user's page, which gets which causes the routing to go to the user's controller. Your index method is gonna go off and it's gonna use active record to get some data from the database for the users that you wanna display on that page. And then in a classic Rails app, and jump in if I get in any of the terms wrong here, gents, because I'm, you know, I'm gonna use more kind of lang lingo that I know.

But what it's gonna do is normally, you would then return an ERB template that you pass a the user index view to and pass the data, which is the users you just looked up from the database using active record. And that's gonna go off and generate your HTML. In this situation, you would instead return an inertia response. So it's and but the the clever thing about the inertia response is so it's basically the exact same thing. You basically return inertia, you pass it the name of the page component, and you pass it the data.

So the controller itself doesn't know if it was a full page visit like a standard get visit or if it was an actual inertia visit. Inertia takes care of that. All the controller has to do is return the page component name. So the client side page component name and the data for that component. Then Inertia behind the scenes, it inspects the request and says, okay, was this a full page visit?

You know, so where we need to display the layout. Well, if that's the case, well, then we're gonna display the layout. We're gonna render it server side, and we're going to inject that base div with the ID of app and with the the data page attribute with all the data for it. And then we're just gonna render that out as kinda just a standard HTML page. Then inertia will grab that data and boot up the client side application.

However, on subsequent visits, when inertia so if you go then and click to a different page, maybe you click on one of the users you wanna view the user. What inertia does is it intercepts that click, that page visit, and it then makes the XHR request to the server. It's gonna hit in the exact same way. Now imagine it's gonna hit your users controller again, but this time it's gonna hit the show method. So again, what would you do just in a standard layer or standard Laravel or rails app is you go off, you'd get that user from the database, use an active record.

Right? And then you would normally just return a response to show the the user show page with the the user data. Except again with inertia, you wouldn't do that. You would do you'd return an inertia response that would then have the user show page component, client side page component, and the data which would be the user data, maybe their ID and their first name, their email, their last name, whatever else. Right?

So when that request comes through the XHR request, what inertia does is it passes through an X inertia header which is set to true so that your rails app knows that this isn't a full page reload. This is this is like an inertia request. So it's an x HR request. And what it does instead is it returns not the the full body and the full layout and everything else. It just returns the JSON data that it requires.

So that's the same JSON data that will be put in the data page attribute if it was like the full, you know, HTML layout render kind of on the first visit. Except it just returns the JSON and nothing else. And it returns that obviously as a JSON response, which that's gonna have your component name and all your props. And then kinda getting back to what I explained earlier, inertia's gonna then take that. It's gonna dynamically swap out the client side page component with the new page component and dynamically swap out the the data, the props for that component.

And like service or sorry. For the for the user and the browser, it's gonna look like you went to a whole new page. But the reality is it's just done some really nice magical work in the background to just kinda flip it for you. And then, of course, like I said, inertia is essentially, in its simplest form, it is a client side routing library. So it's gonna update your your URL in the browser, and it's gonna update the necessary page state so that you have, like, you know, proper history and stuff so you can navigate back and forth and stuff like that.

So that's kinda like the trickiness that we do. But the reality is from a development experience for people who are using rails or Laravel who are kinda used to working with that. Hey. I got a controller. I got a controller method.

I gotta get some data from the database. Now I gotta return a view with some data. It literally feels the exact same way except the difference is you're ending up you're working with Vue or React templates. You're not working with ERB templates. Alright.

I found it now. It's super easy and from for the other kind of web challenge people who are listening. There is a gem. There is, this is the this is the key component I was missing. There is a inertia_railsgem that does it for you.

Yes. Yes. I should have mentioned that probably too. Yes. So you don't gotta do any of this work.

This like I said, when inertia does all the magical work for you, it's actually and when I say magical, it's really not it's not magical at all. It's in its most basic form, it's imagine this, you have a a page response, the inertia gem looks to see, hey. Was the x HR sorry, was the x inertia header set to true? Well, yeah. If it is, then return JSON instead of HTML.

It's, like, literally that basic. And there is, you know, some other interesting features that kinda go along with it such as automatic asset refreshing and and partial reload. So it does get more complicated. But in its basic form, like, I I tell people that if you didn't have the gem, like, so we do have an official inertia gem for rails and we also have an official Laravel package for this as well. So it kinda just makes it really, really easy.

But there's all kinds of people who are making adapters, client side adapters for other languages and frameworks and it's in its most basic form, it really does not take that much. We actually have a page that kinda explains a spec. I kinda call it a protocol because in a way that's really what it is. And as long as you implement that protocol, which is a very simple protocol, you can do this in other language. I I tell people I've literally seen this done.

Somebody reached out and they had done this in cold fusion. I didn't even know cold fusion was still a thing, but somebody has has created an inertia cold fusion adapter. And there's there I know there's been one created for Django and all kinds of other frameworks now. The challenge for me as a library maintainer is normally in the past, anytime I've created libraries, I've always worked with the language that I'm familiar with. So I've worked with PHP and Laravel, and it's not been that or even JavaScript.

And it's not been that hard making the you know, maintaining the library. The challenge with inertia is I'm finding myself becoming more proficient in other languages and frameworks because in order to maintain the rails adapter, I gotta now be more of a Ruby expert. I'm anything but an expert. I shouldn't even said that. But, like, I gotta know the basics of those frameworks.

But fortunately, I've had some a lot of people kinda like jump in and help out on framework specific adapters. Really, the my job at the end of the day is managing the client side adapters because that's, honestly, that's really the hard part. The Vue, the React, and the Svelte adapters are the tricky kind of piece because they're all they kinda got little differences the way they do dynamic component swapping, the way they do data handling, the way they do reactivity. All that stuff is is a little bit different, each one of those client side frameworks. So that's kinda like really the heart of my job.

And even there, I actually have somebody who's helped on the project. One guy who's managing the so I managed the Vue adapter, another guy manages the React adapter, and another guy manages the Svelte adapter. So that's been it's really a quite a collaborative project in that sense. Alright. Now that we theoretically know how to make an app with inertia, why am I making an app with inertia?

Like, what where do you see inertia kind of fitting into the space? And what kinds of apps are we using it for? Things like that. Yeah. That's a really good question to ask because I think it's important.

I think sometimes what happens is people come out with new projects, and I think people like the idea of saying, well, this this whatever this new piece of technology is, this is now the one way to do all the things. And we just, like, we wanna, like, double down and fully commit to that for everything. And if it doesn't do everything, well, then we don't like it. Yeah. We get disappointed if it if it isn't appropriate for all use cases.

And I'm generally, like, slow to say use the right tool for the job because I find quite often we're just most effective using the tool we know and that's tends to be what's worked out better for me. I know that Totally get it. You know? Yeah. I know that Elixir might be better or Node might be better for creating certain apps nowadays, but I'm just so stinking fast with Laravel that I just I use that because it's a tool I know and love.

But I do I will say that kind of in response to that question, I do think that inertia is super suited super well suited for some situations and not others. So the one that it's not well suited for is in a situation where it actually does make sense to make a full on API. So if if it makes sense for you to have a full rest API and a full GraphQL API, then inertia may be not the right choice. Because with inertia, the whole like, my goal with this is to avoid you having to create this whole separate project, this whole separate API, figuring out all the authentication, figuring out all the Olaf stuff and all that Hoopla and the separate hosting account and everything else. Like, my goal is that I just wanna build an app.

I wanna get some data from the database, use an active record, and I wanna split that to a view and render it. Like, that's what I wanna do with Inertia. It's a like, the very fast classic monolith way of building an application. But if you did have a use case that you really truly did need an API, So maybe you're building a web app that has an iOS app and and an Android app and maybe you have maybe you have, native desktop applications or whatever. If you have that use case, then inertia may not be the right choice because it might just make sense in that situation to actually just go off and build that whole API.

But in my experience, there's a ton of applications that get built and I would say, like, especially, like, a lot of just, like, business level applications that never ever ever go past being a web app. That's what they always are. So, yeah, there is there a chance that it could eventually need an API? Sure. But so often you don't need that.

And you know what? You think about any application that's built with just classic Laravel and built with just classic rails using classic rails, server side rendering or Laravel server side rendering, you've already made that decision. You've already just set said this is the web app. And and if I ever need an API, well, then I'm gonna go off and build this app for API for it. So that's really where inertia fits.

If if you were planning and building a server side rendered application, you've already given you've already said no to the API. So my thing here is I really wanted inertia to be for those developers. Those who said, you know, I wanna build a server side application. I was gonna build it with Laravel or I I was gonna build with rails, you know, using the standard monolith approach. I've already decided I'm not gonna build an API.

Well, then Inertia is a wonderful fit because then it allows you to build a rich client side application using Vue or React while still completely working within the paradigm, the monolith approach that you know. And you can be really, really, really fast with that approach. And in my experience as well, I have built applications that use inertia as kind of the the web app tool. And even in those applications, I've had, like, my own application. I do have an iOS and Android app that I'm building right now.

But the iOS and Android app is so simple compared to the web app because that's what makes sense for my business that I didn't even then, I still went in my Laravel app and I just built a really light rest API for my native iOS and Android apps. I still didn't need to fully double down and make my whole web app, you know, run on on this API. It still made sense to build a web app using react using reactor view and inertia without an API. And then literally I have, like, 5 endpoints, 5 API endpoints for this core functionality that I'm making available natively to to iOS and Android. So I hope that kind of explains it.

So that's really I would say the reality is there are probably a ton of situations. Basically, anytime you are planning on building just a classic rails application, that's a good use case for an inertia app. If you have any sort of more interesting client side needs. And by that, and this is maybe the the last distinction I should make, I wouldn't personally use inertia for anything that needs to be public facing. So that's and the reason why is inertia is still a client side rendered application.

Meaning, it doesn't work great from an SEO perspective. Yes. Google is getting better at at indexing, view and react apps, JavaScript apps. It is. And it probably only will continue to get better.

But I think if I was building an application, if I was building a blog, or if I was building a news site, or I was building anything that had a public face that were SEO, search engine optimization was a concern, I probably wouldn't use Inertia because of that limitation. Really, I designed Inertia for, you know, admin control panels, applications, you know, SaaS application where you need to log in, all those kind of tools. And and one great use case is I've done this as well is you could absolutely, say, build a rails application that's completely server side rendered for your public facing pages be it a maybe you're building a SaaS app. You have a bunch of documentation that you wanna make sure it's SEO friendly. You have your pricing page and your about page and all those feature pages.

You could build all that stuff using rails with classic server side rendering while still having the application in the background for the actual SaaS application be an inertia application, but that's only available after you log in. And that's a really common combo where you use server side rendering on the on the front end and you use inertia and client side rendering on the back end. Can we talk about the flicker? Yes. Yes.

So the simple answer is there is no flicker. No flicker at all. That's why it's so wonderful. So there was a flicker building at the old way. So the old way I do this is anytime I needed some view a view component or react component in my application, I would be using classic server side rendering in Laravel, which would return my full document, which would have the all the page content, but somewhere in the page.

So imagine it's maybe like a create user page and maybe I wanna create the the form to create the user. Maybe I wanted to build that in view because I like the reactivity of it. I like to be able to handle errors and everything else just kinda using that view approach. Right? So maybe I'd have the whole page load except the form itself would just be a view component that would boot up after the page loaded.

Right? And that's what I mean by a flicker. That little thing takes a second to boot up because Vue has a Vue to boot up. And it's minor. Like, we're talking milliseconds, but our eyes can perceive it.

And we especially notice it when that component takes no space at first, but then if then it renders and it takes a bunch of space and kinda causes the page to to become longer and, you you know, things move around. And and you and if you have a lot of Vue components, maybe you have a drop down component or a modal or different things like this, that problem just becomes worse and worse. Where with inertia, that totally totally goes away because you're getting exactly what you'd have with, like, a classic Vue or Rails or sorry. A Vue or React app where when you go to visit another page, it's gonna just render that new Vue component and nothing's getting destroyed in the in between because you're not doing a full page reload. Vue and React are long living.

So when I go to the next page, it's gonna load that file in the background. It's gonna load the data in the background via that x h r request. And then when it's ready, it's gonna swap it out. And you can, you know, there's load ways to have loading graphics and stuff for in between that. But the point is nothing's being destroyed when you go from one page to the next that's causing any sort of flicker.

It's it's really, really smooth. So you you sound like you care a lot about kind of the responsibility and user experience. Yes? Very much so. Let's talk milliseconds here.

Let's let's talk some real numbers because I can we could take an enormous effort into kind of making this to help people improve the experience of their users. Let's face it. The whole point is to make the site nicer for the people we write the software for. So what looks like a good load page for you? Yeah.

So my goal generally on a regular web app is 200 milliseconds or less. If I'm building a new application, that's really what I'm going for. Now that's what I would consider, like, a typical server response. But as you know, there's more that goes into a website loading than just your server response. You also have your client side, the time that it needs to render there, the time that it needs to actually paint it on the page, the time that it needs to download in JavaScript bundles and different things like that.

So, yeah, for me, this is honestly, this is one of the reasons why I like this approach so much is because I've I've been very frustrated in the past building rest APIs or even GraphQL. Now GraphQL is amazing, but you can run into performance issues really easy with GraphQL. If you're not careful, you can run into n plus one issues just depending on the the the sort of graph of data you're returning. You it can be tricky from a performance perspective in real applications to have every response from your API be really quick. And that's because these APIs, especially a rest API is is generic.

It's generic because it needs to work for multiple different any application that wants to consume that that API. The wonderful thing about Rails and the wonderful thing about Laravel is that every single controller method, you are going to get the data exactly as you need it for that page. There's no there's no generalized API there. It's like, okay, I'm displaying the users page. I wanna go to the database and I wanna get these 10 users if it's paginated, for example.

And I wanna get their name and I wanna get their ID and I wanna get their email address and maybe I wanna eager load their company company along with it. So what what inertia and this isn't really an inertia feature. This is really just this is really just a rails. This is like a monolith features. Like, when each endpoint is only responsible for getting the data that it needs for the page that it's going to display, you can highly, highly optimize the data retrieval for those endpoints for exactly what's needed in that application.

So that's one of the reasons why I really just like monolith apps in general because I feel like that that approach just leads to fast applications. And I've talked, you know, I mentioned earlier that I'm I love databases and and I love writing learning how to, you know, kinda make the most of the database, create proper indexes, and return the minimal amount of data and run the fastest queries possible. That's that's stuff that I'm super interested in and and focus on. So roundabout way of answering your question, I like 200 milliseconds or less from a response time from the server, which would be the inertia response. But then there's also this whole client side performance side of things.

So let me talk briefly about that as well because that is absolutely a trade off you get when you build a client side application. So one of the trade offs we've talked about already is you the SDO trade off. If SDO is important to you, probably not gonna make sense to build a fully client side rendered application unless you have some sort of server side rendering in place. And and there's all kinds of fancy tools nowadays even to do that with JavaScript stuff, but you know what I'm saying. If if SEO is important to you, you're not gonna wanna have client side rendering as your primary way.

So the other trade off is that you now need to send all that so all your client side views, so all your page components, all your view components, or your your react components, or your spell components, they all need to now be sent over the wire as JavaScript bundles to the client. Right? So inertia, what it does, and this is kind of like a really just I think a cool feature is it will automatically like, it makes you can use because it is just really a plain old regular view or react app. It supports code splitting. So if you use code splitting, what happens is you land on the very first page.

So maybe, you know, going back to our example from earlier, let's say you hit for the very first page, the user index page. What it's gonna happen in inertia app is it's gonna go and get whatever only the minimal amount of JavaScript that's required to display that page. So it's gonna get your typically kinda like your core bundle, which is gonna have like view or react and maybe some like core dependencies that are used kind of by the, you know, all pages on the site. So it's gonna grab that core bundle, which is small because it doesn't have all the pages through your whole application. It's just the core bundle.

And then it's gonna load whatever whatever components are required for that page. So it could be the if it's the the user index page, it's gonna go off and get the user index JavaScript bundle and download that. And then once it's downloaded, you never have to download it again because it's cached. Right? The browser knows to not go off and download it again.

So what that practically means is you hit an inertia endpoint. It's gonna it's gonna only get the minimal amount of JavaScript that you need to actually display that page, and it's gonna get the minimal amount of data from the server because that's the way a a rails app works. And the page can load, like, loads extremely quick. So I actually have a demo app if you wanna try it out. If you told the the demo app is called pingCRM, which is available on the inertia JS website.

And you can actually, you know, click around this application and see exactly what the performance is like. And I think, like, it's so it's hosted on I hosted on Heroku, and I do that intentionally because anytime you host in Heroku, there's even a performance cost and saying having a a one off Linode or DigitalOcean, you know, server because one, for one, the the database is the postgres database, which is not hosted on the same site as the actual web dino. So there's always a performance cost that comes with that, which often, you know, of course, makes sense if you wanna have multiple web dinos and whatnot. So I've posted it that way because I feel like that's a good representation of a real life application. And most responses from the server come back in about a 100 milliseconds.

And I think, you know, that's a pretty awesome experience. I've tried it. It is disgustingly quick. That's what I wanna hear. For me in the UK, it comes back in well under a 100.

Well under a 100 to the extent that I'm quite suspicious that you're loading the next page in the background without turning me first or doing some kind of dirty trick like that. Is it not the easiest database? A 100%. Absolutely, it is. Yep.

Absolutely, it is hidden in the database. And that's interesting you mentioned that because because it is a JavaScript application, there is really some cool opportunities to even do stuff like that. So if you hover over a link for more than a certain period of time, go off and eager load that data. And even if you don't wanna eager load the data, what we can do is eager load the next JavaScript page component that that pay that link would require. So even if you are using code splitting, we can be smart about eager loading that next page component that you may wanna click to.

So, yeah, there's that's a kind of the neat thing because it is ultimately a real view or ultimately a real react app. You kinda get some of the cool things that you can do with those pieces of technology as well. I've been working on another feature that even allows you to do kinda like placeholder pages. So if you were to click on a if you're on the user index page and you were to click on the user, like a a show user page, I've got a working prototype where it could show kinda like a shell of the show user page while inertia is still in the background grabbing that data. Just again, using a classic rails controller show endpoint, and then swap it out when it has the data ready.

And these are like those it's not necessarily something. So the inertia so the the ping CRM demo doesn't do any of but it's I just think it's neat that if you had an application that you were that concerned about the user experience, and you just really wanted to show something right off the bat when someone clicked the link to view a new page that inertia allows you to will allow you to do that. Technically, it doesn't allow you to do that yet, but that's something I'm working on. Yeah. I certainly like speed, but I certainly don't get as excited necessarily as other people do about speed.

But I know that a lot of people do care about it. I think the thing that's most interesting here is so I know that it might be heresy, but I, for a long time, have have more or less said that to me, the controller in MVC, right, really is an API provider, and you're just consuming that API with your view. And it that's sort of like the typical way that people use it. And so I think that inertia, like just kind of leverages that. In my mind, it's you're just leveraging that and making it really easy for people who who are just used to using views to just be like, not have to think about it.

Yeah. It's an awesome evolution in my opinion. Yeah. I love that comment that that comment that it's just essentially an API. It is.

The the difference is with a rails or Laravel app, you've accepted that there is this type coupling between this back end controller and the front end view. That's just an acceptance. You know? And, you know, some people would say, well, that coupling is bad because now I can't use this endpoint for other things. And I say, no, actually, that coupling is awesome because one, it makes it really fast.

You can create these these applications really quickly, and you can optimize them from a performance perspective because you're only worrying about this one request. You're not worried about 30 possible different permutations. It's just one request that you're concerned about. Absolutely. Really, the only benefit to thinking about it that way is when you're suddenly ready to break the rules.

Right? So yeah. Awesome. Anything else that we should know about inertia that you you're just, like, haven't talked about this. You guys Yeah.

Should be thinking about this. Yeah. So yes. There's maybe a couple different things that I think inertia does really well and stuff that I'm even approving on is one is scroll management. So what happens by default when you browse from one page to the next, just using, like, standard, normal, plain old website, and you scroll down and you visit the next page, and then you scroll down and you visit the next page, you know, whatever.

And then you hit back in the browser. The browser is smart enough to remember exactly where you were on each one of those pages and that helps maintain context. Right? Which is a a really nice thing. Inertia allows you to do that because that basically is for free out of the box if you just do a standard page.

But where it becomes tricky, and this is becoming more and more common, is people have what, like, essentially what are considered, like, scroll areas within your UI. So one really common use case for this is imagine you have kinda like your standard layout, left hand side is your navigation and the right hand side is your content. Then maybe along the top you have a bar. Right? When you scroll the content, you maybe wanna scroll the content but not have your left hand nav change or maybe even the other way around.

Maybe when you scroll the content and you want your left hand nav to to follow with you or whatever. Right? So you do this using scroll areas, you know, overflow auto and stuff with CSS to kinda allow that sort of functionality. And yeah. So that's a very common thing with, like, modern applications, especially I would say, like, yeah, more application style websites.

So that kind of like goes out the window. What what goes out the window when you're using scroll areas like that is scroll position management. So if you were to do that and you would go to visit the next page and you go back, the browser has no idea that you were scrolled in this container down 300 pixels. It's like, I don't care. Not my problem.

All it cares about is restoring the body scroll position. So inertia, we're we have support for basically automatically automatic scroll restoration of containers as well. And you can and you don't have to that doesn't happen to all containers. You can actually define on a per container basis, like inertia track the scroll position for this. And that's like a really, really nice feature that you basically yeah.

So that's one thing. Another thing that inertia does really well is asset versioning. So this is a problem that a lot of people run into with, modern client side rendered applications is imagine you have a user. Right? And they go to your application, they go to your website, and they click through a few different pages.

And while they click, you know, maybe they're on the user's page and then when the user show page. And right that moment, you had to fix a bug or do something in that template and you redeployed it. So you redeployed those assets to the server. The problem is right now is with a typical client side rendered application is that you now go back to visit that user index page because it's not doing a full page reload. There's no way for the browser to know that maybe that user index page template changed.

So they're gonna see the old page template, which might be fine or it might not because you might be expecting data from back from the server that's now out of sync with your template. You remember that type coupling that we're talking about between these two things, and would be no different if you're working with an API. If there's an expectation for the data to be there and it's not and that old template could now generate an error, the application application crashed simply because you deployed an update to the application. And this is something that rails and Laravel developers never have to worry about if you're using server side render to fuse. Because when you go to the new page, just doing a full page reload, you're getting a full page, all the new assets, everything else.

So what inertia does is we have, like and there's, like, there are ways to solve this with client side, like classic Vue or React apps, but the it's complicated and they use people use service workers, and I'm not gonna get into details of how that gets solved, but it's kinda complicated. Whereas with inertia, what's really cool about inertia is that the front end and the back end are coupled together. So that's like, you know, this coupling that we keep talking about. Like, that's the real benefit because we can now let the server and the client side frameworks and essentially what it is is it's a server side inertia adapter working with a client side inertia adapter, and they're working together to make sure that things are working properly. So what happens is every single time you make an inertia visit, we keep track of you know what?

Let me back up before I even go there. It might be easier if I explain it this way. When you define your inertia setup in Rails, you have the option on every single page, like, you know, kinda like does it does Rails have this concept of, like, some sort of, like, base, like, application service provider where you do kinda, like, default work? Could it, like, happen to, like, a middleware or just, like, kinda, like, something that gets run on every single page request? Is that I'm I'm sure what Rails said.

Middleware. Right. So imagine I I forget exactly how the gents who put together the Inertia of Rails adapter did this. But just imagine that somewhere in your Inertia configuration, in your Rails application, you basically say, this is the version of my assets. Your assets being your JavaScript basically.

Could also be your your CSS. Rails does all that. Yep. Yeah. So you you have some sort of version number that indicates the current version of your assets.

Like, the way I do it in Laravel is I literally just do I just get an MD 5 of the assets. And and if it changes, it changes. So what you do is you say inertia version and you pass it the current version, and that happens on every single request. So what happens then is that version gets passed to the client side. So that's one.

So I've talked about this page object that that gets passed around, which includes the component name and the props. Well, another another property in that, that page object is the the asset version. So the client side inertia always knows what the current version of your assets are. So then when you now click from one page to the next, so you're on the user show page and you wanna go to user index page, well, you you click the user index page. Inertia goes off and it makes the XHR request, the inertia inertia request to your server to get the index page and the data for the index page.

Inertia automatically passes what it believes is a current version to rails. Then rails, the rails inertia adapter says, okay, I got this request coming in. It's saying that the current asset version is 123, but we can see now that it's a new deploy has happened in the new asset version that is actually 456. And what inertia does is it actually stops the request at that point, and it then gives returns a 4. I believe it's think it's a yeah.

It returns to imagine this in XHR request gets an immediately immediate 409 conflict response back from rails. And then what happens is inertia gets that 409 conflict response back and it says, oh, assets are out of date. So what inertia then does is that automatically does not an XHR request to that page. So going from the user show page to the user index page, it's gonna say the assets are out of date because the server just told me that and it just cuts that XHR initial request short. And it now does an automatic full page visit to the user index page.

And then because you're doing a full page visit, you have an ops the opportunity to use cash bus to reload your assets and you're right back in business. So for the end user, it does mean that they'll have to redownload those assets, of course, but that's what you want because otherwise you wanna deploy them. So they can continue browsing your inertia app like a classic SBA until the assets are out of date, and then they're gonna be forced without their they won't even notice really that it's happening. Other than that, that request will reload the whole page and it'll look like a full page visit, and you're gonna be right back in business on the page. And we do some smart things about the way we make that request, do that 409 response and, like, we automatically reflash data.

So if there was any if you had any flash data that was gonna be used, it automatically reflashes that. So even though you're doing a full page reload, you're gonna still get that flash data come available. So that's a really, really, really cool feature of inertia that is, like, I think would be harder to do with a classic SBA. But because of the way that they the client side and server side adapters work together, it basically takes all the work out of asset refreshing and asset versioning. Like, you literally all you have to do is tell server side, tell inertia what the current version of the assets are, and you're done and it handles it.

Which is also really nice from a development perspective. If you're developing, you're constantly changing your files and inertia, you don't have to, like, constantly hit refresh. You can just click a link and it'll just update automatically for you. No. I agree.

That is super cool. I mean, to be frank, I've been used to rails handling asset management to me for so long that it is frustrating every time that I have to deal with it because I just at this point in my development career, I just think that I shouldn't have to deal with it because I know. Exactly. I literally cannot I mean, shoot. We didn't even have that problem in rails 1 because we weren't serving assets on the project that I was working on.

So Yeah. Yeah. But just it was so long ago. Yeah. And and there's there's some really the last thing you so the last thing I wanna just mention about inertia that we kinda didn't talk about yet and is the fact that inertia visits are not limited to get requests.

So inertia you can make inertia visits for post request, put request, patch request, and deletes as well. And this is really cool. And I it's kind of a complex thing to explain maybe on a podcast, but what it does is it makes forms a lot more like classic rails form submissions, except it's all done by XHR and it's like it's like the the most wonderfully simple thing ever. So I'll explain kinda how it works real briefly here in Laravel and then you guys hopefully can kinda hopefully it'll make sense in rails as well. So what you do is if you have a form, say a view form with all the reactive inputs.

Right? And and then you then a user presses submit. So to submit that data to the 4 you know, down to the server. In that situation, you would still submit that using inertia. So what you would have is you'd have a submit interceptor, right, where you prevent the default browser full page submission.

And then you would say so imagine we're on the create user page. Right? And you hit create user, hit the button, the form submits, we catch it. And then in your JavaScript, in your view page component or in your react page component, whatever, you would then say inertia dot post, or we're creating a user. Yep.

Post. And you would say, we're gonna post that to slash users and pass in the data from that component. So it's just like literally a one liner, but you don't then do a bunch of work after that. You don't say, well, give me the response back and let me inspect the response to see if there was errors. And if there's errors, I'm gonna go and manually update the view, display those errors.

And if there's no errors, well, then we're gonna redirect to somewhere else. You don't do any of that. All you say is inertia post to the user's page. Then what happens is there's 2 paths. There's a happy path the user was created and there's the unhappy path.

There was a validation error, service side validation error. So we'll do happy path first. User you hit the user create page or the user store end point. So that controller end point to store the user. Validation all passes.

It creates the user and then server side in that exit that XHR inertia request, you then just do a classic redirect to wherever you would have normally gone. You you would it was just like a regular standard full page application. You would just do a redirect to wherever you want that user to go after they created the user. So maybe you send them to the the user show page at that point. Right?

So what you would do, you would do the same thing with inertia. You'd literally just say, however, in rails or in Laravel, you return a redirect to that new user's page. So then that redirect is gonna happen in within that XHR request. And what's gonna do is it's gonna go now to that show user page, And that show user page is gonna load. Keep in mind, this is all happening within the inertia the initial inertia post request.

K. So that's that redirects happening. You're now landing on the user show page, and it's just giving you a response. But it it knows that it was an inertia request because that x inertia header actually gets forwarded on when that redirect happens. And then on the user show page, it just returns because it knows it's an inertia request.

It just returns the the the JSON payload back, which includes the the page component name and the page data, which would be the show user page and the user data for that page. So that all then comes back to your create user page. You know, that form and inertia automatically now dynamically swaps out the create user page for the show user page and passes the component. So you don't need to do any work to like redirect the user. It just automatically happens because you're redirecting server side.

So that's the happy path. The unhappy path is validation fails and it essentially works the same way. The valid the user submits the form via post, inertia post that goes to the store controller endpoint. The validation fails. And the way at least this is how it works in Laravel.

When the validation fails, it automatically redirects you back to the page that you're on. So Laravel, if I go to create a user and maybe the it's missing the first name, Laravel automatically does a redirect back to the user page, but it includes some flash data saying, well, there was an error and here's the error, which if you're using server side classic server side templates, you would then take that error and repopulate the page with your old values and display the errors. However, with inertia, you get an inertia response back. So what it'll do is it'll redirect back to the create user page and it will pass along the all the data that you would have for that page anyways. So the create user page, maybe there is no data because you're creating a user, but it would say it's a create user page, and then it would have some data which is the errors that just happened.

Those errors now get passed back to inertia and inertia sees that we're on the same page still. So we went to the create post page. It failed and redirected us back to the create user page, but now we have this bucket of errors. And what and but those errors have been provided from inertia as props. So the page component doesn't change.

So there's no swapping of the page component. So it's you're gonna still be on the create user page, but what it now has is the errors and all you do and those errors come through as props. So they will. You don't have to do any work to update as long as you're taking as long as your page component, your client side page components design that anytime your page create user page component is rendering any errors that come through as a prop. It's just gonna be because all reactive.

It's just gonna automatically display those errors. So like I said, this is a tough thing to explain over over a podcast. But the point is because it's all reactive because that's the way view and react to Svelte work, when that response comes back and has the errors, the props come in and they automatically update. So you literally it it just ends up making for these really, really simple forms because you don't have to do a whole bunch of wrangling to, like, figure out what the response was and update it. It just kind of all happens magically.

And because you're not doing a full page load, you're not having to repopulate all that data that you put in. So they whatever data they put in the form, it's not like you're having to repopulate that because it's all there still because that page component wasn't destroyed. It was it's still persistent there. Does that make sense? Oh, it totally makes sense.

I think it's I think it's very close to what what we would have in Rails. Right? I mean Right. Because Rails does some magic with that stuff. Right?

Like, it kind of like add some stuff to your forms, some JavaScript stuff already. Right? Well, I mean, you if you have Rails not not really. So the way that it would okay. So if I just had Vanilla Rails, right, I would submit my form.

Right? Happy path would redirect me to, like, a show page or an index page maybe. The failed path, you know, I would come back, and what would probably happen is validation things that weren't there before would now suddenly be there because Rails is gonna render that template and Rails is going to conditionally now render some new things. Kinda depends on maybe what gems you have installed, other things like that, but that's that's usually gonna be what it is. Yeah.

But, yeah, it makes sense. Really close. It's really close. Yeah. That's well, that's good.

Yeah. So awesome. I mean, yeah, I think I think the basic gist here that I'm understanding is that inertia is going to make it pretty easy for me as a Rails developer to say, you know what? I have this maybe legacy application or something. Like, I I'm seeing a lot of use cases with already existing applications where I then want to sprinkle some Vue or some React or something on a page or 2 and and have it be a little bit of a spa there for a little while.

That's kind of what I'm seeing. The major use case with Railsbee. There I mean, I guess you could design this with this in mind too. The I don't see anything wrong with that. Yeah.

That's what most people are doing. People are upgrading, like, existing apps to use Inertia, but, like, most people are using it. They're it's kinda like greenfield projects at this point, but that's also because it's a pretty new project. Yeah. Excitement, things like that.

Also always play into this stuff. Yep. Any any other questions from you, Luke, before we kind of roll into PIX here? Do we wanna talk about GitHub sponsorship? Sure.

Why not? So in the notes that you sent us, Jonathan, you said that you had started to get hub sponsorship campaign. You wanna talk a little bit about that before we get rolling? Yeah. Sure.

That's cool. Hey. I was just trying to think of interesting things that might be fun talking about. That's kind of a bit of a newer thing. Yeah.

So this you know, I've been working I've been doing open source for a long, long time. And it's always a challenge working on open source, you know, justifying spending time. And if you're running a business and if you have a family and life's busy, it's difficult to justify committing large large chunks of time to open source just strictly from a business or, you know, personal time management perspective. And so the what I did with Inertia when GitHub Sponsorships came out, I said, you know what? This is a project that I think has legs for the long term, and this is something I wanna work on.

But I've seen how much work Tailwind CSS took and what it takes to make a really, really successful project open source project. And I thought, you know, I wanna try to monetize it in some way to help me justify spending a bit of time on this thing. So I put out the GitHub Sponsorships and it was really I I totally didn't expect much of a response, but I got over 50 over 50 sponsors, which is, you know, not an enormous amount of money, but it's, you know, upwards of about a, you know, $1,000 a month, which was doubled. So it was like $2,000 a month from GitHub for a while, which was awesome. I think that's just I didn't know what to think of the GitHub sponsorship stuff at first.

I'm like, is are people actually gonna help contribute out of their own pockets toward open source? And obviously, GitHub believed that that would happen. And and now, you know, it's it's crazy what some people are are able to do with their GitHub Sponsors, and it's there's some people working on open source full time making making a lot more money than that on, on the GitHub Sponsors, which I think, honestly, is a really, really cool thing for open source. It kinda just it's it's recognizing the amount of time and effort it takes for for people to work on open source and build quality software that, you know, it's crazy how the amount of at least for me, I've I've always worked in the Laravel PHP space. Like, it's it's all free software.

Right? And this is what we're using to run our businesses and everything else. And to me, it only makes sense that some of that money goes back. If nothing else, it just help people spend business hours on open source and not have to feel like they're they're losing money or or, you know, running the issues with their boss cause they feel bad working on it during work hours or whatever. Yeah.

No. I think it's pretty cool too. I I do not think it's the end all be all cause I think there's a limit. Right? To if programmers are the only people contributing to open source, like, there's we're just not gonna have enough money in open source.

But I do think it's a definitely piece of the puzzle. I'm I'm pretty pleased with it myself. Yeah. Yeah. I absolutely agree with that sentiment.

Yep. Awesome. Well, I'm glad that you were able to get some people to support you. So let I guess before we move into PIX, if people wanna, like, get a hold of you, follow you, things like that, how do you recommend they do that? Yeah.

So I'm active on Twitter. That's kinda like the go to place. Just my last name, Reinink, r e I n I n k, on, Twitter. And I talk about, you know, all kinds of inertia and database and Laravel stuff there. So if you're interested, follow me there.

And then, my website, Branink, so same same handle, r e I n I n k. Ca. I blog on there and yeah. And then obviously, inertia, if you if you Google inertia JS, you'll find inertiajs.com if you wanna learn more about that project. Awesome.

We'll we'll make sure that those links are in the show notes too. So sweet. Let's go ahead and move on into picks. Luke, do you have any picks for us this week? My word, do I have a pick for you this week?

We were recently unlucky enough to, lose our server developer who has been building our Kubernetes stack for us. And this means that I've been spending the whole week doing Kubernetes nonstop nonstop Kubernetes this week. I have had used it before back in 2018, but the Kubernetes is in a bit of a state of flux at the moment. So coming back to it, especially if you're kind of running on, Google Kubernetes engine or something, there's been a lot of changes. So my pick for this week is a book on Kubernetes.

It's by another English man, English IT mafia coming in here, and it's called, imaginatively enough, the Kubernetes book. It was updated in February 2020, and it's been very helpful getting up to speed with the Kubernetes. Awesome. Any other picks for us or is that your, is that it for us? That's it.

I'm not going to pick Kubernetes itself. Make that what you will. That's fair. I'd have to plug Chiplaine if, if you did. I feel like anything to make it easier.

You know what? We've got we've got time for a quick rant. Here we go. Kubernetes. Right?

You're learning at Kubernetes, you think. Right? I've got my book. I've got my, my my Docker desktop. I'm gonna go into settings and tick tick the box.

I've got a requirement for Windows, so doing all on Windows. And it's I say to I say to Docker desktop, make me a Kubernetes cluster. Yes? Would you like to guess how much RAM this uses on my my desktop machine? It should take a wild guess how much this ticking this little box cost me.

All of it. It's it's I mean, my guess. It's 3 gigabytes of RAM. And I haven't I haven't made any pods yet. I haven't I haven't run my app.

It's just sitting there. It's eaten for it's the first time, like, this machine's cracked 10 gig. There's 2 sticks of amines missing, and this is the first time. The second one's had to wake up. Yeah.

That makes sense. The typical Kubernetes cluster, right, cluster is you have a box that's just running Kubernetes. Right? All the other stuff comes later, right, after that box. I wonder if if your little ticked box right there is just spinning up the Kubernetes sort of Yeah.

If you whatever you call this, you can see what it is. Background stuff. Yeah. It's all I I found a box so you can see what it's doing, but I mean, the plus side, keep it positive. The the the interface, the API is quite nice.

It's not perfect, but it there's some there's some things to like there. Declarative's all good, but that's that's been around for a while. The the the language of it is nice and clean. So there's there's some good signs. I'm a little confused, though.

I thought all Rails developers use Heroku. So why are you even on Kubernetes? Who uses Heroku? I mean, I know, I know that there's lots of people that do it. Don't get doing your own.

I haven't. I've always been, I've always been very DevOps like person and things like that. And so like, I don't, cause I don't get a lot of value out of personally. But if you don't if you're not really into that, I can totally see that. Just a little joke because I know I know that that's kinda like a big part of Roku's background.

Right? A lot of Ruby riddles. I think so. Yeah. They came from our community.

So, yep. It's Very good. At least that's my understanding. Yeah. Yeah.

No. They're not bad. Just I'm not using them. Okay. I guess guess it's on me now.

So the first thing that I'm picking today is we grew tomato plants like we do every year. So yesterday, our our tomato plants have been producing for, like, about a month. And the average amount that I'm bringing in is a bowl bowl that's like about, you know, 10 or 12 inches big and, like, 6 inches deep. Like, we have, like, I don't know, like, 6 or 7 tomato plants and they go nuts. And it all is because we basically watched some YouTube videos on, like, how to, like, prune them and not, like, kill them and all these things.

And so I'll paste them I'll paste them in here. So if you're like totally there's probably more stuff out there. There's probably somebody that knows how to, like, take care of other kinds of plants, but I'm definitely, like, pushing the watch some YouTube videos if you're if you're doing, like, some home gardening things, you know. Especially if you're, like, growing stuff because it's, like, COVID and everybody seems to be into that this year. Maybe it's a little late for you because maybe your growing season's passed, but definitely for if you keep doing it next year.

So gardening videos, awesome. The other thing that I was that I wanted to plug here. So earlier in the session, Luke was like, hey. I don't wanna have to go to my logs to for queries and stuff. Well, I did some looking during, Well, I'll tell you why.

I can reveal why now because we blasted apps in Kubernetes, and you can't get out the thing. Okay. Maybe what I should give you is a link to a tutorial on how to read logs in Kubernetes because that that I think is your actual problem then. Alright. But I I actually I couldn't find a gem that did that.

But I did find some pretty sweet gems that give you all sorts of extra query, debugging, tracing to the exact spot in your code, explaining. So I'll just link those because they were cool anyway. So, yep, those are my picks. Jonathan, did you have anything for us? Yeah.

I didn't have anything at the beginning, but kind of as you guys were talking, I've come I've come up with 3. One of them is, as I've mentioned earlier, project that I was involved with is called Tailwind CSS. And this is a, kind of a unique approach to building a unique approach to, CSS and building applications that I would highly recommend to your audience to check out. It's become really, really popular, and it's honestly changed the way that I, you you know, handle CSS. I pretty much don't write CSS anymore because I'm using Tailwind, which is if that's confusing to you, then it's you should definitely check it out.

And I will warn you if you've come from, like, a SaaS or a less background or just even just plain old CSS, And you look at this approach, you will probably be disgusted at first, but it is really, really great. Give it a chance, and I pretty much guarantee you'll be making web UI faster than you were before. And, the maintenance is wonderful moving forward because it's just a lot easier to manage because it's all in HTML and not in CSS. So pick number 1, tailwind CSS. Pick number 2 is, I mentioned earlier that I put out a database course.

Now I should mention that this course was primarily primarily designed for Laravel developers. Well, totally designed for Laravel developers, but there is a lot of crossover between Laravel's ORM, which is called Eloquent and active record in Rails. So there's some interesting techniques. So if you are a Laravel developer, listen to this or just even a Rails developer who wants to learn some techniques about databases and how to make your databases database queries faster, check out my course, eloquentdashcourse.reninc.ca, which I'm assuming will end up in the notes throughout. Yeah.

So that's my second pick. And my third one is less software related, but I live on a farm. And this week, I've so little bit of background. I live on a farm, so I have wireless Internet, which basically means that I have an antenna on my property that points to another antenna about 2 kilometers away for from this Internet service provider. And this year, the tree line between us and the tower that we point to is, like, really growing in.

The trees are really growing in. The leaves are really growing in. Our Internet's getting more and more unstable. So I've been pricing it as a new hardware because it turns out that if I move my antenna about a 100 meters south of where my house is right now, which is out in basically the middle of my field. I have a small little 50 acre property.

So we have a bit of land. So I have the flexibility to move the tower. I get perfect line of vision to this tower. But the problem is I have to then get it from there to my house and my and my barn as well. So I've been playing around and been researching a bunch of Ubiquiti products.

And if you are in the sim similar sort of position as me, I can't recommend this stuff enough. It's so cool. I've been playing around with, a product called the nano beam, which are these, like they're really, like, they're small little things or maybe, like, they're circular, maybe 6 or 7 inches wide, and they're rated for, 15, I think 15 to 20 kilometers. Like, I only need it for, like, 300 meters or something. And it just makes it really, really easy to create these wireless connections between, like, long range wireless connections between different places in my property.

So whatever. I'm just kinda nerding out on the Ubiquiti products right now because I'll give I'll give you a plus one for that. Yeah. You've worked with them before? Yeah.

So my a job that I had, like, over a decade ago, one of the things that we did is we broadcast auctions. And a lot of the barns that these auctions will be done in, they didn't have good Internet connections. And so we were using wireless equipment all the time. And we swore by this by Ubiquiti. So just just saying.

That was 10 years ago, but but as far as I know, like, you know, good stuff. Yeah. It's it's pretty cool stuff. I actually have one already set up in my property between 2 spots, and we actually had a wire like, a buried wire under the ground and it gave us all kinds of trouble. And then we put in a couple nano beams and it's just like it's it's almost like they are wired because that's what it looks like from a network perspective.

And they just they're they just work flawlessly. So that's my picks. Awesome. Alrighty. Well, thanks everybody for joining us, and we'll see you again another time.