Speaker 1: Hello, and welcome to Ruby Rokes. I'm John Epperson, and
Speaker 1: we are we have a couple of panelists today.
Speaker 2: We have Luke I welcome, and we have Jonathan Nni.
Speaker 1: Your thing like cut off and gave me the dots
Speaker 1: right as I was looking at it, and I was like,
Speaker 1: oh my gosh, Rinie, welcome. Jonathan is the author or
Speaker 1: creator however you want to say that of a nurser
Speaker 1: JS and we just have him here today to yap
Speaker 1: about it. Can you just give us a little bit
Speaker 1: just to start out about your background and how why
Speaker 1: you might be famous, and then we can go ahead
Speaker 1: to a nursery after that.
Speaker 3: Yeah, for sure.
Speaker 4: I am a web developer and I've been doing web
Speaker 4: development for almost two decades by now, and I hang
Speaker 4: out mostly in the Layra bell community, so I contribute
Speaker 4: to that framework and kind of like doing all things
Speaker 4: PHP and yeah, my main projects have been some libraries
Speaker 4: and some phree libraries. I was also involved early on
Speaker 4: in the tail when CSS framework if you're familiar with that.
Speaker 4: Me and my buddy Adam Weathern built that, and more
Speaker 4: recently I have focused on inertia as well as a bunch.
Speaker 3: Of database stuff.
Speaker 4: I'm a big fan of databases and optimizing databases and
Speaker 4: active record and so I put out a course recently
Speaker 4: about that. So those are kind of the things I
Speaker 4: mostly work on. I work for myself. Outside of that,
Speaker 4: I run a small SaaS business solo SaaS and that's fun.
Speaker 2: That's pretty much me awesome.
Speaker 1: So, since we were planning to talk about inertia, let's
Speaker 1: go ahead and dive in what exactly is inertia.
Speaker 4: Yeah, so it's always fun when you come up with
Speaker 4: a new project that's a little bit different than other things.
Speaker 4: It's certainly been one of the most challenging things. It's
Speaker 4: just explaining what inertia is. And kind of the simplest
Speaker 4: way to describe it is it's a way to build
Speaker 4: single page applications without needing an API, Meaning you can
Speaker 4: build a single page app using a classic server side
Speaker 4: framework such as Rails or layer bel and you can
Speaker 4: use classic service side routing, classic server side control. But
Speaker 4: the only difference is with inertia there is no server
Speaker 4: side views. All the views are done with view or
Speaker 4: they're done and react or done using spell And what
Speaker 4: happens is you basically return some data from our controller
Speaker 4: and where you'd normally return a view and they'll put
Speaker 4: that data. You instead return a JavaScript page component. So
Speaker 4: just imagine a JavaScript page component being rendered on the
Speaker 4: page instead of like an EERB template I guess is
Speaker 4: what they would be considered in rails. And obviously that's
Speaker 4: client side rendered, so it's not server side rendered. But
Speaker 4: what happens is every single time you navigate from one
Speaker 4: page to the next, inertia intercepts any page clicks so
Speaker 4: that you don't do full page reloads, but instead, when
Speaker 4: you click a link, inertia will intercept that link click
Speaker 4: and instead of doing a full page reload, it'll run
Speaker 4: off to the server making what's called an inertia request,
Speaker 4: and the server will pick it up saying okay, this
Speaker 4: is the inertia request, and it'll fire back the data
Speaker 4: needed for the next page. And the data is the
Speaker 4: JavaScript page component, be view or react or whatever, the
Speaker 4: data the props for that component. And then what happens
Speaker 4: is client side, so that's made as an age AX request,
Speaker 4: that data comes back, the response comes back, and then dynamically,
Speaker 4: client side, the page component is swapped out, and that's
Speaker 4: using dynamic components, which is a feature of all three
Speaker 4: of the popular client side frameworks view Reaction SPELT, so
Speaker 4: it's dynamically swapped out and it's given its new page props.
Speaker 4: And the big, big, big benefit there is one when
Speaker 4: you're navigating from one.
Speaker 3: So there's like three key benefits.
Speaker 4: One, you're navigating page page, you're not doing full page reloads,
Speaker 4: so there's a performance benefit to that. Two when it's
Speaker 4: doing that because you're not doing a full page reload,
Speaker 4: it's not having to reboot, view or react every single time.
Speaker 4: So it's like really like silky smooth kind of experience.
Speaker 4: It's just like a it's like you're working with an SPA,
Speaker 4: except you're not. You're just navigating from one page to
Speaker 4: the next, and it's just swapping out those components, those
Speaker 4: page components dynamically.
Speaker 3: And three and I knew this was going to happen.
Speaker 4: I don't remember my third third benefit, but oh, the
Speaker 4: third one is the obvious one. You get to build
Speaker 4: an app using client side technology. And really kind of
Speaker 4: what pushed me down this road is I was building
Speaker 4: more like in my applications that I built and I build,
Speaker 4: I always use layravel, which is very similar to rails.
Speaker 4: So for this audience just kind of think of them
Speaker 4: more or less as the same thing I was. You know,
Speaker 4: much of my apps were starting to contain more and
Speaker 4: more like rich UI and more client side functionality, more
Speaker 4: JavaScript requirements to basically make the UI's work a certain
Speaker 4: way that just kind of wasn't possible using classic server
Speaker 4: side rendering. And what I was basically doing is I
Speaker 4: was in my page responses, I was returning server side renderview,
Speaker 4: which would then have view components mixed into the page.
Speaker 4: So what would happen is the response would come back
Speaker 4: from the server, then view would kick in the gear,
Speaker 4: and any of the view components on the page there'd
Speaker 4: be like a little flicker and then they would show
Speaker 4: up right, and then you'd have those individual components would
Speaker 4: be reactive and whatnot right. And so by going that
Speaker 4: kind of comes with a whole bunch of interesting problems.
Speaker 4: I mentioned the flicker and just kind of having to
Speaker 4: manage each one of those separate components.
Speaker 3: So by going this way with.
Speaker 4: A NURSE, you're really like fully committing to client side
Speaker 4: render views, So you give up server side rendered views.
Speaker 4: That is a trade off, but that means is anytime
Speaker 4: you're working with any of the templates within your application.
Speaker 4: You have the power of JavaScript, you have the power
Speaker 4: of view or React, and you can do whatever you
Speaker 4: need to do.
Speaker 3: And it's just a really really nice way of working it.
Speaker 4: Yeah, so that's kind of a longer description. I would
Speaker 4: say that, like, I definitely built it for people who
Speaker 4: have traditionally worked with server side rendered applications like frameworks
Speaker 4: like again layer Bell, Ruby, Django, that kind of stuff.
Speaker 4: People who are familiar with creating controllers and getting data
Speaker 4: from the database and then passing that data to a view.
Speaker 4: The whole paradigm is very, very similar and much different
Speaker 4: than the classic, the more standard SPA approach where you
Speaker 4: have some separate API, some separate app that provides like
Speaker 4: ar rest API or graphic you LAPI.
Speaker 3: So it's definitely targeted.
Speaker 4: At that audience, and kind of, as I've said to
Speaker 4: people before, I kind of joke that Inertia is like
Speaker 4: the gateway drug to creating single page applications because if
Speaker 4: you're coming from a monol with background in er should
Speaker 4: just makes it so easy to get up and running
Speaker 4: with creating like what essentially feels exactly like a client
Speaker 4: side single page app of kind of using the technology
Speaker 4: that you know and love already.
Speaker 1: Yeah, I actually find it super interesting. I mean I've
Speaker 1: been for at least the past day or so kind
Speaker 1: of checking out some of the stuff on the side
Speaker 1: and things like this, and there's a lot of interest.
Speaker 1: So it kind of sounds just to make sure that
Speaker 1: I understand this the way that I think that I
Speaker 1: understand this, You're more or less going to, obviously, being
Speaker 1: familiar with rails here, You're going to create like this
Speaker 1: kind of high level sort of meta layout as you
Speaker 1: will or whatever. And then instead of creating a whole
Speaker 1: bunch of views for all of my pages, I'm just
Speaker 1: returning this inertia thing which has a props attribute or whatever,
Speaker 1: and then I'm just basically returning data is Jason, so
Speaker 1: kind of a bit like an inline API kind of
Speaker 1: thing almost like I'm just kind of rendering Jason almost there,
Speaker 1: And that's more or less how my page is going
Speaker 1: to run, and that's how my back end's going to run.
Speaker 1: And then I basically just have a single page.
Speaker 2: App on the page.
Speaker 1: That's it, and all these props get passed down and
Speaker 1: I just do with it what I want to in
Speaker 1: that single page.
Speaker 2: Of Yes, so a couple interface as you will.
Speaker 4: Yes, I like, yeah, So a couple of things to
Speaker 4: be aware of. Like, I like to compare inertia in
Speaker 4: a lot of ways to almost React router or view router,
Speaker 4: because in a way, all Inertia is is a specialized
Speaker 4: router like client side router that lives between your server
Speaker 4: and your controllers, which is returning data as Jason and
Speaker 4: your client.
Speaker 3: Side page components. So it's the piece that connects the two.
Speaker 4: But unlike with a classic app, you know, with view router,
Speaker 4: React router, whatever, you don't have any client side state
Speaker 4: management at all, So you're not using any client side
Speaker 4: like view x or whatever the React equivalents are. You're
Speaker 4: not using any of that stuff because all your data
Speaker 4: and all your state is essentially at the server, So
Speaker 4: it's not like you're making requests to the API client side,
Speaker 4: saving that in your client side's vieux library or database
Speaker 4: or whatever you want to call it, and then rendering
Speaker 4: components based on that. Basically, every single time you visit
Speaker 4: a page, the data's coming straight from your controller and
Speaker 4: go into your your client side page component.
Speaker 5: All right, I got a dumb question. You're going to
Speaker 5: have a few votes from me. So I wanted to
Speaker 5: kind of have a go at this. And I've been
Speaker 5: building this view app. And the way I populate my
Speaker 5: VU is it a view or VU view? It's the accent,
Speaker 5: isn't it. I can't I can't even tell. I think
Speaker 5: I'm trying to make it English. The way I populate
Speaker 5: my component is I go off with my HERB, my
Speaker 5: ERB template downloads, and then I do a get to
Speaker 5: get the initial data from the page, and then it
Speaker 5: drops in when to get returns. You've got your view
Speaker 5: building there. Yeah. Now in the examples on the inertia
Speaker 5: JS site, then it uses Laravelle. And we could take
Speaker 5: a nice divergence here because I'm starting to get Laravelle
Speaker 5: envy some of the tooling, some of the tooling that
Speaker 5: you show off on the inertia jas website. I don't.
Speaker 5: I didn't think the Ruby or rails community have. I'm
Speaker 5: sure John no more. But there's a there's a plug
Speaker 5: in where you can see the database queries being done
Speaker 5: on that page like the sequel, and I saw that.
Speaker 5: Oh would have been useful. I mean for years if
Speaker 5: I could just see what the what the page was hitting.
Speaker 5: You know, does that exist for rails.
Speaker 1: I'm pretty sure I've seen various things, and you can
Speaker 1: definitely see it in your logs.
Speaker 5: I know, I know I can see it in my logs,
Speaker 5: but you know to have it.
Speaker 1: There, you know, Hang on, I mean, maybe I could
Speaker 1: go find this. I don't know if it's a good
Speaker 1: use of my time, but maybe I could go find this.
Speaker 1: But I'm pretty sure that I've seen something somewhere that
Speaker 1: does something like that. However, regardless, you do know that
Speaker 1: you can switch those Laravel things to Rails to see
Speaker 1: the Rails examples on the Inertia site.
Speaker 5: No, I don't actually no, I didn't find a tab.
Speaker 5: Where's the tab?
Speaker 4: Every code snippet, every code snippet there is on the site?
Speaker 4: It defaults to Larvel, but you can switch it over
Speaker 4: to rails.
Speaker 5: Oh no, some basic fail going on here.
Speaker 2: No worry.
Speaker 1: So what I'm saying is you're very appreciative of how
Speaker 1: awesome Laaravel is on a review podcast.
Speaker 5: All right, listen, I'll be honest.
Speaker 3: This is not the first time this has happened.
Speaker 5: That's a nice workflow, you know. I like the tool.
Speaker 5: I can't find this finger I don't believe it.
Speaker 2: Exists, right, now I'll take a screenshot.
Speaker 4: Yeah, So the tool and layer bel in the PHP
Speaker 4: community it's called it's called the PHP debug bar, and
Speaker 4: there's a Layervell debug Bar version built on top of that.
Speaker 3: And it's fantastic because it's exactly what you can.
Speaker 4: You know, you can figure out all your database queries
Speaker 4: and your logs and whatnot. But what the layravel debug
Speaker 4: bar does is it just puts them right in the
Speaker 4: bottom of your screen, just like it's almost like a
Speaker 4: Chrome console right where it shows you exactly what database
Speaker 4: queris you're making, and what models you're loading from the database,
Speaker 4: and how much memory you're using. It's super super helpful,
Speaker 4: helpful you identify N plus one issues and slow queries
Speaker 4: and stuff.
Speaker 5: Where's my Rails debug bar? That's what I want to know,
Speaker 5: Moving swiftly on from my basic ability to use a website.
Speaker 5: So I was asking about the way you cook it
Speaker 5: in what there's for the benefit of people who can't
Speaker 5: use website like me. How does Rail send down that
Speaker 5: lump that cut because there's two things, aren't there. There's
Speaker 5: the kind of layout and there's the and the props.
Speaker 3: Yes, yeah, yeah, so I'll walk you through.
Speaker 4: That's I often failed to kind of explain this just
Speaker 4: because you know, you forget sometimes kind of where to
Speaker 4: start after you've talked about something for long enough. But
Speaker 4: so what essentially happens, and I'll explain it as best
Speaker 4: I can kind of using Rail's lingo, but I'm not
Speaker 4: super familiar with with it all, but like.
Speaker 3: Work with me.
Speaker 4: So basically, a request is going to come in, so
Speaker 4: through the very first time that someone hits your inertia application,
Speaker 4: your inertia rails application. What's going to happen is it's
Speaker 4: going to notice that it's just it's a standard full
Speaker 4: page visit, right, And what it's going to do is
Speaker 4: it's going to hit rails and it's going to see
Speaker 4: that it's not an inertial request. So it's not going
Speaker 4: to return some JSON. It's just going to go through
Speaker 4: the normal flow. And what it's going to do is
Speaker 4: it's going to return your base ERB template, so your
Speaker 4: layout file, right, and that layout file, well, it's just
Speaker 4: like a standard layout file that has your head which
Speaker 4: is going to have your script tags and it's gonna
Speaker 4: have your style tags kind of just your standard layout.
Speaker 4: The difference is what it's not going to do is
Speaker 4: it's not going to keep in mind that someone may
Speaker 4: land on your app on any different page. It doesn't
Speaker 4: have to be the homepage, of course, of the index page.
Speaker 4: It could be any page in your application, right, So
Speaker 4: it's going to see that request coming in, so it's
Speaker 4: going to return or it's going to server side render
Speaker 4: that layout. Except the only difference is within the body
Speaker 4: of that server side rendered HTML file, it's not going
Speaker 4: to have any page content, So the page content will
Speaker 4: not exist. So you landed on, say the user's page
Speaker 4: within your application, it's not going to have a bunch
Speaker 4: of HTML server side HTML generated and rendered. What it's
Speaker 4: going to do instead is there is a base DIV
Speaker 4: that it's that you need to put in your base layout,
Speaker 4: and that's the DIV that your client side application is
Speaker 4: going to mount to. So what happens is that based div,
Speaker 4: your client side app, view, React whatever mounts to that.
Speaker 4: But what happens is server side it passes this page
Speaker 4: object so Adjason encoded page object as one of the
Speaker 4: attributes within that DIV. So I think it's called data
Speaker 4: dash page is the page attribute. I should probably double
Speaker 4: check and know that offhand, but I'm pretty certain, Yeah,
Speaker 4: it's a data dash page. That's the attribute on the div.
Speaker 4: So imagine ATIV has an idea of app, which is
Speaker 4: what your Viewer React apps can amount into, and then
Speaker 4: it has an attribute called data dash page and the
Speaker 4: contents of that data dash page attribute is just a string,
Speaker 4: but it's actually a Jason encoded string, and what it's
Speaker 4: including is all the necessary information that INERTI needs in
Speaker 4: order to boot up that particular client side page component.
Speaker 3: So it's going to include two main things that the
Speaker 3: most important things to know are. One the component name,
Speaker 3: So the component name is going to be the viewer
Speaker 3: React component page component name, so in this case it
Speaker 3: might be the user page, which is going to have
Speaker 3: a corresponding user page dot view file or user page
Speaker 3: dot react file. And then the second piece of information
Speaker 3: that's going to be in that Jason payload is the props,
Speaker 3: which is the data. I call them props because they're
Speaker 3: considered when you're working with viewer React. Props are the
Speaker 3: properties there, the attributes the data that gets passed to
Speaker 3: that component. So it's essentially the data.
Speaker 4: So if you imagine now if we hit the Rails app,
Speaker 4: it's the user's page which gets which causes the routing
Speaker 4: to go to the user's controller, the index method of
Speaker 4: the user's controller. Your index method is going to go off,
Speaker 4: and it's gonna use active record to get some data
Speaker 4: from the database for the users that you want to
Speaker 4: display on that page.
Speaker 3: And then in a classic.
Speaker 4: Rails app and jump in if I get any of
Speaker 4: the terms wrong here, gents, because I'm you know, I'm
Speaker 4: gonna use more kind of lingo that I know. But
Speaker 4: what it's going to do is normally you would then
Speaker 4: return an ERB template that you pass the user index
Speaker 4: view too, and pass the data which is the users
Speaker 4: you just looked up from the database, use an active record,
Speaker 4: and that's going to go off and generate your HTML.
Speaker 4: In this situation, you would instead return an inertia response.
Speaker 4: So it's but the clever thing about the inertia response
Speaker 4: is so it's basically the exact same thing. You basically
Speaker 4: return inertia. You pass it the name of the page component,
Speaker 4: and you pass it the data. So the controller itself
Speaker 4: doesn't know if it was a full page visit like
Speaker 4: a standard get visit, or if it was an actual
Speaker 4: inertia visit. Inertia takes care of that. All the controller
Speaker 4: has to do is to return the page component name,
Speaker 4: so the client side page component name and the data
Speaker 4: for that component. Then the Inertia behind the scenes, it
Speaker 4: inspects the request and says, okay, was this a full
Speaker 4: page visit? You know, so where we need to display
Speaker 4: the layout? Well, if that's the case, well then we're
Speaker 4: going to display the layout. We're going to render its
Speaker 4: server side, and we're going to inject that base div
Speaker 4: with the idea of app and with the data page
Speaker 4: attribute with all the data for it, and then we're
Speaker 4: just going to render that out. It's kind of just
Speaker 4: a standard htam olt page. Then Inertia will grab that
Speaker 4: data and boot up the client side application. However, on
Speaker 4: subsequent visits, when inertia, so if you go then and
Speaker 4: click to a different page, maybe you click on one
Speaker 4: of the users you want to view the user, when
Speaker 4: inertia does is it intersect that click that page visit
Speaker 4: and it then makes the XHR request to the server.
Speaker 3: It's going to hit in the exact same way.
Speaker 4: Now imagine it's going to hit your user's controller again,
Speaker 4: but this time it's going to hit the show method.
Speaker 3: So again, what would you.
Speaker 4: Do just an standard layer or standard layer belt or
Speaker 4: rails app is you go off, you'd get that user
Speaker 4: from the database, use an active record, right, and then
Speaker 4: you would normally just return a response to show the
Speaker 4: user show page with the user data. Except again with inertia,
Speaker 4: you wouldn't do that. You would do you'd return an
Speaker 4: inertial response that would then have the user show page component,
Speaker 4: client side page component, and the data which would be
Speaker 4: the user data maybe their ID and their first name,
Speaker 4: their email and their last name and whatever else. Right,
Speaker 4: So when that request comes through the XHR request, what
Speaker 4: inertia does is it passes through an ex inertia header
Speaker 4: which is set to true so that your rails app
Speaker 4: knows that this isn't a full pagreload. This is this
Speaker 4: is like an inertia request, So it's an XHR request,
Speaker 4: and what it does instead is it returns not the
Speaker 4: full body and the full layout and everything else.
Speaker 3: It just turns the Jason data that it requires.
Speaker 4: So that's the same Jason data that we put in
Speaker 4: the data page attribute if it was like the full
Speaker 4: you know, HTML layout render kind of on the first visit,
Speaker 4: except it just returns the Jason and nothing else and
Speaker 4: it returns out obviously is adjacent response, which that's gonna
Speaker 4: have your component name and all your props and then
Speaker 4: kind of getting back to what I explained earlier, and
Speaker 4: Nursa's gonna then take that. It's gonna dynamically swap out
Speaker 4: the client side page component with the new page component
Speaker 4: and dynamically swap out the data the props for that
Speaker 4: component and like service sorry for the for the user
Speaker 4: and the browser, it's.
Speaker 3: Gonna look like you went to a whole new page.
Speaker 4: But the reality is it's just done some really nice
Speaker 4: magical work in the background to just kind of flip
Speaker 4: it for you. And then, of course, like I said,
Speaker 4: Inertia is essentially in its simplest form, it is a
Speaker 4: client side routing library. So it's gonna update your URL
Speaker 4: in the browser, and it's gonna update the necessary page
Speaker 4: state so that you have like you know, proper history
Speaker 4: and stuff so you can navigate back and forth and
Speaker 4: stuff like that. So that's kind of like the trickiness
Speaker 4: that we do with the reality is from a development
Speaker 4: experience for people who are using rails or layervell who
Speaker 4: are kind of used to working with that, Hey, I
Speaker 4: got a controller, I got a controller method, I got
Speaker 4: to get some data from the database and I got
Speaker 4: a return of you with some data. It literally feels
Speaker 4: the exact same way, except the difference is you're ending up.
Speaker 4: You're working with viewer React templates, you're not working with
Speaker 4: EARB templates.
Speaker 5: All right, I found it. Now It's super easy. And
Speaker 5: for the other kind of web challenge people who are listening,
Speaker 5: there is a gem. There is. This is the this
Speaker 5: is the key component I was missing. There is an
Speaker 5: inertia under school rails gem that does it for you.
Speaker 3: Yes, yes, I should have mentioned that probably too. Yes,
Speaker 3: so you don't got to do any of this work.
Speaker 4: This, like I said, when inertia does all the magical
Speaker 4: work for you, it's actually and when I say magical,
Speaker 4: it's really not that.
Speaker 3: It's not magical at all. It's in its most basic form.
Speaker 3: It's imagine this.
Speaker 4: You have a page response, The inertia gem looks to see,
Speaker 4: Hey was the x HR Sorry was the ex inertia
Speaker 4: header set to true? Well yeah, if it is, then
Speaker 4: return Jason instead of HTML. It's like literally that basic,
Speaker 4: and there is you know, some other interesting features that
Speaker 4: kind of go along with it, such as automatic asset
Speaker 4: refreshing and partial reloads so it does get more complicated,
Speaker 4: but in its basic form, like I tell people that
Speaker 4: if you didn't have the gem, like so, we do
Speaker 4: have an official Inertia gem for Rails, and we also
Speaker 4: have an official layer bel package for this as well,
Speaker 4: so it kind of just makes it really really easy.
Speaker 4: But there's all kinds of people who are making adapters,
Speaker 4: client side adapters for other languages and frameworks, and it's
Speaker 4: in its most basic form, it's really does not take
Speaker 4: that much.
Speaker 3: We actually have a page that kind of explains.
Speaker 4: A spec I kind of call it a protocol because
Speaker 4: in a way, that's really what it is. And as
Speaker 4: long as you implement that protocol, which is a very
Speaker 4: simple protocol, you can do this in other language. I
Speaker 4: tell people I've literally seen this done. Somebody reached out
Speaker 4: and they had done this in cold Fusion. I didn't
Speaker 4: even know cold fusion was still a thing, but somebody
Speaker 4: has created an inertia cold Fusion adapter, and there's there.
Speaker 4: I know there's been one creative for Django and all
Speaker 4: kinds of other frameworks. Now, the challenge for me as
Speaker 4: a library maintainer is normally in the past, anytime I've
Speaker 4: created library I've always worked with the language that I'm
Speaker 4: familiar with. So I've worked with PHP and layer Vell
Speaker 4: and it's not been that or even JavaScript, and it's
Speaker 4: not been that hard making the you know, maintain the library.
Speaker 4: The challenge where the ertia is I'm finding myself becoming
Speaker 4: more proficient in other languages and frameworks because in order
Speaker 4: to maintain the Rails adapter, I got to now be
Speaker 4: more of a Ruby expert on anything about an expert
Speaker 4: I should even said that, but like I got to
Speaker 4: know the basics of those frameworks.
Speaker 3: But fortunately I've had some a lot.
Speaker 4: Of people kind of like jump in and help out
Speaker 4: on framework specific adapters. Really that my job at the
Speaker 4: end of the day is managing the client side adapters,
Speaker 4: because that's, honestly, that's really the hard part. The view
Speaker 4: the React and the Spelt adapters are the tricky kind
Speaker 4: of piece because they're all they kind of got little differences.
Speaker 4: The way they do dynamic components swapping, the way they
Speaker 4: do data handling, the way they do reactivity. All that
Speaker 4: stuff is it's a little bit different each one of
Speaker 4: those client side frameworks.
Speaker 3: So that's kind of like.
Speaker 4: Really the heart of my job. And even there I
Speaker 4: actually have somebody who's helped on the project. One guy
Speaker 4: who's managing the so I managed to view adapter, another
Speaker 4: guy manages the React adapter, and another guy manages be
Speaker 4: spelt adapter. So that's been It's really quite a collaborative
Speaker 4: project in that sense.
Speaker 2: All right.
Speaker 1: Now that we theoretically know how to make an app
Speaker 1: with inertia, why am I making an app with inertia?
Speaker 1: Like what where do you see inertia kind of fitting
Speaker 1: into the space? And what kinds of apps are we
Speaker 1: using it for?
Speaker 2: Things like that?
Speaker 4: Yeah, that's a really good question to ask, because I
Speaker 4: think it's important. I think sometimes what happens is people
Speaker 4: come out with new projects, and I think people like
Speaker 4: the idea of saying, well, this, this whatever, this new
Speaker 4: piece of technology is, this is now the one way
Speaker 4: to do all the things, and we just like we
Speaker 4: want to like double down and fully commit to that
Speaker 4: for everything. And if it doesn't do everything, well, then
Speaker 4: we don't like it. Yeah, we get disappointed if it
Speaker 4: isn't appropriate for all use cases.
Speaker 3: And I'm generally.
Speaker 4: Like slow to say use the right tool for the job,
Speaker 4: because I find quite often we're just most effective using
Speaker 4: the tool we know and that's tends to be what's
Speaker 4: worked out better for me. I know that, you know, yeah,
Speaker 4: I know that Electra might be better or no, it
Speaker 4: might be better for creating certain apps nowadays, but I'm
Speaker 4: just so stinking fast with layer Bell that I just
Speaker 4: I use that because it's a tool I know and love.
Speaker 4: But I do I will say that kind of in
Speaker 4: response to that question.
Speaker 3: I do think that.
Speaker 4: Inertia is super suited, super well suited for some situations
Speaker 4: and not others. So the one that it's not well
Speaker 4: suited for is in a situation where it actually does
Speaker 4: make sense to make a full on API. So if
Speaker 4: it makes sense for you to have a full rest
Speaker 4: API and a full graph QLAPI, then Inertia maybe not
Speaker 4: the right choice because with inertia, the whole like my
Speaker 4: goal with this is to avoid you having to create
Speaker 4: this whole separate project, this whole separate API, figuring out
Speaker 4: all the authentication figuring out with all the old off
Speaker 4: stuff and all that Hoopla and the separate hosting account
Speaker 4: and everything else.
Speaker 3: Like, my goal is that I just want to build
Speaker 3: an app.
Speaker 4: I want to get some data from the database to
Speaker 4: use an active record, and I want to spit that
Speaker 4: to I you and render it like that's what I
Speaker 4: want to do with inertia. It's a like the very fast,
Speaker 4: classic monolith way of building an application. But if you
Speaker 4: did have a use case that you really truly did
Speaker 4: need an API. So maybe you're building a web app
Speaker 4: that has an iOS app and an Android app, and
Speaker 4: maybe you have maybe you have a native desktop applications
Speaker 4: or whatever. If you have that use case, then inertia
Speaker 4: may not be the right choice because it might just
Speaker 4: make sense in that situation to actually just go off
Speaker 4: and build that HOLYPI. But in my experience, there's a
Speaker 4: ton of applications that get built and I would say,
Speaker 4: like especially like a lot of just like business level
Speaker 4: applications that never ever ever go past being a web app.
Speaker 3: That's what they always are.
Speaker 4: So yeah, there is there a chance that it could
Speaker 4: eventually need an API, sure, but so often you don't
Speaker 4: need that. And you know what you think about any
Speaker 4: application that's built with just Classic LAYERVELT and built with
Speaker 4: just Classic rails using Classic Rails service side rendering or
Speaker 4: layveel service side rendering, you've already made that decision. You've
Speaker 4: already said this is the web app. And if I
Speaker 4: ever need an API, well, then I going to go
Speaker 4: off and build this a great API for it. So
Speaker 4: that's really where inertia fits. If you were planning and
Speaker 4: building a server side rendered application, you've already given You've
Speaker 4: already said.
Speaker 3: No to the API.
Speaker 4: So my thing here is I really wanted Anertia to
Speaker 4: be for those developers, those who said, you know, I
Speaker 4: want to build a service side application. I was gonna
Speaker 4: build it with layer bel or I was gonna build
Speaker 4: with rails using the standard monolith approach. I've already decided
Speaker 4: I'm not going to build an API. Well, then inertia
Speaker 4: is a wonderful fit because then it allows you to
Speaker 4: build a rich client side application using viewer react will
Speaker 4: still completely working within the paradigm the monolith approach that
Speaker 4: you know, and you can be really really really fast
Speaker 4: with that approach. And in my experience as well, I
Speaker 4: have built applications that use Inertia.
Speaker 3: As kind of the web app tool.
Speaker 4: And even in those applications I've have like my own application,
Speaker 4: I do have an iOS and Android app that I'm
Speaker 4: building right now, but the iOS and Android app is
Speaker 4: so simple compared to the web app, because that's what
Speaker 4: makes sense for.
Speaker 3: My business that I didn't.
Speaker 4: Even then, I still went in my layer of bel
Speaker 4: app and I just built a really light rest API
Speaker 4: for my native iOS and Android apps. I still didn't
Speaker 4: need to fully double down and make my whole web app,
Speaker 4: you know, run on on this API. It's still made
Speaker 4: sense to build a web app using using Reactor, View
Speaker 4: and Inertia without an API. And then literally I have
Speaker 4: like five endpoints, five API en points for this core
Speaker 4: functionality that I'm making available natively to iOS and Android.
Speaker 4: So I hope that kind of explains it. So that's
Speaker 4: really I would say. The reality is there are probably
Speaker 4: a ton of situations. Basically, anytime you were planning on
Speaker 4: building just a classic rails application, that's a good use
Speaker 4: case for an inertia app if you have any sort
Speaker 4: of more interesting client side needs. And by that, and
Speaker 4: this is maybe the last distinction I should make, I
Speaker 4: wouldn't personally use Inertia for anything that needs to be
Speaker 4: public facing. So that's and the reason why is Inertia
Speaker 4: is still a client side rendered application, meaning it doesn't
Speaker 4: work great from an SEO perspective. Yes, Google is getting
Speaker 4: better at indexing View and React apps. The JavaScript apps
Speaker 4: it is, and it probably only will continue to get better.
Speaker 4: But I think if I was building an application, if
Speaker 4: I was building a blog, or if I was building
Speaker 4: a news side, or I was building anything that had
Speaker 4: a public face that where SEO Search engine optimization was
Speaker 4: a concern, I probably wouldn't use inertia because of that limitation. Really,
Speaker 4: I designed inertia for you know, admin control panels, applications,
Speaker 4: you know SaaS applications where you need to log.
Speaker 3: In all those kind of tools.
Speaker 4: And one great use cases I've done this as well
Speaker 4: is you could absolutely say, build a RAILS application that's
Speaker 4: completely server side rendered for your public facing pages. Maybe
Speaker 4: you're building a SaaS app. You have a bunch of
Speaker 4: documentation that you want to make sure it's SEO friendly.
Speaker 4: You have your pricing page, and you're about page, and
Speaker 4: all those feature pages. You could build all that stuff
Speaker 4: using RAILS with classic server side rendering, will still having
Speaker 4: the application in the background. For the actual SaaS application
Speaker 4: be an inertia application, but that's only available after you
Speaker 4: log in. And that's a really common combo where you
Speaker 4: use server side rendering on the front end and you
Speaker 4: use inertia and client side rendering on the back end.
Speaker 5: Can we talk about the flicker.
Speaker 4: Yes, yes, So the simple answer is there is no flicker,
Speaker 4: no flicker at all. That's why it's so wonderful. So
Speaker 4: there was a flicker. Building it the old way. So
Speaker 4: the old way I do this is anytime I needed
Speaker 4: some view of view component or React component in my application,
Speaker 4: I would be using classic server side rendering in layer vow,
Speaker 4: which would return my full document, which would have all
Speaker 4: the page content, but somewhere in the page. So imagine
Speaker 4: it's maybe like a create user page, and maybe I
Speaker 4: want to create the form to create the user.
Speaker 3: Maybe I wanted to.
Speaker 4: Build that in view because I like the reactivity of it.
Speaker 4: I like be able to handle errors and everything else,
Speaker 4: just kind of using that view approach. Right, So maybe
Speaker 4: i'd have the whole page load, except the form itself
Speaker 4: would just be a view component that.
Speaker 3: Would boot up after the page loaded. Right, And that's
Speaker 3: what I mean by a flicker.
Speaker 4: That little thing takes a second to boot up because
Speaker 4: view has to viewed boot up, and it's minor, like
Speaker 4: we're talking milliseconds, but our eyes can perceive it, and
Speaker 4: we especially notice it when that component takes no space
Speaker 4: at first. But then if then it renders and it
Speaker 4: takes a bunch of space and kind of like causes
Speaker 4: the page to become longer, and you know, things move around,
Speaker 4: and if you have a lot of view components, maybe
Speaker 4: you have a drop down component or modal or different
Speaker 4: things like this, that problem just becomes worse and worse.
Speaker 4: Where with inertia that totally totally goes away because you're
Speaker 4: getting exactly what you'd have with like a Classic view
Speaker 4: or Rails or sorry, a view or React app, where
Speaker 4: when you go to visit another page, it's going to
Speaker 4: just render that new view component and nothing's getting destroyed
Speaker 4: in the in between because you're not doing a full
Speaker 4: page reload.
Speaker 3: View and React are long living.
Speaker 4: So when I go to the next page, it's going
Speaker 4: to load that file in the background, it's going to
Speaker 4: load the data in the background via that exit tour request,
Speaker 4: and then when it's ready, it's going to swap it
Speaker 4: out and you can you know, there's load ways to
Speaker 4: have loading graphics and stuff in between that, but the
Speaker 4: point is nothing's being destroyed when you go from one
Speaker 4: page to the next that's causing any sort of flicker.
Speaker 3: It's really really smooth.
Speaker 5: So you sound like you care a lot about kind
Speaker 5: of responsibility and user experience. Yes, very much, So let's
Speaker 5: talk milliseconds here. Let's talk some real numbers, because I
Speaker 5: can see we could take an enormous effort into kind
Speaker 5: of making this to help people improve the experience so
Speaker 5: they use this. Let's face it, the whole point is
Speaker 5: to make the site nicer for the people we write
Speaker 5: the software for. So what looks like a good load
Speaker 5: page for you?
Speaker 4: Yeah, So my goal generally on a regular web app
Speaker 4: is two hundred milliseconds or less. If I'm building a
Speaker 4: new application, That's really what I'm going for. Now, That's
Speaker 4: what I would consider like a typical server response. But
Speaker 4: as you know, there's more that goes into a website
Speaker 4: loading than just your server response. You also have your
Speaker 4: client side, the time that it needs to render there,
Speaker 4: the time that it needs to actually painted it on
Speaker 4: the page, the time that it needs to download, and
Speaker 4: JavaScript bundles and different things like that. So yeah, for me,
Speaker 4: this is honestly, this is one of the reasons why
Speaker 4: I like this approach so much, is because I've been
Speaker 4: very frustrated in the past building rest APIs or even
Speaker 4: graph Q on the graph QL is amazing, but you
Speaker 4: can run into performance issues really easy with graph u L.
Speaker 4: If you're not careful, you can run into n plus
Speaker 4: one issues just depending on the sort of graph of
Speaker 4: data you're returning. It can be tricky from a performance
Speaker 4: perspective in real applications to have every response from your
Speaker 4: API be really quick. And that's because these APIs, especially
Speaker 4: a rest API, is generic. It's generic because it needs
Speaker 4: to work for multiple different any application that wants to
Speaker 4: consume that that API. The wonderful thing about rails, and
Speaker 4: the wonderful thing about layer val is that every single
Speaker 4: control or method you are going to get the data
Speaker 4: exactly as you need it for that page. There's no
Speaker 4: generalized A there. It's like, okay, I'm displaying the user's page.
Speaker 4: I want to go to the database and I want
Speaker 4: to get these ten users if it's paginated for example,
Speaker 4: and I want to get their name, and I want
Speaker 4: to get their ID, and I want to get their
Speaker 4: email address, and maybe I want to egarload their company
Speaker 4: company along with it. So what inertia And this isn't
Speaker 4: really an inertia feature. This is really just this is
Speaker 4: really just a rail. This is like a monolith features,
Speaker 4: like when each end point is only responsible for getting
Speaker 4: the data that it needs for the page that it's
Speaker 4: going to display, you can highly highly optimize the data
Speaker 4: retrieval for those endpoints for exactly what's needed in that application.
Speaker 4: So that's one of the reasons why I really just
Speaker 4: like monolith apps in general, because I feel like that
Speaker 4: that approach.
Speaker 3: Just leads to fast applications.
Speaker 4: And I've talked you know, I mentioned earlier that I
Speaker 4: love databases and I love writing learning how to you know,
Speaker 4: kind of make the most of the database, create proper
Speaker 4: indexes and return the minimal amount of data, and that
Speaker 4: run the fastest career as possible. That's that's stuff that
Speaker 4: I'm super interested in and focus on. So roundabout way
Speaker 4: of answering your question, I like two hundred milliseconds or
Speaker 4: less from a response time from the server, which would
Speaker 4: be the inertia response. But then there's also this whole
Speaker 4: client side performance side of things, So let me talk
Speaker 4: briefly about that as well, because that is absolutely a
Speaker 4: tradeoff you get when you build a client side application.
Speaker 4: So one of the trade offs we've talked about already
Speaker 4: is you the sdo tradeoff if SEO is important to you,
Speaker 4: probably not going to make sense to build a fully
Speaker 4: client side rendered application unless you have some sort of
Speaker 4: service side rendering in place. And there's all kinds of
Speaker 4: fancy tools nowadays even to do that with JavaScript stuff.
Speaker 4: But you know what I'm saying, if SEO is important
Speaker 4: to you, you're not going to want to have client side
Speaker 4: rendering as your primary way. So the other trade off
Speaker 4: is that you now need to send all that to
Speaker 4: all your client side views. So all your page components,
Speaker 4: all your view components, are your your React components or
Speaker 4: your spell components, they all need to now be sent
Speaker 4: over the wire as JavaScript bundles to the client.
Speaker 2: Right.
Speaker 4: So Inertia what it does, and this is kind of
Speaker 4: like a really just I think a cool feature, is
Speaker 4: it will automatically like it makes you can use because
Speaker 4: it is just really a plain old regular view or
Speaker 4: React app. It supports code splitting. So if you use
Speaker 4: code splitting, what happens is you land on the very
Speaker 4: first page. So maybe you know, going back to our
Speaker 4: example from earlier, let's say you hit for the very
Speaker 4: first page, the user index page. What it's gonna happen
Speaker 4: in Inertia app is it's gonna go and get whatever,
Speaker 4: only the minimal amount of JavaScript that's required to display
Speaker 4: that page. So it's gonna get your typically kind of
Speaker 4: like your core bundle, which is gonna have like view
Speaker 4: or React and maybe some like core dependencies that are
Speaker 4: used kind of by the you know, all pages on
Speaker 4: the site. So it's gonna grab that core bundle, which
Speaker 4: is small because it doesn't have all the pages through
Speaker 4: your whole applications, just the core bundle, and then it's
Speaker 4: gonna load whatever whatever components are required for that page.
Speaker 4: So it could be the if it's the user index page,
Speaker 4: it's gonna go off and get the user index JavaScript
Speaker 4: bundle and download that, and then once it's downloaded, you
Speaker 4: never have to download it again because it's cash right
Speaker 4: and the browser knows to not go off and download
Speaker 4: it again.
Speaker 3: So what that.
Speaker 4: Practically means is you hit an inertia endpoint. It's gonna
Speaker 4: it's gonna only get the minimal amount of JavaScript that
Speaker 4: you need to actually display that page, and it's gonna
Speaker 4: get the minimal amount of data from the server because
Speaker 4: that's the way a rails app works, and the page
Speaker 4: can load like loads extremely quick, So I actually have
Speaker 4: a demo app if you want to try it out,
Speaker 4: if you call the demo apps called ping CRM, which
Speaker 4: is available on the Inertia Gas website, and you can actually,
Speaker 4: you know, click around this application and see exactly what
Speaker 4: the performance is like.
Speaker 3: And I think, like, so it's hosted on I host it.
Speaker 4: On Heroku, and I do that intentionally because anytime you
Speaker 4: host in Heroku, there's even a performance cost in saying
Speaker 4: having a one off linot or Digital Ocean, you know, server,
Speaker 4: because one for one, the database is the Postcrest database,
Speaker 4: which is not hosted on the same site as the
Speaker 4: actual web dinos, so there's always a performance cost that
Speaker 4: comes with that, which often you know, of course makes
Speaker 4: sense if you want to have multiple web dinos and whatnot.
Speaker 4: So I've hosted it that way because I feel like
Speaker 4: that's a good representation of a real life application. And
Speaker 4: most responses from the server come back in about one
Speaker 4: hundred milliseconds, and I think, you know, that's a pretty
Speaker 4: awesome experience.
Speaker 5: I've tried it. It is disgustingly quick.
Speaker 3: That's what I want to hear.
Speaker 5: For me in the UK comes back in well under
Speaker 5: one hundred well under one hundred to the extent that
Speaker 5: I'm quite suspicious that you're loading the next page the
Speaker 5: ground that terming me first or doing some kind of
Speaker 5: dirty trick like that isn't you know?
Speaker 3: It's funny that you mentioned one hundred percent. Absolutely it is. Yeah, absolutely,
Speaker 3: it is hitting the database.
Speaker 4: And that's interesting you mentioned that because because it is
Speaker 4: a JavaScript application, there is really some cool opportunities to
Speaker 4: even do stuff like that. So if you hover over
Speaker 4: a link for more than a certain period of time,
Speaker 4: go off and eager load that data. And even if
Speaker 4: you don't want to egerload the data, what we can
Speaker 4: do is eiger load the next JavaScript page component that
Speaker 4: that page, that link would require. So even if you
Speaker 4: are using code splitting, we can be smart about eger
Speaker 4: loading that next page component that you may want.
Speaker 3: To click to. So yeah, there's that's a kind of
Speaker 3: the neat thing.
Speaker 4: Because it is ultimately a real view or ultimately a
Speaker 4: real React app, you kind of get some of the
Speaker 4: cool things that you can do with those pieces of
Speaker 4: technology as well. I've been working on another feature that
Speaker 4: even allows you to do kind of like placeholder pages.
Speaker 4: So if you were to click on a if you're
Speaker 4: on the user index page and you were to click
Speaker 4: on the user like a show user page. I've got
Speaker 4: a working prototype where it could show kind of like
Speaker 4: a shell of the show user page while inertia is
Speaker 4: still in the background grabbing that data just again using
Speaker 4: a classic rails controller show endpoint.
Speaker 3: And then swap it out when it has the data ready.
Speaker 3: And these are like those.
Speaker 4: It's not necessarily something so the inertia, So the Pinxi
Speaker 4: r M demo doesn't do any of that, but it's
Speaker 4: I just think it's neat that if you had an
Speaker 4: application that you were that concerned about the user experience
Speaker 4: and you just really wanted to show something right off
Speaker 4: the bat when someone clicked a link to view a
Speaker 4: new page, that inertia allows you to will allow you.
Speaker 3: To do that. It technically doesn't allow you to do
Speaker 3: that yet, but that's something I'm working on.
Speaker 1: Yeah, I certainly like speed, but I certainly don't get
Speaker 1: as excited necessarily as other people do about speed. But
Speaker 1: I know that a lot of people do care about it.
Speaker 1: I think the thing that's most interesting here is so
Speaker 1: I know that it might be heresy, but I for
Speaker 1: a long time have more or less said that to me.
Speaker 1: The controller in NBC right, really is an API provider
Speaker 1: and you're just consuming that API with your view and
Speaker 1: that's sort of like the typical way that people use it.
Speaker 1: And so I think that inertia like just kind of
Speaker 1: leverages that. In my mind, you're just leveraging that and
Speaker 1: making it really easy for people who are just used
Speaker 1: to using views to just be like not have to
Speaker 1: think about it. Yeah, it's an awesome evolution in my opinion.
Speaker 4: Yeah, I love that comment that that comment that it's
Speaker 4: just essentially an API.
Speaker 3: It is.
Speaker 4: The difference is with a rails or layer ofl app,
Speaker 4: you've accepted that there is this type coupling between this
Speaker 4: back end controller and the front end view.
Speaker 3: That's just an accepsolutely, you know. And you know, some people.
Speaker 4: Say, well, that coupling's bad because now I can't use
Speaker 4: the sendpoint for other things, and I say, no, actually,
Speaker 4: that coupling is awesome because one, it makes it really fast.
Speaker 4: You can create these these applications really quickly, and you
Speaker 4: can optimize them from a performance perspective because you're only
Speaker 4: worrying about this one request. You're not worried about thirty
Speaker 4: possible different permutations.
Speaker 3: It's just one request. That you're concerned about.
Speaker 2: Absolutely.
Speaker 1: Really, the only benefit to thinking about it that way
Speaker 1: is when you're suddenly ready to break the rules, right,
Speaker 1: So yeah, awesome.
Speaker 2: Anything else that we should know about.
Speaker 1: Inertia that you you're just like, haven't talked about this,
Speaker 1: you guys?
Speaker 2: Yeah, thinking about this?
Speaker 3: Yeah?
Speaker 4: So yes, there's maybe a couple different things that I
Speaker 4: think inertia does really well and stuff that I'm even
Speaker 4: proving on is one is scroll management. So what happens
Speaker 4: by default when you browse from one page to the next,
Speaker 4: just using like standard normal, plain old website, and you
Speaker 4: scroll down and you visit the next page, and then
Speaker 4: you scroll down, you visit the next page, you know whatever,
Speaker 4: and then you hit back in the browser. The browser
Speaker 4: is smart enough to remember exactly where you were on
Speaker 4: each one of those pages, and that helps maintain context, right,
Speaker 4: which is a really nice thing.
Speaker 3: Inertia allows you to do that.
Speaker 4: Because that basically is for free out of the box,
Speaker 4: if you just do a standard page. But where it
Speaker 4: becomes tricky, and this is becoming more and more common,
Speaker 4: is people have like essentially what are considered like scroll
Speaker 4: areas within your UI. So one really common use case
Speaker 4: for this is imagine you have kind of like your
Speaker 4: standard layout. Left hand side is your navigation and the
Speaker 4: right hand side is your content, and maybe along the
Speaker 4: top you have a bar right when you scroll the content,
Speaker 4: you maybe want to scroll the content but not have
Speaker 4: your left hand nav change.
Speaker 3: Or even the other way around.
Speaker 4: Maybe when you scroll the content you want your left
Speaker 4: hand ab to follow with you or whatever. Right, So
Speaker 4: you do this using scroll areas, you know, overflow auto
Speaker 4: and stuff with CSS to kind of allow that sort
Speaker 4: of functionality. And yeah, so that's a very common thing
Speaker 4: with like modern applications especially I would say, like, yeah,
Speaker 4: more application style websites.
Speaker 3: So that kind of like goes out the window. What
Speaker 3: goes out the window when you're using scroll areas like
Speaker 3: that is scroll position management. So if you were to
Speaker 3: do that and you would go to visit the next
Speaker 3: page and you go back, the browser has no idea
Speaker 3: that you were scrolled in this container down three hundred pixels.
Speaker 4: It's like that, don't care, not my problem. All it
Speaker 4: cares about is restoring the body scroll position. So inertia,
Speaker 4: we're we have support for basically automatically automatic scroll restoration
Speaker 4: of containers as well, and you can and you don't
Speaker 4: have to. That doesn't happen to all containers. You can
Speaker 4: actually define on a per container basis, like inertia track
Speaker 4: the scroll position for this, and that's like a really
Speaker 4: really nice feature that you basically Yeah, so that's one thing.
Speaker 4: Another thing that in or she does really well is
Speaker 4: asset version ing. So this is a problem that a
Speaker 4: lot of people run into with modern client side rendered
Speaker 4: applications is imagine you have a user, right and they
Speaker 4: go to your application, they go to your website, and
Speaker 4: they click through a few different pages and while they click,
Speaker 4: you know, maybe they're on the user's page, and then
Speaker 4: when the user show page and right at that moment,
Speaker 4: you had to fix a bug or do something in
Speaker 4: that template and you redeployed it, so you would deployed
Speaker 4: those assets to the server. The problem is right now
Speaker 4: is with a typical client side rendered application is if
Speaker 4: you now go back to visit that user index page,
Speaker 4: because it's not doing a full page reload, there's no
Speaker 4: way for the browser to know that maybe that user
Speaker 4: index page template changed, so they're going to see the
Speaker 4: old page template, which might be fine, or it might
Speaker 4: not because you might be expecting data back from the
Speaker 4: server that's now out of sync with your template. You
Speaker 4: remember that type coupling that we're talking about between these
Speaker 4: two things, and would be no different if you're working
Speaker 4: with an API, if there's an expectation for the data
Speaker 4: to be there and it's not, and that old template
Speaker 4: could now generate an error the Appleic application craft simply
Speaker 4: because you deployed.
Speaker 3: An update to the application.
Speaker 4: And this is something that rails and layerbelt developers never
Speaker 4: have to worry about if you use some service side
Speaker 4: render views because when you go to the new page,
Speaker 4: it's doing a full page reload. You're getting a full page,
Speaker 4: all the new assets, everything else. So what inertia does
Speaker 4: is we have like and there's like there are ways
Speaker 4: to solve this with client side like Classic viewer, React apps,
Speaker 4: but it's complicated and they use people use service workers
Speaker 4: and I'm not going to get into details of how
Speaker 4: that gets solved, but it's kind of complicated, whereas with inertia.
Speaker 4: What's really cool about inertia is that the front end
Speaker 4: and the back end are coupled together. So that's like,
Speaker 4: you know, this coupling that we keep talking about, like,
Speaker 4: that's the real benefit because we can now let the
Speaker 4: server and the client side frameworks, and essentially what it
Speaker 4: is is it's a service side inertia adapter working with
Speaker 4: a client side inertia adaptor, and they're working together to
Speaker 4: make sure that things are working properly. So what happens
Speaker 4: is every single time you make it an inertia visit,
Speaker 4: we keep track of you know what, Let me back
Speaker 4: up before I even go there. It might be zero
Speaker 4: to explaining it this way. When you define your inertia
Speaker 4: set up in Rails, you have the option on every
Speaker 4: single page, like, you know, kind of like does it
Speaker 4: does Rails have this concept of like some sort of
Speaker 4: like base like application service provider where you do kind
Speaker 4: of like default work. Could it like happen in like
Speaker 4: a middleware or just like kind of like something that
Speaker 4: gets run on every single page request?
Speaker 3: Is that right?
Speaker 4: So imagine I forget exactly how the gens who put
Speaker 4: together the inertiative Rails adapter did this, but just imagine
Speaker 4: that somewhere in your inertia configuration in your Rails application,
Speaker 4: you basically say this is the version of my assets.
Speaker 4: Your assets being your JavaScript basically could also be yours. Yeah,
Speaker 4: so you you have some sort of version number that
Speaker 4: indicates the current version of your assets.
Speaker 3: Like the way I do it in layer.
Speaker 4: Bel is I literally just do I just get an
Speaker 4: empty five of the assets and and if it changes,
Speaker 4: it changes.
Speaker 3: So what you do is you.
Speaker 4: Say inertia version and you pass it the current version,
Speaker 4: and that happens on every single request. So what happens
Speaker 4: then is that version gets past to the client side.
Speaker 3: So that's one.
Speaker 4: And so I've talked about this page object that that
Speaker 4: gets passed around, which includes the component name and the props. Well,
Speaker 4: another another property in that that page object is the
Speaker 4: asset version. So the client side Inertia always knows what
Speaker 4: the current version of your assets are. So then when
Speaker 4: you now click from one page to the next, so
Speaker 4: you're on the user show page and you want to
Speaker 4: go to the user index page. Well, you you click
Speaker 4: the user index page, Inertia goes off and it makes
Speaker 4: the XHR request, the inertial inertial request to your server
Speaker 4: to get the index page and the data for the
Speaker 4: index page. Inertia automatically passes what it believes is a
Speaker 4: current version two rails, then rails the rails. Inertia adapter says, okay,
Speaker 4: I got this request coming in, it's saying that the
Speaker 4: current asset version is one, two, three, but we can
Speaker 4: see now that it's a new deploye has happened and
Speaker 4: the new asset version that is actually four or five six.
Speaker 4: And what Inertia does is it actually stops the request
Speaker 4: at that point and it then gives returns a four
Speaker 4: oh I believe it think it's a yeah it returns.
Speaker 4: So imagine this XHR request gets an immediately immediate four
Speaker 4: oh nine conflict response back from Rails, and then what
Speaker 4: happens is Inertia gets that four h nine conflict response
Speaker 4: back and it says, oh, assets are at a date.
Speaker 4: So what Inertia then does is that automatically does not
Speaker 4: an XHR request to that page. So going from the
Speaker 4: user show page to the user index page, it's gonna
Speaker 4: say the assets are at a date because the server
Speaker 4: just told me that, and it just cuts that XHR
Speaker 4: INNERSI request short and it now does an automatic full
Speaker 4: page visit to the user index page. And then because
Speaker 4: you're doing a full page visit, you have an off
Speaker 4: the opportunity to use cash bussing to reload your assets
Speaker 4: and you're right back in business.
Speaker 3: So for the end user.
Speaker 4: It does mean that they'll have to redownload those assets,
Speaker 4: of course, but that's what you want because otherwise you
Speaker 4: want to deploy them so they can continue browsing your
Speaker 4: Inertia app like a classic SPA until the assets are
Speaker 4: aut a date, and then they're gonna be forced without
Speaker 4: their they won't even notice really that it's happening other
Speaker 4: than that request will reload the whole page and it'll
Speaker 4: look like a full page visit and you're gonna be
Speaker 4: right back in business on the page. And we do
Speaker 4: some smart things about the way we make that request,
Speaker 4: that four nine response, and like we automatically reflash data,
Speaker 4: so if there was any if you had any flash
Speaker 4: data that was going to be used, it automatically reflashes that.
Speaker 4: So even though you're doing a full page reload, you're
Speaker 4: going to still get that flash data come available. So
Speaker 4: that's a really, really, really cool feature of Inertia that is,
Speaker 4: like I think it would be harder to do with
Speaker 4: a classic SBA, but because of the way that the
Speaker 4: clients side and service side adapters work together, it basically
Speaker 4: takes all the work out of asset refreshing and asset
Speaker 4: versioning like you Literally, all you have to do is
Speaker 4: tell service side, tell Inertia what the current version of
Speaker 4: the assets are, and you're done and it handles it.
Speaker 4: Which is also really nice from a development perspective because
Speaker 4: if you're developing, you're constantly changing your files, and inertia
Speaker 4: you don't have to like constantly hit refresh.
Speaker 3: You can just click a link and it'll just update
Speaker 3: automatically for you.
Speaker 1: No, I agree, that is super cool. I mean to
Speaker 1: b Frank, I've been used to Rails handling asset management
Speaker 1: to me for so long that it is frustrating every
Speaker 1: time that I have to deal with it because I
Speaker 1: just at this point in my development career, I just
Speaker 1: think that I shouldn't.
Speaker 2: Have to deal with it because I know exactly I
Speaker 2: literally cannot.
Speaker 1: I mean, shoot, we didn't even have that problem in
Speaker 1: Rails one because we weren't serving assets on the project
Speaker 1: that I was working on.
Speaker 2: So yeah, yeah, it was so long ago.
Speaker 4: Yeah, and there's there's some really the last thing, you so,
Speaker 4: the last thing I want to just mention about inertia
Speaker 4: that we kind of didn't talk about yet, and is
Speaker 4: the fact that inertia visits are not limited to get requests,
Speaker 4: so you can make inertia visits for post requests, put requests,
Speaker 4: patch requests, and delete as well. And this is really
Speaker 4: cool and it's kind of a complex thing to explain,
Speaker 4: maybe on a podcast, but what it does is it
Speaker 4: makes forms a lot more like classic Rails form submissions,
Speaker 4: except it's all done ya xhr, and it's like it's
Speaker 4: like the most wonderfully simple thing ever. So I'll explain
Speaker 4: kind of how it works real briefly in layer Bell
Speaker 4: and then you, guys, hopefully you can kind of hopefully it'll
Speaker 4: make sense in Rails as well. So what you do
Speaker 4: is if you have a form, say a view form
Speaker 4: with all the React of inputs right, and then you
Speaker 4: then a user presses submit to submit that data to
Speaker 4: the form, you know, down to the server. In that situation,
Speaker 4: you would still submit that using inertia. So what you
Speaker 4: would have is you'd have a submit interceptor where you
Speaker 4: prevent the default browser full page submission and then you
Speaker 4: would say, so imagine we were on the create user
Speaker 4: page right and you hit create user, hit the button,
Speaker 4: the form submits, We catch it, and then in your jabscript,
Speaker 4: in your view page component or in your React page
Speaker 4: component whatever. You would then say inertia dot post if
Speaker 4: we're creating a user yet post and you would say,
Speaker 4: we're going to post that to slash users and passing
Speaker 4: the data from that component. So it's just like literally
Speaker 4: a one liner. But you don't then do a bunch
Speaker 4: of work after that. You don't say, well, give me
Speaker 4: the response back and let me inspect the response to
Speaker 4: see if there is errors, and if there's errors, I'm
Speaker 4: going to go and manually update the view display those errors.
Speaker 4: And if there's no errors, well then we're going to
Speaker 4: redirect to somewhere else. You don't do any of that.
Speaker 4: All you say is inertia post to the user's page.
Speaker 4: Then what happens is there's two paths. There's a happy
Speaker 4: path the user created and there's the unhappy path. There
Speaker 4: was a validation error service sidevalidation error, So do happy path. First, user,
Speaker 4: you hit the user create page or the user store endpoint,
Speaker 4: so that controller endpoint to store the user validation all passes,
Speaker 4: it creates the user, and then server side in that
Speaker 4: exit that XHR inertial request, you then just do a
Speaker 4: classic redirect to wherever.
Speaker 3: You would have normally gone.
Speaker 4: You you would if it was just like a regular
Speaker 4: standard full page application. You would just do a redirect
Speaker 4: wherever you want that user to go after they created
Speaker 4: the user, so maybe you send them to the user
Speaker 4: show page at that point, right, So what you would do,
Speaker 4: you would do the same thing with inertia. You'd literally
Speaker 4: just say, however, in rails or in layer bel you
Speaker 4: return a redirect to that new user's page. So then
Speaker 4: that redirects going to happen in within that XHR request,
Speaker 4: and what's going to do is it's going to go
Speaker 4: now to that show user page, and that show user
Speaker 4: page is gonna load. Keep in mind, this is all
Speaker 4: happening within the initial inertia, the initial inertia post request. Okay,
Speaker 4: so that that redirects happening, you're now landing on the
Speaker 4: user show page and it's just given you a response,
Speaker 4: but it knows that it was an inertial request because
Speaker 4: that ex inertia header actually gets forwarded on when that
Speaker 4: redirect happens. And then on the user show page, it
Speaker 4: just returns because it knows it's an inertia request. It
Speaker 4: just returns the Jason payload back, which includes the page
Speaker 4: component name and the page data, which would be the
Speaker 4: show user page and the user data for that page,
Speaker 4: so that all then comes back to your create user page.
Speaker 4: You know that form and Inertia automatically now dynamically swaps
Speaker 4: out the create user page for the show user page
Speaker 4: and passes the component. So you don't need to do
Speaker 4: any work to like redirect the user. It just automatically
Speaker 4: happens because you're redirecting server side. So that's the happy path.
Speaker 4: The unhappy path is validation fails, and it essentially works
Speaker 4: the same way. The user submits the form via post
Speaker 4: inernship post that goes to the store controller endpoint, the
Speaker 4: validation fails, and the way at least this is how
Speaker 4: it works in layer about when the validation fails, it
Speaker 4: automatically redirect you back to the page that you're on. So,
Speaker 4: Lara Bell, if I go to create a user and
Speaker 4: maybe it's missing the first name, Larva automatically does a
Speaker 4: redirect back to the user page, but then includes some
Speaker 4: flash data saying well, there was an error and here's
Speaker 4: the error, which if you're using server side classic server
Speaker 4: side templates, you would then take that air and repopulate
Speaker 4: the page with your old values and display the errors. However,
Speaker 4: with inertia, you get an Inertia response back. So what
Speaker 4: it'll do is so redback, redirect back to the create
Speaker 4: user page, and it will pass along all the data
Speaker 4: that you would have for that page anyway. So the
Speaker 4: create user page maybe there is no data because you're
Speaker 4: creating a user, but it would say it's a create
Speaker 4: user page and then it would have some data, which
Speaker 4: is the errors that just happened. Those errors now get
Speaker 4: passed back to inertia, and Inertia sees that we're on
Speaker 4: the same page still, so we went to the create
Speaker 4: post page. It failed and redirected us back to the
Speaker 4: create user page. But now we have this bucket of
Speaker 4: errors and what but in those errors have been provided
Speaker 4: from Inertia as props, so the page component doesn't change,
Speaker 4: so there's no swapping of the page component. So it's
Speaker 4: you're gonna still be on the create user page, but
Speaker 4: what it now has is the errors, and all you
Speaker 4: do and those errors come through is props, so they
Speaker 4: will you don't have to do any work to update
Speaker 4: as long as you're taking as long as your page component,
Speaker 4: your client side page components designed that anytime your page
Speaker 4: create user page component is rendering any errors that come
Speaker 4: through as a prop, it's just gonna because it's all reactive,
Speaker 4: it's just going to automatically display those errors. So, like
Speaker 4: I said, this is a tough thing to explain over
Speaker 4: over a podcast, but the point is because it's all reactive,
Speaker 4: because that's the way view and reactings felt work. When
Speaker 4: that response comes back and has the errors, the props
Speaker 4: come in and they automatically update, so you literally it
Speaker 4: just ends up making for these really really simple forms
Speaker 4: because you don't have to do a whole bunch of
Speaker 4: wrangling to like figure out what the response was and
Speaker 4: update it.
Speaker 3: It just kind of all happens magically.
Speaker 4: And because you're not doing a full page load, you're
Speaker 4: not having to repopulate all that data that you put in,
Speaker 4: so that whatever data they put into the form, it's
Speaker 4: not like you're having to repopulate that because it's all
Speaker 4: they're still because that page component wasn't.
Speaker 3: Destroyed, it was, it's still persistent.
Speaker 2: There. Does that make sense, Oh, it totally makes sense.
Speaker 1: I think it's I think it's very close to what
Speaker 1: what we would have in Rails, right because.
Speaker 4: Rails doesn't magic with that stuff, right, Like it kind
Speaker 4: of like adds some stuff to your form, some JavaScript
Speaker 4: stuff already.
Speaker 1: Right, well, I mean if you have rails, not not
Speaker 1: really so the way that it would Okay, So if
Speaker 1: I just had vanilla Rails, right, I would submit my
Speaker 1: form right, happy path would redirect me to like a
Speaker 1: show page or an index page maybe the failed path,
Speaker 1: you know, I would come back and what would probably
Speaker 1: happen is validation. Things that weren't there before would now
Speaker 1: suddenly be there because Rails is going to render that template,
Speaker 1: and Rails is going to conditionally now render some new things.
Speaker 2: Kind of depends on maybe what gems you have.
Speaker 1: Installed other things like that, but that's that's usually going
Speaker 1: to be what it is.
Speaker 2: Yeah, but yeah, it makes it really close. It's really close. Yeah.
Speaker 3: Well that's good.
Speaker 2: Yeah, so awesome.
Speaker 1: I mean yeah, I think I think the basic gist
Speaker 1: here that I'm understanding is that inertia is going to
Speaker 1: make it pretty easy for me as a rail developer
Speaker 1: to say, you know what, I have this maybe legacy
Speaker 1: application or something like. I'm seeing a lot of use
Speaker 1: cases with already existing applications where I then want to
Speaker 1: sprinkle some view or some react or something on a
Speaker 1: page or two and have it be a little bit
Speaker 1: of a spa there for a little while. That's kind
Speaker 1: of what I'm seeing the major use case with rails
Speaker 1: B there. I mean, I guess you could design this
Speaker 1: with this in mine too. I don't see anything wrong
Speaker 1: with that.
Speaker 4: Yeah, that's what most people are doing. People are upgrading
Speaker 4: like existing apps to use inertia. But like most people
Speaker 4: are using it there. It's kind of like greenfield projects
Speaker 4: at this point. But that's also because it's a pretty
Speaker 4: new project.
Speaker 1: Yeah, excitement things like that also, always playing to this stuff. Yeah,
Speaker 1: any any other questions from you, Luke before we kind
Speaker 1: of roll into picks here?
Speaker 5: Do we want to tool amount gate, hubs, bumster shit?
Speaker 2: Sure? Why not?
Speaker 5: So?
Speaker 1: In the notes that you sent us, John Nathan, you
Speaker 1: said that you had started to get hub sponsorship campaign.
Speaker 1: You want to talk a little bit about that before
Speaker 1: we get wrong?
Speaker 3: Yeah, sure, that's cool.
Speaker 4: I was just trying to think of interesting things that
Speaker 4: might be fun talking about. That's kind of a of
Speaker 4: a newer thing, is so this. You know, I've been
Speaker 4: working I've been doing open source for a long long time,
Speaker 4: and it's always a challenge working an open source you know,
Speaker 4: justifying spending time, and if you're running a business and
Speaker 4: if you have a family and life's busy, it's difficult
Speaker 4: to justify committing large, large chunks of time to open
Speaker 4: source just strictly from a business or.
Speaker 3: You know, personal time management perspective.
Speaker 4: And so the what I did with Inertia when gethub
Speaker 4: sponsorships came out, I said, you know what, this is
Speaker 4: a project that I think has legs for the long term,
Speaker 4: and this is something I want to work on. But
Speaker 4: I've seen how much work tailwind CSS took and what
Speaker 4: it takes to make a really really successful project, open
Speaker 4: source project, and I thought, you know, I want to
Speaker 4: try to monetize it in some way to help me
Speaker 4: justify spending a bit of time on this thing. So
Speaker 4: I put out the GitHub sponsorships and it was really
Speaker 4: I totally didn't expect much of a response, but I
Speaker 4: got over fifty over fifty sponsors, which is, you know,
Speaker 4: not an enormous amount of money, but it's you know,
Speaker 4: upwards about you know, one thousand dollars a month.
Speaker 3: Which was double.
Speaker 4: So it was like two thousand dollars a month for
Speaker 4: getthub for a while, which was awesome.
Speaker 3: I think that's just I didn't know what to think
Speaker 3: of the GitHub sponsorship stuff at first.
Speaker 4: I'm like, are people actually gonna help contribute out of
Speaker 4: their own pockets toward open source? And obviously Gethub believe
Speaker 4: that that would happen, and and now you know, it's
Speaker 4: it's crazy what some people are able to do with
Speaker 4: their GitHub sponsors. And it's there's some people working on
Speaker 4: open source full time making making a lot more money
Speaker 4: than that on their GitHub sponsors, which I think, honestly
Speaker 4: is a really really cool thing for open source. It
Speaker 4: kind of just it's it's recognizing the amount of time
Speaker 4: and effort it takes for for people to work on
Speaker 4: open source and build quality software that you know, it's
Speaker 4: crazy at the amount of at least for me, I've
Speaker 4: I've always worked in the layer vel, PHP space, like
Speaker 4: it's it's all free software, right and this is what
Speaker 4: we're using to run our businesses and everything else. And
Speaker 4: to me, it only makes sense that some of that
Speaker 4: money goes back, if nothing else, to just help people
Speaker 4: spend business hours on open source and not have to
Speaker 4: feel like they're they're losing money or you know, running
Speaker 4: the issues with their boss because they feel bad working
Speaker 4: on a during work hours or whatever.
Speaker 1: You know, I think it's pretty cool too. I I
Speaker 1: do not think it's the end all be all, because
Speaker 1: I think there's a limit right to if programmers are
Speaker 1: the only people contributing to open source, like there's we're
Speaker 1: just not going to have enough money in open source.
Speaker 1: But I do think it's a definitely piece.
Speaker 2: Of the puzzle. I'm pretty so pleased with it myself.
Speaker 3: Yeah, yeah, I touly agree with that sentiment.
Speaker 2: Yeah, awesome. Well, I'm glad that you are able to
Speaker 2: get some people to support you. So let's I guess
Speaker 2: before we move into picks, if people.
Speaker 1: Want to like get a hold of you, follow you
Speaker 1: things like that, how do you recommend they do that?
Speaker 4: Yeah, So I'm active on Twitter. That's kind of like
Speaker 4: the go to place. Just my last name renik ari
Speaker 4: e I n I n K on Twitter, and I
Speaker 4: talk about you know, all kinds of inertia and database
Speaker 4: and layer bell stuff there. So you're interested follow me there,
Speaker 4: and then my website reanik so same same handle, Renick
Speaker 4: ari I n I n K dot ca A. I
Speaker 4: blog on there, and yeah, and then obviously inertia if
Speaker 4: you if you google inertia JS you'll find inertiajs dot
Speaker 4: com if you want to learn more about that project.
Speaker 2: Awesome.
Speaker 1: Well, we'll make sure that those links are in the
Speaker 1: show notes too. So sweet, let's go and move on
Speaker 1: into picks. Luke, do you have any picks for us
Speaker 1: this week?
Speaker 5: My word, do I have a pick for you? This week?
Speaker 5: We were recently unlucky enough to lose our server developer
Speaker 5: who has been building our Kubernetes stack for us, and
Speaker 5: this means that I've been spending the whole week doing Kubernetes,
Speaker 5: non stop, non stop Kubernetes this week. I have had
Speaker 5: used it before, back in twenty eighteen, but the Kubernetes
Speaker 5: is in a bit of a state of flux at
Speaker 5: the moment, so coming back to it, especially if you're
Speaker 5: kind of running on Google Kubernetes engine or something's been
Speaker 5: a lot of changes. So my pick for this week
Speaker 5: is a book on Kubernetes. It's by another Englishman, the
Speaker 5: English it Mathia coming in here, and it's called imaginatively enough,
Speaker 5: the Kubernettes Book. It was updated in February twenty twenty
Speaker 5: and it's been very helpful getting up the speed with
Speaker 5: the Kubernetes.
Speaker 2: Any other picks for us? Is that you're Is that
Speaker 2: it for us? That's it.
Speaker 5: I'm not going to pick Kubernettes itself. Make of that
Speaker 5: what you will.
Speaker 2: That's fair.
Speaker 1: I'd have to push chaplaine if if you did, I
Speaker 1: feel like anything to make it easier.
Speaker 5: Do you know what we got? We've got time for
Speaker 5: a quick rant. Here we go. Cubernettes. Right, you're learning
Speaker 5: a Cubernettes, you think. Right, I've got my book, I've
Speaker 5: got my my my Docker desktop. I'm going to go
Speaker 5: into settings and tick tick the box. I've got a
Speaker 5: requirement for Windows, so doing all the windows. And I
Speaker 5: say to I say to docer desktop, make me a
Speaker 5: Kubernettes cluster.
Speaker 2: Yes.
Speaker 5: Would you like to guess how much RAM this uses
Speaker 5: on my desktop machine? It's to take a wild guess
Speaker 5: how much this ticking this little box costs me?
Speaker 2: All of it?
Speaker 5: It's free gigabytes of RAM. And I haven't I haven't
Speaker 5: made any pods yet. I haven't. I haven't run my app.
Speaker 5: It's just sitting there. It's eating free. It's the first
Speaker 5: time this machine's cracked ten gig there's two sticks of
Speaker 5: raminist scene and this is the first time the second
Speaker 5: ones had to wake up.
Speaker 2: Yeah, that makes sense.
Speaker 1: The typical Kubernetes closter right cluster is you have a
Speaker 1: box that's just running Kubernetes right. All the other stuff
Speaker 1: comes later right after that box. I wonder if if
Speaker 1: your little ticked box right there is just spinning up
Speaker 1: the Kubernetes sort.
Speaker 5: Of yeah, ground stuff. Yeah, I found a box. You
Speaker 5: can see what it's doing. But I mean the plus side,
Speaker 5: keep it positive. The the the interface, the a p
Speaker 5: I is quite nice, not perfect, but there's some there's
Speaker 5: some things to like. The declaratives all good, but that's
Speaker 5: that's been around for a while. The the the language
Speaker 5: of it is nice and clean, so there's there's some
Speaker 5: good signs.
Speaker 4: I'm a little confused though, I thought all rails developers
Speaker 4: used Roku.
Speaker 3: So why are you even on Kubernetes.
Speaker 2: I know, I know that there's lots of people that
Speaker 2: don't doing around. I haven't.
Speaker 1: I've always been I've always been very devaps like personally
Speaker 1: and and things like that, and so like, I don't
Speaker 1: because I don't get a lot of value at it personally.
Speaker 1: But if you don't, if you're not really into that,
Speaker 1: I can totally see that just a.
Speaker 4: Little joke because I know, I know that that's kind
Speaker 4: of like a big part of Roku's background, right, A
Speaker 4: lot of I think.
Speaker 1: So, yeah, they came from our community. So yeah, it's
Speaker 1: least that's my understanding. Yeah, yeah, no, they're not bad.
Speaker 1: Just I'm not using though. Okay, I guess guess it's
Speaker 1: on me now. So the first thing that I'm picking
Speaker 1: today is we grew tomato plants, like we do every year,
Speaker 1: So yesterday, our tomato plants have been producing for like
Speaker 1: a bottom month, and the average amount that I'm bringing
Speaker 1: in is a bowl fowl. It's like about, you know,
Speaker 1: ten or twelve inches big and like six inches deep.
Speaker 1: Like we have like I don't know, like six or
Speaker 1: seven tomato plants and they go nuts. And it all
Speaker 1: is because we basically watched some YouTube videos on like
Speaker 1: how to like prune them and not like kill them
Speaker 1: and all these things, and so I'll paste them. I'll
Speaker 1: paste them in here. So if you're like totally, there's
Speaker 1: probably more stuff out there, probably somebody that knows how
Speaker 1: to take care of other kinds of plants, but I'm
Speaker 1: definitely like pushing the watch some YouTube videos. If you're
Speaker 1: if you're doing like some home gardening things, you know,
Speaker 1: especially if you're like growing stuff, because it's like COVID
Speaker 1: and everybody seems to be into.
Speaker 2: That this year.
Speaker 1: Maybe it's a little late for you because maybe you're
Speaker 1: growing seasons past, but definitely for if you keep doing
Speaker 1: it next year. So gardening videos awesome. The other thing
Speaker 1: that I was that I wanted to plug here so
Speaker 1: earlier in the session, Luke was like, Hey, I don't
Speaker 1: want to have to go to my logs too for
Speaker 1: queries and stuff.
Speaker 2: Well I did some looking during Well.
Speaker 5: I'll tell you why. I could reveal why now because
Speaker 5: but blasted apps and kubernettes and you can't get at
Speaker 5: the thing.
Speaker 1: Okay, maybe what I should give you is a link
Speaker 1: to tutorial on how to read logs and kubernetes, because
Speaker 1: that that I think is your actual problem. Then all right,
Speaker 1: But I actually I couldn't find a gem that did that.
Speaker 1: But I did find some pretty sweet gems that give
Speaker 1: you all sorts of extra query debugging tracing to the
Speaker 1: exact spot in your code explaining, So I'll just like
Speaker 1: those because they were cool anyway.
Speaker 2: So yep, those are my picks. Jonathan, did you have
Speaker 2: anything for us.
Speaker 4: Yeah, I didn't have anything at the beginning, but it
Speaker 4: kind of as you guys were talking, I've come up
Speaker 4: with three. One of them is, as I've mentioned earlier,
Speaker 4: project that I was involved with is called Tailwind CSS,
Speaker 4: and this is a kind of a unique approach to
Speaker 4: building and a unique approach to CSS and building applications
Speaker 4: that I would highly recommend to your audience to check out.
Speaker 4: It's become really really popular and it's honestly changed the
Speaker 4: way that I handled CSS. I pretty much don'trite CSS
Speaker 4: anymore because I'm using Tailwind, which is If that's confusing
Speaker 4: to you, then it's you should definitely check it out.
Speaker 4: And I will warn you if you've come from like
Speaker 4: a SAS or a less background or just even just
Speaker 4: plain old CSS and you look at this approach, you
Speaker 4: will probably be disgusted at first, but it is really
Speaker 4: really great. Give it a chance, and I pretty much
Speaker 4: guarantee you you'll be making webuis faster than you were before.
Speaker 4: And the maintenance is wonderful moving forward because it's just
Speaker 4: a lot easier to manage because it's all in HTML
Speaker 4: and not in CSS.
Speaker 3: So pick number one, tail in CSS. Pick number two is.
Speaker 4: I mentioned earlier that I put out a database course.
Speaker 4: Now I should mention that this course was primarily primarily
Speaker 4: designed for layveel developers.
Speaker 3: Well totally designed.
Speaker 4: For layravel developed developers, but there is a lot of
Speaker 4: crossover between larravels or m which is called Eloquent and
Speaker 4: active record in rails.
Speaker 3: So there's some interesting techniques.
Speaker 4: So if you are a layerbel developer listening to this,
Speaker 4: or just even a rails developer who wants to learn
Speaker 4: some techniques about databases and how to make your databases
Speaker 4: your database queries faster, check out my course eloquentdas course
Speaker 4: dot renik dot CA, which I'm assuming we'll end up
Speaker 4: in the notes. So yeah, So that's my second pick,
Speaker 4: and my third one is less software related. But I
Speaker 4: live on a farm and this week I so a
Speaker 4: little bit of a background. I live on a farm,
Speaker 4: so I wireless at Internet, which basically means that I
Speaker 4: have an antenna on my property that points to another
Speaker 4: antenna about two kilometers away from this Internet service provider.
Speaker 4: And this year, the tree line between us and the
Speaker 4: tower that we point to is like really growing in.
Speaker 4: The trees are really grown in, the leaves are really
Speaker 4: grown in and our internet's getting more and more unstable.
Speaker 4: So I've been pricing out some new hardware because it
Speaker 4: turns out that if I move my antenna about one
Speaker 4: hundred meters south of where my house is right now,
Speaker 4: which is out in basically the middle of my field
Speaker 4: of a small, little fifty acre property, so we have
Speaker 4: a bit of land, so I have the flexibility to.
Speaker 3: Move the tower.
Speaker 4: I get perfect line of vision to this tower. But
Speaker 4: the problem is I have to then get it from
Speaker 4: there to my house and my barn as well. So
Speaker 4: I've been playing around and been researching a bunch of
Speaker 4: ubiquity products, and if you are in the similar sort
Speaker 4: of position as me, I can't recommend this stuff enough.
Speaker 4: It's so cool. I've been playing around with a product
Speaker 4: called the Nanobeam, which are these like they're really like
Speaker 4: they're small little things or maybe like they're circular, maybe
Speaker 4: six or seven inches wide, and they're rated for fifteen
Speaker 4: I think fifteen to twenty kilometers, Like I only need
Speaker 4: it for like three hundred meters or something, and it
Speaker 4: just makes it really really easy to create these wireless
Speaker 4: connections between like long range wireless connections between different places
Speaker 4: of my property. So whatever, I'm just kind of nerding
Speaker 4: out on the Ubiquity products right now.
Speaker 2: Because I'll give you a plus.
Speaker 3: Yeah you've worked with them before.
Speaker 1: Yeah, So my a job that I had like over
Speaker 1: a decade ago. One of the things that we did
Speaker 1: is we broadcast auctions and a lot of the barns
Speaker 1: that these auctions would be done and they didn't have
Speaker 1: good Internet connections and so we were using wireless equipment
Speaker 1: all the time and we swore by this by Ubiquity.
Speaker 1: So just just saying that was ten years ago. But
Speaker 1: as far as I know, like you know, good stuff, it's.
Speaker 3: It's pretty cool stuff.
Speaker 4: I actually have one already set up on my property
Speaker 4: between two spots and we actually had a wire like
Speaker 4: a buried wire under the ground and it gave us
Speaker 4: all kinds of trouble. And then we put in a
Speaker 4: couple of nanobeams and it's just like it's it's almost
Speaker 4: like they are wired, because that's what it looks like
Speaker 4: from a network perspective, and they just they just work flawlessly.
Speaker 3: So that's my picks.
Speaker 1: Awesome alrighty, well, thanks everybody for joining us, and we'll
Speaker 1: see you again.
Speaker 2: Another that