Hello, and welcome to Ruby Rokes. I'm John Epperson, and we are we have a couple of panelists today.
We have Luke I welcome, and we have Jonathan Nni.
Your thing like cut off and gave me the dots right as I was looking at it, and I was like, oh my gosh, Rinie, welcome. Jonathan is the author or creator however you want to say that of a nurser 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 to a nursery after that.
Yeah, for sure.
I am a web developer and I've been doing web development for almost two decades by now, and I hang out mostly in the Layra bell community, so I contribute to that framework and kind of like doing all things PHP and yeah, my main projects have been some libraries and some phree libraries. I was also involved early on in the tail when CSS framework if you're familiar with that. Me and my buddy Adam Weathern built that, and more recently I have focused on inertia as well as a bunch.
Of database stuff.
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 things I mostly work on. I work for myself. Outside of that, I run a small SaaS business solo SaaS 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 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 layer bel and you can
use classic service side routing, classic server side control. But the only difference is with inertia there is no server side views. All the views are done with view or they're done and react or done using spell And what happens is you basically return some data from our controller and where you'd normally return a view and they'll put
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 EERB 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 one 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 saying okay, this is the inertia request, and it'll fire back the data
needed for the next page. And the data is the JavaScript page component, be view or react or whatever, the
data the props for that component. And then what happens is client side, so that's made as an age AX request, that data comes back, the 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 three of the popular client side frameworks view Reaction SPELT, so it's dynamically swapped out and it's given its new page props. And the big, big, big benefit there is one when you're navigating from one.
So there's like three key benefits.
One, you're navigating page page, you're not doing full page reloads, so there's a performance benefit to that. Two when it's doing that because you're not doing a 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 three and I knew this was going to happen.
I don't remember my third third benefit, but oh, the third one is the obvious one. You get to build an app using client side technology. And really kind of what pushed me down this road is I was building more like in my applications that I built and I build, I always use layravel, which is very similar to rails. So for this audience just kind of 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 UI's work a certain way that just kind of 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 renderview, which would then have view components mixed into the page.
So what would happen is the response would come back from the server, then view would kick in the gear, and any of the view 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 that kind of comes with a whole bunch of interesting problems. I mentioned the flicker and just kind of having to manage each one of those separate components.
So by going this way with.
A NURSE, you're really like fully committing to client side render views, So you give up server side rendered views. That is a trade off, but 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 view 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 kind of a longer description. I would say that, like, I definitely built it for people who have traditionally worked with server side rendered applications like frameworks like again layer Bell, 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 ar rest API or graphic you LAPI.
So it's definitely targeted.
At that audience, and kind of, as I've said to people before, I kind of joke that Inertia is like the gateway drug to creating single page applications because if you're coming from a monol with background in er should just makes it so easy to get up and running with creating like what essentially feels exactly like a client side single page app of kind of 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 side and things like this, and there's a lot of interest. So it kind of 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 going to create like this kind of 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 is Jason, so kind of a bit like an inline API kind of thing almost like I'm just kind of rendering Jason almost there, And that's more or less how my page is going to run, and that's how my back end's going to run. And then I basically just have a single page.
App on the page.
That's it, and all these props get passed down and I just do with it what I want to in that single page.
Of Yes, so a couple interface as 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 view 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 Jason and your client.
Side page components. So it's the piece that connects the two.
But unlike with a classic app, you know, with view router, React router, whatever, you don't have any client side state management at all, So you're not using any client side
like view x 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 side's vieux library or database or whatever you want to call it, and then rendering
components based on that. Basically, every single time you visit a page, the data's coming straight from your controller and go into your your client side page component.
All right, I got a dumb question. You're going to have a few votes from me. So I wanted to kind of have a go at this. And I've been building this view app. And the way I populate my VU is it a view or VU view? 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 with 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 to get returns. You've got your view building there. Yeah. Now in the examples on the inertia JS site, then it uses Laravelle. And we could take a nice divergence here because I'm starting to get Laravelle envy some of the tooling, some of the tooling that you show off on the inertia jas website. I don't. I didn't think the Ruby or rails community have. I'm
sure John no more. But there's a there's a plug in where you can see the database queries being done on that page like the sequel, and I saw that. Oh 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.
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 Rails examples on the Inertia site.
No, I don't actually no, I didn't find a tab. Where's the tab?
Every code snippet, every code snippet there is on the site? It defaults to Larvel, but you can switch it over to rails.
Oh no, some basic fail going on here.
No worry.
So what I'm saying is you're very appreciative of how awesome Laaravel is on a review podcast.
All right, 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. I can't find this finger I don't believe it.
Exists, right, now I'll take a screenshot.
Yeah, So the tool and layer bel in the PHP community it's called it's called the PHP debug bar, and there's a Layervell debug Bar version built on top of that.
And it's fantastic because it's exactly what you can.
You know, you can figure out all your database queries and your logs and whatnot. But what the layravel debug bar does is it just puts them right in the bottom of your screen, just like it's almost like a Chrome console right where it shows you exactly what database queris you're making, and what models you're loading from the database, and how much memory you're using. It's super super helpful, helpful you identify N plus one issues and slow queries and stuff.
Where's my Rails debug bar? That's what I want to know, Moving swiftly on from my basic ability to use a website. So I was asking about the way you cook it in what there's for the benefit of people who can't use website like me. How does Rail send down that lump that cut because there's two things, aren't there. There's the kind of layout and there's the and the props.
Yes, yeah, yeah, so I'll walk you through.
That's I often failed 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 it as best I can kind of using Rail's lingo, but I'm not super familiar with with it all, but like.
Work with me.
So basically, a request is going to come in, so through the very first time that someone hits your inertia application, your inertia rails application. What's going to happen is it's going to notice that it's just it's a standard full page visit, right, And what it's going to do is it's going to hit rails and it's going to see that it's not an inertial request. So it's not going to return some JSON. It's just going to go through
the normal flow. And what it's going to do is it's going to return your base ERB template, so your layout file, right, and that layout file, well, it's just like a standard layout file that has your head which is going to have your script tags and it's gonna have your style tags kind of just your standard layout. The difference is what it's not going to do is it's not going to keep in mind that someone may
land on your app on any different page. It doesn't have to be the homepage, of course, of the index page. It could be any page in your application, right, So it's going to see that request coming in, so it's going to return or it's going to server side render that layout. Except the only difference is within the body of that server side rendered HTML file, it's not going to 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 going to have a bunch of HTML server side HTML generated and rendered. What it's going to do instead is there is a base DIV that it's 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 based div, your client side app, view, React whatever mounts to that.
But what happens is server side it passes this page object so Adjason 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 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 ATIV has an idea of app, which is what your Viewer React apps can amount into, and then it has an attribute called data dash page and the contents of that data dash page attribute is just a string, but it's actually a Jason encoded string, and what it's including is all the necessary information that INERTI needs in order to boot up that particular client side page component.
So it's going to include two main things that the most important things to know are. One the component name, So the component name is going to be the viewer React component page component name, so in this case it might be the user page, which is going to have a corresponding user page dot view file or user page dot react file. And then the second piece of information that's going to be in that Jason payload is the props, which is the data. I call them props because they're
considered when you're working with viewer React. Props are the properties there, the attributes the data that gets passed to that component. So it's essentially the data.
So if you imagine now if we hit the Rails app, it's the user's page which gets which causes the routing to go to the user's controller, the index method of the user's controller. Your index method is going to go off, and it's gonna use active record to get some data from the database for the users that you want to display on that page.
And then in a classic.
Rails app and jump in if I get any of the terms wrong here, gents, because I'm you know, I'm gonna use more kind of lingo that I know. But what it's going to do is normally you would then return an ERB template that you pass the user index view too, and pass the data which is the users you just looked up from the database, use an active record, and that's going to go off and generate your HTML. In this situation, you would instead return an inertia response.
So it's but 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 to return the page component name, so the client side page component name and the data
for that component. Then the 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 going to display the layout. We're going to render its server side, and we're going to inject that base div with the idea of app and with the data page attribute with all the data for it, and then we're just going to render that out. It's kind of just
a standard htam olt 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 want to view the user, when inertia does is it intersect that click that page visit and it then makes the XHR request to the server.
It's going to hit in the exact same way.
Now imagine it's going to hit your user's controller again, but this time it's going to hit the show method.
So again, what would you.
Do just an standard layer or standard layer belt 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 user show page with the user data. Except again with inertia, you wouldn't do that. You would do you'd return an inertial 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 and their last name and whatever else. Right, So when that request comes through the XHR request, what inertia does is it passes through an ex inertia header which is set to true so that your rails app knows that this isn't a full pagreload. This is this is like an inertia request, So it's an XHR request, and what it does instead is it returns not the full body and the full layout and everything else.
It just turns the Jason data that it requires.
So that's the same Jason data that we 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 Jason and nothing else and it returns out obviously is adjacent response, which that's gonna have your component name and all your props and then kind of getting back to what I explained earlier, and
Nursa'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 data the props for that component and like service 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 kind of 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 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 kind of like the trickiness that we do with the reality is from a development experience for people who are using rails or layervell who are kind of used to working with that, Hey, I got a controller, I got a controller method, I got to get some data from the database and I got a return of you with some data. It literally feels the exact same way, except the difference is you're ending up.
You're working with viewer React templates, you're not working with EARB templates.
All right, I found it. Now It's super easy. And 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 an inertia under school rails gem that does it for you.
Yes, yes, I should have mentioned that probably too. Yes, so you don't got to 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 that.
It's not magical at all. It's in its most basic form. It's imagine this.
You have a page response, The inertia gem looks to see, Hey was the x HR Sorry was the ex inertia header set to true? Well yeah, if it is, then
return Jason instead of HTML. It's like literally that basic, and there is you know, some other interesting features that kind of go along with it, such as automatic asset refreshing and partial reloads so it does get more complicated, but in its basic form, like 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 layer bel package for this as well, so it kind of 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's really does not take that much.
We actually have a page that kind of explains.
A spec I kind of 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 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 created an inertia cold Fusion adapter, and there's there. I know there's been one creative 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 library I've always worked with the language that I'm familiar with. So I've worked with PHP and layer Vell and it's not been that or even JavaScript, and it's not been that hard making the you know, maintain the library.
The challenge where the ertia is I'm finding myself becoming more proficient in other languages and frameworks because in order to maintain the Rails adapter, I got to now be more of a Ruby expert on anything about an expert I should even said that, but like I got to know the basics of those frameworks.
But fortunately I've had some a lot.
Of people kind of like jump in and help out on framework specific adapters. Really that 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 view the React and the Spelt adapters are the tricky kind of piece because they're all they kind of got little differences. The way they do dynamic components swapping, the way they
do data handling, the way they do reactivity. All that stuff is it's a little bit different each one of those client side frameworks.
So that's kind of 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 to view adapter, another guy manages the React adapter, and another guy manages be spelt adapter. So that's been It's really quite a collaborative project in that sense.
All right.
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 want to 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 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, you know, yeah, I know that Electra might be better or no, it might be better for creating certain apps nowadays, but I'm just so stinking fast with layer Bell 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 it makes sense for you to have a full rest API and a full graph QLAPI, then Inertia maybe 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 with all the old off stuff and all that Hoopla and the separate hosting account and everything else.
Like, my goal is that I just want to build an app.
I want to get some data from the database to use an active record, and I want to spit that to I you and render it like that's what I want to 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 an Android app, and maybe you have maybe you have a 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 HOLYPI. 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 LAYERVELT and built with just Classic rails using Classic Rails service side rendering or layveel service side rendering, you've already made that decision. You've already said this is the web app. And if I ever need an API, well, then I going to go off and build this a great API for it. So
that's really where inertia fits. 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 Anertia to be for those developers, those who said, you know, I want to build a service side application. I was gonna build it with layer bel or I was gonna build with rails using the standard monolith approach. I've already decided
I'm not going to build an API. Well, then inertia is a wonderful fit because then it allows you to build a rich client side application using viewer react will 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 web app tool.
And even in those applications I've have 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 layer of bel 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's still made sense to build a web app using using Reactor, View and Inertia without an API. And then literally I have like five endpoints, five API en points for this core functionality that I'm making available natively 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 were 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 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 indexing View and React apps. The 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 side, or I was building anything that had a public face that where 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 applications where you need to log.
In all those kind of tools.
And one great use cases 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. Maybe you're building a SaaS app. You have a bunch of documentation that you want to make sure it's SEO friendly. You have your pricing page, and you're about page, and all those feature pages. You could build all that stuff using RAILS with classic server side rendering, will 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 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 it the old way. So the old way I do this is anytime I needed some view of view component or React component in my application, I would be using classic server side rendering in layer vow, which would return my full document, which would have all
the page content, but somewhere in the page. So imagine it's maybe like a create user page, and maybe I want to create the form to create the user.
Maybe I wanted to.
Build that in view because I like the reactivity of it. I like be able to handle errors and everything else, just kind of 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 view has to viewed 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 kind of like causes the page to become longer, and you know, things move around, and if you have a lot of view components, maybe you have a drop down component or 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 view or Rails or sorry, a view or React app, where when you go to visit another page, it's going to just render that new view component and nothing's getting destroyed in the in between because you're not doing a full page reload.
View and React are long living.
So when I go to the next page, it's going to load that file in the background, it's going to load the data in the background via that exit tour request, and then when it's ready, it's going to swap it out and you can you know, there's load ways to have loading graphics and stuff 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 really really smooth.
So you sound like you care a lot about kind of responsibility and user experience. Yes, very much, So let's talk milliseconds here. Let's talk some real numbers, because I can see we could take an enormous effort into kind of making this to help people improve the experience so they use this. 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 two hundred 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 painted it on the page, the time that it needs to download, and
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 been very frustrated in the past building rest APIs or even graph Q on the graph QL is amazing, but you can run into performance issues really easy with graph u L. If you're not careful, you can run into n plus one issues just depending on the sort of graph of
data you're returning. 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 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 layer val is that every single control or method you are going to get the data
exactly as you need it for that page. There's no generalized A there. It's like, okay, I'm displaying the user's page. I want to go to the database and I want to get these ten users if it's paginated for example, and I want to get their name, and I want to get their ID, and I want to get their email address, and maybe I want to egarload their company company along with it. So what inertia And this isn't really an inertia feature. This is really just this is
really just a rail. This is like a monolith features, like when each end point 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 love databases and I love writing learning how to you know, kind of make the most of the database, create proper indexes and return the minimal amount of data, and that run the fastest career as possible. That's that's stuff that I'm super interested in and focus on. So roundabout way of answering your question, I like two hundred 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 tradeoff you get when you build a client side application. So one of the trade offs we've talked about already is you the sdo tradeoff if SEO is important to you, probably not going to make sense to build a fully client side rendered application unless you have some sort of
service side rendering in place. And there's all kinds of fancy tools nowadays even to do that with JavaScript stuff. But you know what I'm saying, if SEO is important to you, you're not going to want to have client side rendering as your primary way. So the other trade off is that you now need to send all that to
all your client side views. So all your page components, all your view components, are 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 kind of 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 applications, 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 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 cash right and 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 rails app works, and the page can load like loads extremely quick, So I actually have a demo app if you want to try it out, if you call the demo apps called ping CRM, which is available on the Inertia Gas website, and you can actually,
you know, click around this application and see exactly what the performance is like.
And I think, like, so it's hosted on I host it.
On Heroku, and I do that intentionally because anytime you host in Heroku, there's even a performance cost in saying having a one off linot or Digital Ocean, you know, server, because one for one, the database is the Postcrest database, which is not hosted on the same site as the actual web dinos, so there's always a performance cost that comes with that, which often you know, of course makes sense if you want to have multiple web dinos and whatnot. So I've hosted 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 one hundred milliseconds, and I think, you know, that's a pretty awesome experience.
I've tried it. It is disgustingly quick.
That's what I want to hear.
For me in the UK comes back in well under one hundred well under one hundred to the extent that I'm quite suspicious that you're loading the next page the ground that terming me first or doing some kind of dirty trick like that isn't you know?
It's funny that you mentioned one hundred percent. Absolutely it is. Yeah, absolutely, it is hitting 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 want to egerload the data, what we can do is eiger load the next JavaScript page component that
that page, that link would require. So even if you are using code splitting, we can be smart about eger loading that next page component that you may want.
To 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 kind of 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 kind of 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 show user page. I've got a working prototype where it could show kind of 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 Pinxi r M demo doesn't do any of that, 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 a link to view a new page, that inertia allows you to will allow you.
To do that. It technically 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 more or less said that to me. The controller in NBC right, really is an API provider and you're just consuming that API with your view and 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, you're just leveraging that and making it really easy for people 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 difference is with a rails or layer ofl app, you've accepted that there is this type coupling between this back end controller and the front end view.
That's just an accepsolutely, you know. And you know, some people.
Say, well, that coupling's bad because now I can't use the sendpoint 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 thirty 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, 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 proving 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, 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 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 like essentially what are considered like scroll areas within your UI. So one really common use case for this is imagine you have kind of like your
standard layout. Left hand side is your navigation and the right hand side is your content, and maybe along the top you have a bar right when you scroll the content, you maybe want to scroll the content but not have your left hand nav change.
Or even the other way around.
Maybe when you scroll the content you want your left hand ab to follow with you or whatever. Right, So you do this using scroll areas, you know, overflow auto and stuff with CSS to kind of 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 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 three hundred pixels.
It's like that, 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 in or she does really well is
asset version ing. 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 at that moment, you had to fix a bug or do something in that template and you redeployed it, so you would deployed
those assets to the server. The problem is right now is with a typical client side rendered application is if 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 going to see the old page template, which might be fine, or it might not because you might be expecting data 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 Appleic application craft simply because you deployed.
An update to the application.
And this is something that rails and layerbelt developers never have to worry about if you use some service side render views because when you go to the new page, it's 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 viewer, React apps, but it's complicated and they use people use service workers and I'm not going to get into details of how that gets solved, but it's kind of 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 service side inertia adapter working with a client side inertia adaptor, and they're working together to make sure that things are working properly. So what happens is every single time you make it an inertia visit, we keep track of you know what, Let me back
up before I even go there. It might be zero to explaining it this way. When you define your inertia set up in Rails, you have the option on every single page, like, you know, kind of like does it does Rails have this concept of like some sort of like base like application service provider where you do kind of like default work. Could it like happen in like a middleware or just like kind of like something that gets run on every single page request?
Is that right?
So imagine I forget exactly how the gens who put together the inertiative 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 yours. 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 layer.
Bel is I literally just do I just get an empty five 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 past to the client side.
So that's one.
And 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 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 want to
go to the user index page. Well, you you click the user index page, Inertia goes off and it makes the XHR request, the inertial inertial 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 two rails, then rails the rails. Inertia adapter says, okay, I got this request coming in, it's saying that the current asset version is one, two, three, but we can see now that it's a new deploye has happened and the new asset version that is actually four or five six. And what Inertia does is it actually stops the request at that point and it then gives returns a four oh I believe it think it's a yeah it returns.
So imagine this XHR request gets an immediately immediate four oh nine conflict response back from Rails, and then what happens is Inertia gets that four h nine conflict response back and it says, oh, assets are at a 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 at a date because the server just told me that, and it just cuts that XHR INNERSI 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 off the opportunity to use cash bussing 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 want to deploy them so they can continue browsing your Inertia app like a classic SPA until the assets are aut a date, and then they're gonna be forced without their they won't even notice really that it's happening other than 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, that four nine response, and like we automatically reflash data, so if there was any if you had any flash data that was going to be used, it automatically reflashes that. So even though you're doing a full page reload, you're
going to still get that flash data come available. So that's a really, really, really cool feature of Inertia that is, like I think it would be harder to do with a classic SBA, but because of the way that the clients side and service 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 service 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 because 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 b 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 one because we weren't serving assets on the project that I was working on.
So yeah, yeah, it was so long ago.
Yeah, and there's there's some really the last thing, you so, the last thing I want to just mention about inertia that we kind of didn't talk about yet, and is the fact that inertia visits are not limited to get requests, so you can make inertia visits for post requests, put requests,
patch requests, and delete as well. And this is really cool and 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 ya xhr, and it's like it's like the most wonderfully simple thing ever. So I'll explain kind of how it works real briefly in layer Bell and then you, guys, hopefully you can kind of 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 React of inputs right, and then you then a user presses submit to submit that data to the form, 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 where you prevent the default browser full page submission and then you would say, so imagine we were on the create user page right and you hit create user, hit the button, the form submits, We catch it, and then in your jabscript, in your view page component or in your React page
component whatever. You would then say inertia dot post if we're creating a user yet post and you would say, we're going to post that to slash users and passing 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 is errors, and if there's errors, I'm going to go and manually update the view display those errors.
And if there's no errors, well then we're going to 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 two paths. There's a happy path the user created and there's the unhappy path. There
was a validation error service sidevalidation error, So do happy path. First, user, you hit the user create page or the user store endpoint, so that controller endpoint to store the user validation all passes, it creates the user, and then server side in that exit that XHR inertial request, you then just do a classic redirect to wherever.
You would have normally gone.
You you would if it was just like a regular standard full page application. You would just do a redirect wherever you want that user to go after they created the user, so maybe you send them to 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 layer bel you
return a redirect to that new user's page. So then that redirects going to happen in within that XHR request, and what's going to do is it's going to go now to that show user page, and that show user page is gonna load. Keep in mind, this is all
happening within the initial inertia, the initial inertia post request. Okay, so that that redirects happening, you're now landing on the user show page and it's just given you a response, but it knows that it was an inertial request because that ex 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 Jason payload back, which includes 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 user submits the form via post inernship post that goes to the store controller endpoint, the validation fails, and the way at least this is how it works in layer about when the validation fails, it
automatically redirect you back to the page that you're on. So, Lara Bell, if I go to create a user and maybe it's missing the first name, Larva automatically does a redirect back to the user page, but then 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 air 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 so redback, redirect back to the create user page, and it will pass along all the data that you would have for that page anyway. 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 but in 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 is 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 designed that anytime your page create user page component is rendering any errors that come through as a prop, it's just gonna because it's all reactive,
it's just going to 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 reactings felt work. When that response comes back and has the errors, the props come in and they automatically update, so you literally 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 that whatever data they put into the form, it's not like you're having to repopulate that because it's all they're 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 because.
Rails doesn't magic with that stuff, right, Like it kind of like adds some stuff to your form, some JavaScript stuff already.
Right, well, I mean 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 going to render that template, and Rails is going to conditionally now render some new things.
Kind of depends on maybe what gems you have.
Installed other things like that, but that's that's usually going to be what it is.
Yeah, but yeah, it makes it really close. It's really close. Yeah.
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 rail developer to say, you know what, I have this maybe legacy application or something like. I'm seeing a lot of use cases with already existing applications where I then want to sprinkle some view or some react or something on a page or two 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 rails
B there. I mean, I guess you could design this with this in mine too. 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 there. It's kind of like greenfield projects at this point. But that's also because it's a pretty new project.
Yeah, excitement things like that also, always playing to this stuff. Yeah, any any other questions from you, Luke before we kind of roll into picks here?
Do we want to tool amount gate, hubs, bumster shit?
Sure? Why not?
So?
In the notes that you sent us, John Nathan, you said that you had started to get hub sponsorship campaign. You want to talk a little bit about that before we get wrong?
Yeah, sure, that's cool.
I was just trying to think of interesting things that might be fun talking about. That's kind of a of a newer thing, is 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 an 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 gethub 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 want to 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 want to 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 totally didn't expect much of a response, but I got over fifty over fifty sponsors, which is, you know, not an enormous amount of money, but it's you know, upwards about you know, one thousand dollars a month.
Which was double.
So it was like two thousand dollars a month for getthub 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, are people actually gonna help contribute out of their own pockets toward open source? And obviously Gethub believe that that would happen, and and now you know, it's it's crazy what some people 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 their GitHub sponsors, which I think, honestly
is a really really cool thing for open source. It kind of 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 at the amount of at least for me, I've I've always worked in the layer vel, 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, to just help people spend business hours on open source and not have to feel like they're they're losing money or you know, running the issues with their boss because they feel bad working on a during work hours or whatever.
You know, I think it's pretty cool too. I I do not think it's the end all be all, because 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 going to have enough money in open source. But I do think it's a definitely piece.
Of the puzzle. I'm pretty so pleased with it myself.
Yeah, yeah, I touly agree with that sentiment.
Yeah, awesome. Well, I'm glad that you are able to get some people to support you. So let's I guess before we move into picks, if people.
Want to 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 kind of like the go to place. Just my last name renik ari e I n I n K on Twitter, and I talk about you know, all kinds of inertia and database and layer bell stuff there. So you're interested follow me there, and then my website reanik so same same handle, Renick ari I n I n K dot ca A. I blog on there, and yeah, and then obviously inertia if you if you google inertia JS you'll find inertiajs dot com if you want to learn more about that project.
Awesome.
Well, we'll make sure that those links are in the show notes too. So sweet, let's go 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, non stop, non stop Kubernetes this week. I have had used it before, back in twenty eighteen, 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's been
a lot of changes. So my pick for this week is a book on Kubernetes. It's by another Englishman, the English it Mathia coming in here, and it's called imaginatively enough, the Kubernettes Book. It was updated in February twenty twenty and it's been very helpful getting up the speed with the Kubernetes.
Any other picks for us? Is that you're Is that it for us? That's it.
I'm not going to pick Kubernettes itself. Make of that what you will.
That's fair.
I'd have to push chaplaine if if you did, I feel like anything to make it easier.
Do you know what we got? We've got time for a quick rant. Here we go. Cubernettes. Right, you're learning a Cubernettes, you think. Right, I've got my book, I've got my my my Docker desktop. I'm going to go into settings and tick tick the box. I've got a requirement for Windows, so doing all the windows. And I say to I say to docer desktop, make me a Kubernettes cluster.
Yes.
Would you like to guess how much RAM this uses on my desktop machine? It's to take a wild guess how much this ticking this little box costs me?
All of it?
It's free 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 eating free. It's the first time this machine's cracked ten gig there's two sticks of raminist scene and this is the first time the second ones had to wake up.
Yeah, that makes sense.
The typical Kubernetes closter 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, ground stuff. Yeah, I found a box. You can see what it's doing. But I mean the plus side, keep it positive. The the the interface, the a p I is quite nice, not perfect, but there's some there's some things to like. The declaratives 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 used Roku.
So why are you even on Kubernetes.
I know, I know that there's lots of people that don't doing around. I haven't.
I've always been I've always been very devaps like personally and and things like that, and so like, I don't because I don't get a lot of value at it 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 kind of like a big part of Roku's background, right, A lot of I think.
So, yeah, they came from our community. So yeah, it's least that's my understanding. Yeah, yeah, no, they're not bad. Just I'm not using though. 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 tomato plants have been producing for like a bottom month, and the average amount that I'm bringing in is a bowl fowl. It's like about, you know, ten or twelve inches big and like six inches deep.
Like we have like I don't know, like six or seven 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, probably somebody that knows how to 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 you're growing seasons past, 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 want to have to go to my logs too for queries and stuff.
Well I did some looking during Well.
I'll tell you why. I could reveal why now because but blasted apps and kubernettes and you can't get at the thing.
Okay, maybe what I should give you is a link to tutorial on how to read logs and kubernetes, because that that I think is your actual problem. Then all right, But 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 like 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 it kind of as you guys were talking, I've come up with three. 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 and 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 handled CSS. I pretty much don'trite 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 SAS 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 you'll be making webuis 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 one, tail in CSS. Pick number two is.
I mentioned earlier that I put out a database course. Now I should mention that this course was primarily primarily designed for layveel developers.
Well totally designed.
For layravel developed developers, but there is a lot of crossover between larravels or m which is called Eloquent and active record in rails.
So there's some interesting techniques.
So if you are a layerbel developer listening to this, or just even a rails developer who wants to learn some techniques about databases and how to make your databases your database queries faster, check out my course eloquentdas course dot renik dot CA, which I'm assuming we'll end up in the notes. So 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 so a
little bit of a background. I live on a farm, so I wireless at Internet, which basically means that I have an antenna on my property that points to another antenna about two kilometers away 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 grown in, the leaves are really grown in and our internet's getting more and more unstable.
So I've been pricing out some new hardware because it turns out that if I move my antenna about one hundred meters south of where my house is right now, which is out in basically the middle of my field of a small, little fifty 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 barn as well. So I've been playing around and been researching a bunch of ubiquity products, and if you are in the 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 Nanobeam, which are these like they're really like they're small little things or maybe like they're circular, maybe six or seven inches wide, and they're rated for fifteen I think fifteen to twenty kilometers, Like I only need it for like three hundred 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
of my property. So whatever, I'm just kind of nerding out on the Ubiquity products right now.
Because I'll give you a plus.
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 would be done and they didn't have good Internet connections and so we were using wireless equipment all the time and we swore by this by Ubiquity. So just just saying that was ten years ago. But as far as I know, like you know, good stuff, it's.
It's pretty cool stuff.
I actually have one already set up on my property between two 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 of nanobeams 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 just work flawlessly.
So that's my picks.
Awesome alrighty, well, thanks everybody for joining us, and we'll see you again.
Another that