0:00

When you think about businesses that are

0:02

selling through the roof like Ello or

0:04

Allbirds or Skims, sure, you think about

0:06

a great product, a cool brand and

0:09

brilliant marketing. But an often overlooked secret

0:11

is actually the business behind the business,

0:13

making selling simple. For millions of businesses,

0:16

that business is Shopify. Nobody does selling

0:18

better than Shopify. Home of the number

0:20

one checkout on the planet. And the

0:23

not-so secret secret. With shop pay that

0:25

boosts conversions up to 50%. Meaning way

0:27

less carts going abandoned. and way more

0:30

sales going. So if you're

0:32

into growing your business, your

0:35

commerce platform better be ready

0:37

to sell wherever your customers

0:40

are scrolling or strolling on

0:42

the web in your store

0:44

in their feed and everywhere

0:47

in between. Upgrade your business

0:49

and get the same check

0:52

out Allbirds uses. Sign up

0:54

for your $1 per month

0:57

trial period at Shopify.com/Try. Refinance

0:59

your car at Kemba Financial

1:01

Credit Union for quick access

1:04

to cash. Plus get up

1:06

to $500 next day cash

1:08

bag. Enjoy no payments for

1:11

90 days and take advantage

1:13

of cash equity from your

1:15

vehicle. Apply at

1:17

Kemba.org. Restrictions apply.

1:19

Offer ends March 31st, 2024

1:22

federal insured by NCOA. Equal Opportunity Lenter.

1:24

We have a couple panelists today, we

1:26

have Luke. Hi. Welcome. And we have

1:28

Jonathan Rining. Your thing like cut off

1:30

and gave me the dots right as

1:32

I was looking at it. I was

1:34

like, oh my gosh, Rining, welcome. Jonathan

1:37

is the author or creator, however you

1:39

want to say that, of inertia J.S.

1:41

And we just have here today to

1:43

yeah, for about it. Can you just

1:45

give us a little bit just to

1:47

start out about your background and how

1:49

why you might be famous? And then

1:51

we can go ahead and get into

1:53

inertia after that. Yeah, for sure. I

1:55

am a web developer and I've been

1:57

doing web development for almost two decades.

1:59

and I hang out mostly in the

2:02

Laravel community, so I contribute to that

2:04

framework and kind of like doing all

2:06

things, Ph. And yeah, my main projects

2:08

have been some libraries and some PhD

2:11

libraries. I was also involved early on

2:13

in the Tailwind CSS framework, if you're

2:15

familiar with that, you know, my buddy

2:17

Adam Webin built that. And more recently,

2:20

I have focused on inertia as well

2:22

as a bunch of database stuff. I'm

2:24

a big fan of databases and optimized

2:26

in databases and active record. and so

2:29

I put it a course recently about

2:31

that. So those are kind of the things

2:33

I mostly work on. I work for myself

2:35

outside of that. I run a small SAS

2:37

business, solo SAS, and that's fun. That's pretty

2:39

much me. Awesome. So since we were

2:41

planning to talk about inertia, let's

2:44

go ahead and dive in. What

2:46

exactly is inertia? Yeah. So it's

2:48

always fun when you come up

2:51

with a new project that's a

2:53

little bit different than other things.

2:55

It's certainly one of the most

2:58

challenging things. It's just explaining what

3:00

inertia is. And kind of the

3:02

simplest way to describe it is

3:05

it's a way to build single

3:07

page applications without needing an API.

3:09

rails or layervel and you can

3:11

use classic server side routing, classic

3:14

server side controllers. But the only

3:16

difference is with inertia, there is

3:18

no server side views. All the

3:21

views are done with view or

3:23

they're done in react or done

3:26

using Selt. And what happens is

3:28

you basically return some data from

3:30

our controller and where you normally

3:33

return a view and output that

3:35

data, you instead return a JavaScript

3:37

page component. component being rendered on

3:40

the page instead of like an ERB template

3:42

I guess is what they would be considered

3:44

in rails and obviously that's client side rendered

3:46

so it's not server side rendered but what

3:49

happens is every single time you navigate from

3:51

one page to the next inertia intercepts any

3:53

page clicks so that you don't do full

3:55

page reloads but instead when you click a

3:58

link inertia will intercept that link click And

4:00

instead of doing a full page reload,

4:02

it'll run off to the server, making

4:04

what's called an inertia request, and the

4:06

server will pick it up, say, okay,

4:08

this is the inertia request, and it'll

4:10

fire back the data needed for the

4:12

next page. And the data is the

4:14

JavaScript page component, be view or react

4:16

or whatever, and the data, be view

4:19

or react or whatever, and the data,

4:21

the props or the props for that

4:23

component. which is a feature of all

4:25

three of the popular client-side frameworks view

4:27

reactions felt. So it's dynamically swapped out

4:29

and it's given its new page props.

4:31

And the big, big, big benefit there

4:33

is one, when you're navigating from one,

4:35

so there's like three key benefits. One,

4:37

you're navigating page-to-page, you're now doing full

4:39

page reload, so there's a performance benefit

4:41

to that. Two, when it's doing that

4:43

because you're not doing a full page

4:46

reload, it's not having to reboot, view,

4:48

or react every single time. So it's

4:50

like really like silky smooth kind of

4:52

experience. It's just like a, it's like

4:54

you're working with an SPA, except you're

4:56

just navigating from one page to the

4:58

next and it's just swapping out those

5:00

components, those page components dynamically. And three,

5:02

and I knew this was gonna happen,

5:04

I don't remember my third benefit, but

5:06

oh, the third one's the obvious one,

5:08

you get to build an obvious one,

5:11

you get to build an app, you

5:13

get to build an app using. client-side

5:15

technology. And really, kind of what pushed

5:17

me down this road is I was

5:19

building more like in my applications that

5:21

I built and I build, I always

5:23

use Laravel, which is very similar to

5:25

rails. So for this audience, just kind

5:27

of think of them more or less

5:29

as the same thing. I was, you

5:31

know, much of my apps were starting

5:33

to contain more and more like rich,

5:35

u. You know, more client-side functional, more

5:38

JavaScript requirements to basically make the u.

5:40

doing is I was in my page

5:42

responses I was returning server side render

5:44

view which would then have view components

5:46

mixed into the page so what would

5:48

happen is the response would come back

5:50

from the server then view would kick

5:52

in the gear and any of the

5:54

view components on the page there'd be

5:56

like a little flicker and then they

5:58

would show up, right? And then you'd

6:00

have those individual components would be reactive

6:03

and whatnot, right? And so by going,

6:05

but that kind of comes with a

6:07

whole bunch of interesting problems. I mentioned

6:09

the Flickr and just kind of having

6:11

to manage each one of those separate

6:13

components. So by going to go in

6:15

and manage each one of those separate

6:17

components. So by going in this way

6:19

with inertia, you're really like fully committing

6:21

to client-side render views. That is a

6:23

that is a trade-off. But what that

6:25

is a trade-off. and you can do

6:27

whatever you need to do. And it's

6:30

just a really really nice way of

6:32

working it. Yeah, so that's kind of

6:34

a longer description. I would say that

6:36

like, I definitely built it. for people

6:38

who have traditionally worked with server side

6:40

rendered applications, like frameworks like again, Lairbell,

6:42

Ruby, Jango, that kind of stuff. People

6:44

who are familiar with creating controllers and

6:46

getting data from the database and then

6:48

passing that data to a view, the

6:50

whole paradigm is very very similar and

6:52

much different than the classic, the more

6:54

standard SPA approach where you have some

6:57

separate API, some separate app that provides

6:59

like a rest API or GraphUL API.

7:01

So it's definitely targeted at that audience.

7:03

and kind of as I was I've

7:05

said to people before I kind of

7:07

joke that inertia is like the gateway

7:09

drug to creating single-page applications because if

7:11

you're coming from a monolith background inertia

7:13

just makes it so easy to get

7:15

up and running with creating like what

7:17

essentially feels exactly like a client-side single-page

7:19

app but kind of using the technology

7:22

that you know and love already. Yeah

7:24

I actually find it super interesting I

7:26

mean I've been for at least a

7:28

past day or so kind of checking

7:30

out some of the stuff on the

7:32

site and things like this. And there's

7:34

a lot of it. So it kind

7:36

of sounds just to make sure that

7:38

I understand this the way that I

7:40

think that I understand this. You're more

7:42

or less going to obviously being familiar

7:44

with rails here. You're going to create

7:46

like this kind of high level sort

7:49

of meta layout as you will or

7:51

whatever. And then instead of creating a

7:53

whole bunch of views for all of

7:55

my pages. or whatever, and then I.

7:57

just basically returning. data is Jason. So

7:59

kind of a bit like an in

8:01

line API kind of thing almost like

8:03

I'm just kind of rendering Jason almost

8:05

there. And that's more or less how

8:07

my page is going to run. And

8:09

that's how my back end's going to

8:11

run. And then I basically just have

8:14

a single page app on the page.

8:16

That's it. And all these props get

8:18

passed down. And I just do with

8:20

it what I want to in that

8:22

single page. Yep. So a couple of

8:24

interface as you will, if you will.

8:26

Yes. I like. So a couple of

8:28

a couple of a couple of things.

8:30

React router or view router because

8:32

in a way all inertia is

8:34

is a specialized router like client

8:36

side router that lives between your

8:38

server and your controllers which is

8:41

returning data as Jason and your

8:43

client side page components so it's

8:45

the piece that connects it to

8:47

but unlike with a classic app

8:49

you know with view router react

8:51

router whatever you don't have any

8:53

client side state management at all

8:55

so you're not using any client

8:57

side like VUX or whatever the

8:59

react equivalents are, you're not using any

9:01

of that stuff because all your data

9:04

and all your state is essentially at

9:06

the server. So it's not like you're

9:08

making requests to the API client side,

9:11

saving that in your client side, VUX

9:13

library or database or whatever you want

9:15

to call it, and then rendering components

9:17

based on that. Basically every single time

9:20

you visit a page, the data is

9:22

coming straight from your controller and going

9:24

to your client side page component. question.

9:26

You're going to have a few of

9:29

those from me. So I wanted to

9:31

kind of have a get at this

9:33

and I've been building this view app

9:35

and the way I populate my view

9:38

of view view. It's the accent, isn't

9:40

it? I can't even tell. I think

9:42

I'm trying to make it English. The

9:44

way I populate my component is I

9:46

go off my ERB template downloads and

9:49

then I do a get to get

9:51

the initial data from the page and

9:53

then it drops in when the get

9:55

returns you've got your view building. Yeah.

9:58

Now in the examples on the inertia

10:00

JS site, then it uses Laravel and

10:02

we could take a nice divergence here

10:04

because I'm starting to get Laravel envy.

10:06

Some of the tooling, some of the

10:09

tooling that you show off on the

10:11

inertia JS website, I don't think the

10:13

Ruby or Rails community have, I'm sure

10:15

John, no more, but there's a there's

10:17

a plug-in where you can see the

10:20

database queries being done on that page

10:22

like the sequel. And I sort of,

10:24

oh. would have been useful I mean

10:26

for years if I could just see

10:28

what the what the page was hitting

10:31

you know does that exist for rails

10:33

I'm pretty sure I've seen various things

10:35

and you can definitely see it in

10:37

your logs I know I know I

10:40

can see it in my logs but

10:42

you know I can see it in

10:44

my logs but you know to have

10:46

it have it there you know to

10:48

have it there you know hang on

10:51

I mean maybe I could go find

10:53

this I don't know if it's a

10:55

good use in my time but I'm

10:57

pretty sure that I've seen the rails

10:59

examples on the inertia site. No, I

11:02

didn't actually, no, I didn't find the

11:04

tap. Where's the tab? So every code

11:06

snippet, every code snippet, there is on

11:08

the site. It defaults to Laravel, but

11:10

you can switch it over to rails.

11:13

Oh, no. There's some basic fail going

11:15

on here. No way. So what you're

11:17

saying is you're very appreciative of how

11:19

awesome Laravel is on a Ruby podcast.

11:21

All right. I'll be honest, this is

11:24

not the first time this has happened.

11:26

That's a nice workflow, you know, I

11:28

like the tool. Yeah, I can't find

11:30

this thing you're talking about. I don't

11:32

believe it exists. I'm looking at it

11:35

right now. I'll take a screenshot. Yeah,

11:37

so the tool in Laerville and the

11:39

PSP community, it's called the PSP debug

11:41

bar and there's a Laerville debug bar

11:43

version built on top of that and

11:46

it's fantastic because it's exactly. You can

11:48

figure out all your database query. in

11:50

your logs and whatnot, but what the

11:52

layer of the bug bar does is

11:55

it just puts them right in the

11:57

bottom of your screen, just like a,

11:59

it's almost like a, a chrome console,

12:01

right, where it shows you exactly what

12:03

data. queries you're making and what models

12:06

you're loading from the database and how

12:08

much memory you're using it's super super

12:10

helpful helps you to identify n plus

12:12

one issues and slow queries and stuff.

12:14

Where's my rails debug bar that's what

12:17

I want to know moving swiftly on

12:19

from my basic inability to use a

12:21

website so I was asking about the

12:23

the way you cook it in what

12:25

does for the benefit people who can't

12:28

use website like me how does rail

12:30

send down that lump because there's two

12:32

things aren't there's the kind of layout

12:34

and the props, yes? Yeah, yeah, so

12:36

I'll walk you through that's, I often

12:39

fail to kind of explain this just

12:41

because, you know, you forget sometimes kind

12:43

of where to start after you've talked

12:45

about something for long enough, but so

12:47

what essentially happens, and I'll explain it

12:50

as best I can kind of using.

12:52

rails lingo but I'm not super familiar

12:54

with with at all but like work

12:56

with me so basically request is going

12:58

to come in so through the very

13:01

first time that someone hits your inertia

13:03

application your inertia rails application what's going

13:05

to happen is it's going to notice

13:07

that it's going to notice that it's

13:10

just it's a standard full page visit

13:12

right and what it's going to do

13:14

is it's going to go through the

13:16

normal flow and what it's going to

13:18

do is it's going to return your

13:21

base ERB template so your layout file

13:23

Right in that Leo file, it's just

13:25

like a standard Leo file that has

13:27

your head, which is going to have

13:29

your script tags and it's going to

13:32

have your style tags. Refinance your car

13:34

at Kemba Financial Credit Union for quick

13:36

access to cash. Plus get up to

13:38

$500 next day cash. Enjoy no payments

13:40

for 90 cash. And take no payments

13:43

for 90 days and take advantage of

13:45

cash equity from your vehicle. Apply at

13:47

Kemba.org. Restrict. casino.com. Got it. Step two,

13:49

collect your welcome bonus. Come to Papa,

13:51

welcome bonus. Step three, play hundreds of

13:54

casino style games for free. That's a

13:56

lot of games, all for free. Step

13:58

four, unleash your excitement. free welcome bonus

14:00

now and live the Temple Life. Visit

14:02

chemba casino.com. No purchase necessary v.G.W. group

14:05

void for prohibited by law 21 plus

14:07

terms and conditions apply. Kind of just

14:09

your standard layout. The difference is what

14:11

it's not going to do is it's

14:13

not going to do is it's not

14:16

going to so and keep in mind

14:18

that someone may land on your app

14:20

on any different page. It doesn't have

14:22

to be the home page of course

14:25

the index page. It can be any

14:27

page in your application in your request.

14:29

of that server-side rendered HDML file, it's

14:31

not going to have any page content.

14:33

So the page content will not exist.

14:36

So you landed on, say, the user's

14:38

page within your application. It's not going

14:40

to have a bunch of HDML, server-side

14:42

HDML generated and rendered. What it's going

14:44

to do instead is there is a

14:47

base div that it's going to... that

14:49

you need to put in your base

14:51

layout. And that's the div that your

14:53

client side application is going to mount

14:55

to. So what happens is that base

14:58

div, your client side, app, view, react,

15:00

whatever, mounts to that. But what happens

15:02

is server side, it passes this page

15:04

object. So a Jason and coded page

15:06

object as one of the attributes within

15:09

that div. So I think it's called

15:11

data dash page is the page attribute.

15:13

I should probably double check and know

15:15

that off. I'm pretty certain, yeah, it's

15:17

a data dash page, that's the attribute

15:20

on the div. So imagine a div

15:22

has an idea of app, which is

15:24

what your viewer react apps can amount

15:26

into, and then it has an attribute

15:28

called data dash page, and the contents

15:31

of that data dash page attribute is

15:33

just a string, but it's actually a

15:35

Jason encoded string. And what it's including

15:37

is all the necessary information that inertia

15:40

needs in order to boot up that

15:42

particular client side page component. That's the

15:44

most important things to know are one

15:46

the component name so the component name

15:48

is going to be the view or

15:51

react component page component name So in

15:53

this case it might be the user

15:55

page which is going to have a

15:57

corresponding user page view file or user

15:59

page dot react file and then the

16:02

second piece of information that's going to

16:04

be in that Jason payload is the

16:06

props, which is the data. I call

16:08

them props because they're considered when you're

16:10

working with viewer react. Props are the

16:13

properties, the attributes, the data that gets

16:15

passed to that component. So it's essentially

16:17

the data. So it's essentially the data.

16:19

So it's essentially the data. So if

16:21

you imagine now, if we hit the

16:24

rails app, it's the users page which

16:26

causes the routing to go to the

16:28

users controller. for the users that you

16:30

want to display on that page. And

16:32

then in a classic rails app, and

16:35

jump in if I get any of

16:37

the terms wrong here, Gents, because I'm

16:39

going to use more kind of lingo

16:41

that I know, but what it's going

16:43

to do is normally you would then

16:45

return an ERB template that you pass

16:48

a user index view to. and pass

16:50

the data, which is the users you

16:52

just looked up from the database using

16:54

active record, and that's going to go

16:56

off and generate your HTML. In this

16:58

situation, you would instead return an inertia

17:01

response. But the clever thing about

17:03

the inertia response is, so it's,

17:05

but the clever thing about the

17:07

inertia response is, so it's basically

17:09

the exact same thing. You basically

17:11

return inertia, you pass it the

17:13

name of the page component, and

17:15

you pass it. Nursia takes care

17:17

of that. All the controller has

17:19

to do is return the page

17:21

component name, so the client side

17:23

page component name, and the data

17:25

for that component. Then the Nursia

17:27

behind the scenes, it inspects the

17:29

request and says, okay, was this a

17:31

full page? visit, you know, so where

17:33

we need to display the layout. Well,

17:35

if that's the case, well, then we're

17:37

going to display the layout, we're going

17:39

to render it server side, and we're

17:41

going to inject that base div with

17:43

the ID of app and with the

17:45

data page attribute with all the data

17:47

page attribute with all the data for

17:49

it, the data page attribute with all

17:51

the data for it, and then we're

17:53

just going to render it, so if

17:55

you go then and click to a

17:57

different user, you want to view the

17:59

user. What inertia does is it intercepts

18:01

that click, that page visit. And it

18:03

then makes the XHR request to the

18:05

server. It's going to hit in the

18:08

exact same way. Now imagine it's going

18:10

to hit your user's controller again, but

18:12

this time it's going to hit the

18:14

show method. So again, what would you

18:16

do just in a standard layer or

18:18

standard layer of rail or rails app

18:20

is you go off, you'd get that

18:22

user from the database, use an active

18:24

record, right? And then you would normally

18:26

just return a response to show the

18:28

user show page component. client-side page component

18:31

and the data which would be the

18:33

user data maybe their ID and their

18:35

first name their email and their last

18:37

name and whatever else right so when

18:39

that request comes through the XHR request.

18:41

What inertia does is it passes through

18:43

an X inertia header which is set

18:45

to true so that your rails app

18:47

knows that this isn't a full page

18:49

reload. This is like an inertia request.

18:51

So it's an XHR request. And what

18:54

it does instead is it returns not

18:56

the full body and the full layout

18:58

and everything else. It just returns the

19:00

Jason data that it will be put

19:02

in the data page attribute if it

19:04

was like the full. you know, HDML

19:06

layout render kind of on the first

19:08

visit, except it just returns the Jason

19:10

and nothing else. And it returns out,

19:12

obviously, is the Jason response, which that's

19:14

going to have your component name and

19:16

all your props. And then kind of

19:19

getting back to what I explained earlier,

19:21

and Nersha is going to then take

19:23

that, it's going to then take that,

19:25

it's going to the user in the

19:27

browser, it's going to look like you

19:29

went to a whole new. page, but

19:31

the reality is it's just done some

19:33

really nice magical work in the background

19:35

to just kind of flip it for

19:37

you. And then of course, like I

19:39

said, inertia is essentially in its simplest

19:42

form. It is a client-side routing library.

19:44

So it's going to update your URL

19:46

in the browser and it's going to

19:48

update the necessary page state so that

19:50

you have like, you know, proper history

19:52

and stuff so you can navigate back

19:54

and forth and stuff like that. That's

19:56

kind of like the trickiness that we

19:58

do, but the reality is from a

20:00

development experience for people who are using

20:02

rails or layer of all who are

20:05

kind of used to working with that,

20:07

hey, I got a controller, I got

20:09

a controller method, I got to get

20:11

some data from the database, and I

20:13

got to return a view with some

20:15

data, with some data, with some data,

20:17

with some data, with some data, with

20:19

some data, with some data, with some

20:21

data, with some data. Right. There is

20:23

a, this is the, this is the

20:25

key component I was missing. There is

20:27

an inertia under school rails gem that

20:30

does it for you. Yes, yes, I

20:32

should have mentioned that probably too. Yes,

20:34

so you don't gonna do any of

20:36

this work. This, like I said, when

20:38

inertia does all the magical work for

20:40

you, it's actually, and when I say

20:42

magical, it's really not, it's not magical

20:44

at all. It's, in its most basic

20:46

form, it's imagine this, you have, Yeah,

20:48

if it is, then return Jason instead

20:50

of HTML. It's like literally that basic.

20:53

And there is, you know, some other

20:55

interesting features that kind of go along

20:57

with it, such as automatic asset refreshing

20:59

and partial reload. So it does get

21:01

more complicated. But in its basic form,

21:03

like in partial reload, but in its

21:05

basic form, like I tell people that

21:07

if you didn't have the gem, like

21:09

so we do have an official inertia

21:11

gem for rails and we also have

21:13

an official layer of package for other.

21:16

languages and frameworks and it's in its

21:18

most basic form it really does not

21:20

take that much. We actually have a

21:22

page that kind of explains a spec.

21:24

I kind of call it a protocol

21:26

because in a way that's really what

21:28

it is. And as long as you

21:30

implement that protocol, which is a very

21:32

simple protocol, you can do this in

21:34

other language. I tell people, I've literally

21:36

seen this done. Somebody reached out and

21:38

they had done this in cold fusion.

21:41

I didn't even know cold fusion was

21:43

still a thing, but somebody has created

21:45

an inertia cold fusion adapter and there's,

21:47

I know there's been one creative for

21:49

Jango and all kinds of other frameworks

21:51

now. The challenge for me as a

21:53

library for me as a library maintainer

21:55

is a library maintainer is normally. Anytime

21:57

I've created libraries, I've always worked with

21:59

the language that I'm familiar with. I've

22:01

worked with PhD in Laravel, and it's

22:04

not been that, or even JavaScript, and

22:06

it's not been that hard making the,

22:08

you know. maintain the library. The challenge

22:10

with inertia is I'm finding myself becoming

22:12

more proficient in other languages and frameworks

22:14

because in order to maintain the rails

22:16

adapter, I got to now be more

22:18

of a Ruby expert. I'm anything but

22:20

an expert. I shouldn't even think about

22:22

an expert. I shouldn't even think about

22:24

an expert. I shouldn't even said that.

22:27

But like I got to know the

22:29

basics of those frameworks, I'm anything but

22:31

an expert. I shouldn't even said that.

22:33

But I shouldn't. kind of piece because

22:35

they're all they kind of got little

22:37

differences the way they do dynamic component

22:39

swapping the way they do data handling

22:41

the way they do reactivity all that

22:43

stuff is it's a little bit different

22:45

each one of those client side framework

22:47

so that's kind of like really the

22:49

heart of my job and even there

22:52

I actually have somebody who's helped on

22:54

the project one guy who's managing the

22:56

so I managed to view adapter another

22:58

guy manages the react adapter an app

23:00

with inertia? Why am I making an

23:02

app with inertia? Like where do you

23:04

see inertia kind of fitting into the

23:06

space and what kinds of apps are

23:08

we using it for? Things like that.

23:10

Yeah, that's a really good question to

23:12

ask because I think it's important. I

23:15

think it's important. I think sometimes what

23:17

happens is people come out with new

23:19

projects and I think people like the

23:21

idea of saying, well, this, whatever this

23:23

new piece of technology is, this is

23:25

now the one way to do all

23:27

the things. And if it doesn't do

23:29

everything, well, then we don't like it,

23:31

yeah, we get disappointed if it isn't

23:33

appropriate for all use cases. And I'm

23:35

generally like slow to say, use the

23:38

right tool for the job, because I

23:40

find quite often we're just most effective

23:42

using the tool we know, and that's

23:44

tends to be what's worked out better

23:46

for me. I know that, you know,

23:48

yeah, I know that elixir might be

23:50

better or note might be better for

23:52

creating certain apps nowadays, but I'm just.

23:54

so stinking fast with Larabelle that I

23:56

just I use that because it's a

23:58

tool I know and love but I

24:01

do I will say that kind of

24:03

in response to that question I do

24:05

think that inertia is super suited super

24:07

well suited for some situations and not

24:09

others so the one that it's not

24:11

well suited for is in the situation

24:13

where it actually does make sense to

24:15

make a full on API so if

24:17

it makes sense for you to have

24:19

a full rest API and a full

24:21

graph Quel API then inertia may be

24:23

not the right the right choice because

24:26

with inertiaa like my goal with this

24:28

is to avoid you having to create

24:30

this whole separate project, this whole separate API,

24:32

figuring out all the authentication, figuring out all

24:34

the old off stuff and all that hoopla

24:36

and the separate hosting account and everything else.

24:38

Like my goal is that I just want

24:40

to build an app, I want to build

24:43

an app, I want to build an app,

24:45

I want to get some data from the

24:47

database, use an active record, like my goal

24:49

is that I just want to build an

24:51

app, I want to get some data from

24:53

the database, use case, use case, that you

24:55

really, that you really truly, that you really

24:58

truly, app and maybe you have native desktop

25:00

applications or whatever if you have that use

25:02

case then inertia may not be the right

25:04

choice because it might just make sense in

25:06

that situation to actually just go off and

25:09

build that whole API. But in my experience

25:11

there's a ton of applications that get built

25:13

and I would say like especially like a

25:15

lot of just like business level applications that

25:17

never ever go past being a web app.

25:20

That's what they always are. So yeah, is

25:22

there a chance that it could eventually need

25:24

an API? Sure. But so often you don't

25:26

need that. And you know what? You

25:28

think about any application that's built with

25:31

just classic layer of L and built with

25:33

just classic rail and built with just classic

25:35

rails, using classic rails, using classic rails, using

25:37

classic rails, service side rendering, you've already said,

25:39

this is the web app. And if I

25:42

ever need an API, well, then I'm going

25:44

to go off and build a separate and

25:46

build a separate rendered application, already given, you've

25:48

already said no to the API. So my

25:51

thing here is I really wanted inertia to

25:53

be for those developers. Those who said, you

25:55

know, I want to build a server-side application,

25:57

I was going to build it with Larabel.

26:00

or I was going to build with

26:02

rails using the standard monolith approach. I've

26:04

already decided I'm not going to build

26:06

an API. Well, then inertia is a

26:08

wonderful fit because then it allows you

26:10

to build a rich client-side application using

26:12

viewer react will still completely working within

26:15

the paradigm, the monolith approach that you

26:17

know. And you can. It is Ryan

26:19

Secrest here. There was a recent social

26:21

media trend which consisted of flying on

26:23

a plane with no music, no movies,

26:25

no entertainment, no entertainment, no entertainment, no

26:28

entertainment, no entertainment, Chumpa Casino has over

26:30

a hundred online casino style games, all

26:32

absolutely free. It's the most fun you

26:34

can have online and on a plane.

26:36

So grab your free welcome bonus now

26:38

at Chumpa Casino.com. Sponsored by Chumpa Casino.

26:45

can be really really really fast with that

26:47

approach and in my experience as well I

26:49

have built applications that use inertia as kind

26:52

of the the web app tool and even

26:54

in those applications I've had like my own

26:56

application I do have an iOS and Android

26:58

app that I'm building right now but the

27:01

iOS and Android app is so simple compared

27:03

to the web app because that's what makes

27:05

sense for my business that I didn't Even

27:07

then, I still went in my layer of

27:09

the app and I just built a really

27:12

light rest API for my native iOS and

27:14

Android apps. I still didn't need to fully

27:16

double down and make my whole web app

27:18

run on this API. It still made sense

27:21

to build a web app using reactor view

27:23

and inertia without an API. and then literally

27:25

I have like five endpoints five API endpoints

27:27

for this core functionality that I'm making available

27:30

natively to to iOS and Android so I

27:32

hope that kind of explains it so that's

27:34

really I would say the reality is there

27:36

are probably a ton of situations basically any

27:38

time you were planning on building just a

27:41

classic rails application that's a good use case

27:43

for an inertia app if you have any

27:45

sort of more interesting client side needs and

27:47

by that and this is maybe the last

27:50

distinction I should make I wouldn't personally use

27:52

inertia for anything that needs to be public

27:54

facing. So that's, and the reason why is

27:56

inertia is still a client side rendered. application,

27:59

meaning it doesn't work great from an SEO

28:01

perspective. Yes, Google is getting better at indexing,

28:03

view and react apps, it is, and it

28:05

probably only will continue to get better. But

28:08

I think if I was building an application,

28:10

if I was building a blog, if I

28:12

was building a blog, if I was building

28:14

a blog, if I was building a news

28:16

site, or if I was building a news

28:19

site, or if I was building a news

28:21

site, you need to log in, all those

28:23

kind of tools. And one great use cases,

28:25

I've done this as well, is you could

28:28

absolutely say build a rails application that's completely

28:30

server side rendered for your public facing pages,

28:32

be it a, maybe you're building a SAS

28:34

app, you have a bunch of documentation that

28:37

you want to make sure it's SEO friendly,

28:39

you have your pricing page and your about

28:41

page and all those feature pages, you could

28:43

build all that stuff using rails with classic

28:45

server side rendering, while still having the application

28:48

in the application in the background for the.

28:50

So SAS application be an inertia application, but

28:52

that's only available after you log in. And

28:54

that's a really common combo where you use

28:57

server side rendering on the front end and

28:59

you use inertia and client side rendering on

29:01

the back end. Can we talk about the

29:03

flicker? Yes. So the simple answer is there

29:06

is no flicker. No flicker at all. That's

29:08

why it's so wonderful. So there was a

29:10

flicker building it the old way. So the

29:12

old way I do this. classic server-side rendering

29:14

in layer bell, which would return my full.

29:17

document, which would have all the page content,

29:19

but somewhere in the page. So imagine it's

29:21

maybe like a create user page, and maybe

29:23

I want to create the form to create

29:26

the user, maybe I want to build the

29:28

user, maybe I wanted to build that in

29:30

view, because I like the reactivity of it,

29:32

I like being able to handle errors, and

29:35

everything else, just kind of using that, I

29:37

like being able to handle errors, just kind

29:39

of using that, like being the handle errors,

29:41

just kind of using just kind of using

29:44

that, like being the handle errors, like being

29:46

able to handle errors, like being the handle

29:48

errors, and everything else, just, just, like being

29:50

the handle errors, just, like being the handle

29:52

errors, like being, like being the handle errors,

29:55

like being, like being the handle errors, like

29:57

being the handle errors, like being the handle

29:59

errors, like being, like being, like being, like

30:01

being, like being, like being the handle errors,

30:04

like being the handle errors, like being, like

30:06

being the handle errors, just, just notice it

30:08

when that component takes no space at first

30:10

but then then it renders and it takes

30:13

a bunch of space and kind of like

30:15

causes the page to become longer and you

30:17

know things move around and and you and

30:19

if you have a lot of view components

30:21

maybe you have a drop-down component or modal

30:24

or different things like this that problem just

30:26

becomes worse and worse where with inertia that

30:28

totally totally goes away because you're getting exactly

30:30

what you'd have with like a classic view

30:33

or rails or a view or react app

30:35

where when you go to visit another page

30:37

it's gonna just render that new view component

30:39

and nothing's getting destroyed in the in between

30:42

because you're not doing a full page reload,

30:44

view and react are long living. So when

30:46

I go to the next page, it's going

30:48

to load that file in the background. It's

30:50

going to load the data in the background

30:53

via that Exeter request and then when it's

30:55

ready, it's going to swap it out. And

30:57

you know, there's ways to have loading graphics

30:59

and stuff. from between that, but the point

31:02

is nothing's being destroyed when you go from

31:04

one page to the next that's causing any

31:06

sort of flicker. It's really, really smooth. So

31:08

you sound like you care a lot about

31:11

kind of responsibility and user experience, yes? Very

31:13

much so. Let's talk milliseconds here. Let's talk

31:15

some real numbers because I can say, we

31:17

could take an enormous effort into kind of

31:20

making this to help people improve the experience

31:22

of their users. for so what looks like

31:24

good load page for you? Yeah so my

31:26

goal generally on a regular web app is

31:28

200 milliseconds or less if I'm building a

31:31

new application that's really what I'm going for

31:33

now that's what I would consider like a

31:35

typical server response but as you know there's

31:37

more that goes into a website loading than

31:40

just your server response you also have your

31:42

client's side the time that it needs to

31:44

render there the time that it needs to

31:46

actually painted it and JavaScript bundles and different

31:49

things like that so Yeah, for me, this

31:51

is honestly, this is one of the reasons

31:53

why I like this approach so much is

31:55

because I've been very frustrated in the past

31:57

building rest APIs or even GraphQL. GraphQL is

32:00

amazing, but you can run into performance issues

32:02

really easy with GraphQL if you're not careful.

32:04

You can run into N plus one issues.

32:06

just depending on the sort of graph of

32:09

data you're returning, it can be tricky from

32:11

a performance perspective in real applications to have

32:13

every response from your API be really quick.

32:15

And that's because these APIs, especially arrest API,

32:18

is generic. It's generic because it needs to

32:20

work for multiple different, any application that wants

32:22

to consume that that API. The wonderful thing

32:24

about rails and the wonderful thing about layervel

32:26

is that every single control or method you

32:29

are going to get the data exactly as

32:31

you need it for that page. There's no

32:33

there's no generalized API there. It's like, okay,

32:35

I'm displaying the user's page. I want to

32:38

go to the database and I want to

32:40

get these 10 users, if it's paginated, for

32:42

example, and I want to get their name

32:44

and I want to get their ID and

32:47

I want to get their email address and

32:49

maybe I want to either load their company

32:51

along with it. So what inertia, and this

32:53

isn't really an inertia feature, this is really

32:56

an inertia feature, this is really an inertia

32:58

feature, this is really just a rails, this

33:00

is like a monolith feature, this is like

33:02

a monolith feature, it's like a monolith feature,

33:04

for exactly what's needed. monolith apps in general,

33:07

because I feel like that that approach just

33:09

leads to fast applications. And I've talked, you

33:11

know, I mentioned earlier that I'm, I love

33:13

databases and I love writing, learning how to,

33:16

you know, kind of make the most of

33:18

the database, create proper indexes, and return the

33:20

most of the database, create proper indexes, and

33:22

return the minimal amount of data, and run

33:25

the fastest queries, which would be the inertia

33:27

response. But then there's also this whole client

33:29

side. performance side of things. So let me

33:31

talk briefly about that as well, because that

33:33

is absolutely a tradeoff you get when you

33:36

build a client side application. So one of

33:38

the tradeoffs we've talked about already is you,

33:40

the STO tradeoff. If SEO is important to

33:42

you, probably not going to make sense to

33:45

build a fully client side rendered application, unless

33:47

you have some sort of server side rendering

33:49

in place. And there's all kinds of fancy

33:51

tools nowadays even to do that with JavaScript

33:54

stuff, but you know what I'm saying. If

33:56

SEO is. you're not going to want to

33:58

have client-side rendering as your primary way. So

34:00

the other tradeoff is that you now need

34:02

to send all that to all your client-side

34:05

views, so all your page components, all your

34:07

view components, all your view components, or your

34:09

react components, or your spell components, they all

34:11

need to now be sent over the wire

34:14

as JavaScript bundles to the client, right? So

34:16

inertia, what it does, and this is kind

34:18

of like a really just, I think a

34:20

cool feature, a cool feature is it will.

34:23

automatically like it makes you can use because

34:25

it is just really a plain old regular

34:27

view or react app it supports code splitting

34:29

so if you use code splitting what happens

34:31

is you land on the very first page

34:33

so maybe you know going back to our

34:35

example from earlier let's say you hit for

34:37

the very first page the user index page

34:40

what it's going to happen in inertia app

34:42

is it's going to go and get whatever

34:44

only the minimal amount of JavaScript that's required

34:46

to display that page so it's going to

34:48

get your typically a kind of like your

34:50

core bundle, which is going to have like

34:52

view or react, and maybe some like core

34:54

dependencies that are used kind of by, you

34:56

know, all pages on the site. So it's

34:58

going to grab that core bundle, which is

35:00

small, because it doesn't have all

35:02

the pages, through all, because it

35:04

doesn't have all the pages, through

35:06

your whole applications, just small, because

35:08

it doesn't have all the pages

35:10

through your whole applications, just, because

35:12

it doesn't have all the pages

35:14

through your whole applications, to not

35:16

go off. download it again. So

35:18

what that practically means is you

35:21

hit an inertia endpoint, it's gonna...

35:23

it's going to only get the

35:25

minimal amount of JavaScript that you

35:27

need to actually display that page,

35:29

and it's going to get the minimal

35:31

amount of data from the server, because that's

35:33

the way a rails app works, and the

35:35

page can load like loads extremely quick. So

35:37

I actually have a demo app if you

35:39

want to try it. If you call the

35:42

demo app, if you want to try it.

35:44

If you call the demo app, if you

35:46

want to try it. If you call it,

35:48

if you want to try it. If you

35:50

want to try it. cost insane having a

35:52

one-off linod or digital ocean dine, you know,

35:55

server because one, for one, the database is

35:57

a post-crest database which is not hosted on

35:59

the same. site as the actual web dino.

36:01

So there's always a performance cost that

36:03

comes with that, which often, you know,

36:05

of course, makes sense if you want

36:07

to have multiple web dinos and whatnot.

36:09

So I've posted it that way because

36:11

I feel like that's a good representation

36:13

of a real life application. And most

36:15

responses from the server come back in

36:17

about 100 milliseconds. And I think, you

36:19

know, that's a pretty awesome experience. I've

36:21

tried it. It is disgustingly quick. That's

36:23

what I want to hear. For me,

36:25

in the UK, it comes back in

36:27

well under 100, well under 100, to

36:29

the extent that I'm quite suspicious that

36:31

you're loading the next page in the

36:33

background. Is it actually that you mentioned

36:35

the base? 100% absolutely it is. Yep,

36:37

absolutely it is hitting the database. And

36:39

that's interesting. You mentioned that because it

36:41

is. a JavaScript application, there is really

36:43

some cool opportunities to even do stuff

36:45

like that. So if you hover over

36:47

a link for more than a certain

36:49

period of time, go off and eager

36:51

load that data. And even if you

36:53

don't want to eager load the data,

36:55

what we can do is either load

36:57

the data. What we can do is

36:59

either load the next JavaScript page component

37:01

that that that link would require. So

37:04

even if you are using code splitting,

37:06

we can be smart about eager loading

37:08

that next page component that you may

37:10

want to click to. So yeah, that's

37:12

a kind of the neat thing. React

37:14

app, you kind of get some of

37:16

the cool things that you can do

37:18

with those pieces of technology as well.

37:20

I've been working on another feature that

37:22

even allows you to do kind of

37:24

like placeholder pages. So if you were

37:26

to click on a, if you were

37:28

on the user index page and you

37:30

were to click on the user index

37:32

page and you were to click on

37:34

the user, like a show user, user

37:36

page, I've got a working prototype where

37:38

it could show kind of like a

37:40

shell of the show user page, while

37:42

inertia, and these are like. It's not

37:44

necessarily something, so the inertia, so the

37:46

Pink CRM demo doesn't do any of

37:48

that, but I just think it's neat

37:50

that if you had an application that

37:52

you were that concerned about the user

37:54

experience and you just really wanted to

37:56

show something right off the bat when

37:58

someone clicked a link to view a

38:00

new page, that inertia allows you to,

38:02

will allow you to do it. that

38:04

technically doesn't allow you to do that

38:06

yet, but that's something I'm working on.

38:08

Yeah, I certainly like speed, but I

38:10

certainly don't get as excited necessarily as

38:12

other people do about speed, but I

38:14

know that a lot of people do

38:16

care about it. I think the thing

38:18

that's most interesting here is, so I

38:20

know that it might be heresy, but

38:22

I for a long time have have

38:24

more or less said that to me,

38:26

the controller in NBC, right, really is

38:28

an API provider and you're just consuming

38:30

that API with your view. And that's

38:32

sort of like the typical way that

38:34

people use it. And so I think

38:36

that inertiaia like just kind of leverage

38:38

is that in my mind, you're just

38:40

leveraging that and making it really easy

38:42

for people who were just used to

38:44

using views to just be like not

38:46

have to think about it. Yeah, it's

38:48

an awesome evolution in my opinion. Yeah,

38:50

I love that comment. that comment that

38:52

it's just essentially an API it is

38:54

that the difference is with a rails

38:56

or layer of app you've accepted that

38:58

there is this type it is Ryan's

39:00

secrets here there was a recent social

39:02

media trend which consisted of flying on

39:04

a plane with no music no movies

39:06

no entertainment but a better trend would

39:08

be going to chumba casino.com it's like

39:10

having a mini social casino in your

39:12

pocket chumba casino has over a hundred

39:14

online casino-style Welcome bonus now at Chumba

39:16

Casino.com. Sponsored by Chumba Casino. coupling

39:22

between this back end controller and the front

39:25

end view. That's just an accepted, you know,

39:27

and you know, some people would say, well,

39:29

that coupling is bad because now I can't

39:31

use the send point for other things. And

39:34

I say, no, actually that coupling is awesome

39:36

because one, it makes it really fast. You

39:38

can create these these applications really quickly and

39:41

you can optimize them from a performance perspective

39:43

because you're only worrying about this one request.

39:45

30 possible different permutations. It's just one request

39:47

that you're concerned about. Absolutely. Really, the only

39:50

benefit to thinking about it that way is

39:52

when you're suddenly ready to break the rules,

39:54

right? So, yeah, awesome. Anything else that we

39:57

should know about inertia that you, you're just

39:59

like having to. about this, you guys should

40:01

be thinking about this. Yeah, so yes, there's

40:03

maybe a couple different things that I think

40:06

inertia does really well and stuff that I'm

40:08

even approving on is one is scroll management.

40:10

So what happens by default, when you browse

40:13

from one, by default, when you browse from

40:15

one page to the next, when you browse

40:17

from one page to the next, just using

40:19

like standard normal, plain old website, and you

40:22

scroll down and you visit the next page

40:24

and you visit the next. maintain context, right?

40:26

Which is a really nice thing. Inertia allows

40:29

you to do that because that basically is

40:31

for free out of the box if you

40:33

just do a standard page. But where it

40:35

becomes tricky, and this is becoming more and

40:38

more common, is people have like essentially what

40:40

are considered like scroll areas within your UI.

40:42

So one really common use case for this

40:45

is imagine you have kind of like your

40:47

standard layout, left hand side is your navigation,

40:49

and the right hand side is your content,

40:51

and maybe want to scroll the content but

40:54

not have your left-hand nav change or maybe

40:56

the other way around maybe when you scroll

40:58

the content and you want your left-hand nav

41:01

to follow with you or whatever right so

41:03

you do this using scroll areas you know

41:05

overflow auto and stuff with CSS to kind

41:07

of allow that sort of functionality and yeah

41:10

so that's a very common thing with like

41:12

modern applications especially I would say like yeah

41:14

more application style websites so that kind of

41:17

like goes out the window when you're using

41:19

scroll areas like that is scroll position management

41:21

So if you were to do that and

41:23

you would go to visit the next page

41:26

and you go back, the browser has no

41:28

idea that you were scrolled in this container

41:30

down 300 pixels. It's like... don't care, not

41:33

by problem. All it cares about is restoring

41:35

the body scroll position. So inertia, we have

41:37

support for basically automatically, automatic scroll restoration of

41:39

containers as well. And you can, and you

41:42

don't have to, that doesn't happen to all

41:44

containers, you can actually define on a per

41:46

container basis, like inertia track the scroll position

41:48

for this. And that's like a really, really

41:51

nice feature that you basically. Yeah, so that's

41:53

one. Another thing that inertia does really well

41:55

is asset versioning. So this is a problem

41:58

that a lot of people run into with

42:00

modern client-side rendered applications is imagine you have

42:02

a user right and they go to your

42:04

application they go to your website and they

42:07

click through a few different pages and while

42:09

they click, you know, maybe they're on the

42:11

user's page and then we end the user's

42:14

show page. And right at that moment, you

42:16

had to fix a bug or do something

42:18

in that template and you redeployed it. So

42:20

you were deployed those assets to the server.

42:23

The problem is, right now, is with a

42:25

typical client side rendered application, is you now

42:27

go back to visit that user index page

42:30

because it's not doing a full page reload.

42:32

There's no way for the browser to know

42:34

that maybe that user index page template changed.

42:36

So they're going to see the old page

42:39

template, which might be fine or it might

42:41

not, because you might be expecting data from

42:43

back from the server that's now out of

42:46

sync with your template. You remember expecting data

42:48

from the server that's now out of sync

42:50

with your template. You remember that type coupling

42:52

with your template. And it would be expecting

42:55

data from the server that's now out of

42:57

sync with your template. You remember the type

42:59

of the user index page template, the user

43:02

page template, never have to worry about if

43:04

you're using server-side render views because when you

43:06

go to the new page, just doing a

43:08

full page reload, you're getting a full page,

43:11

all the new assets, everything else. So what

43:13

inertia does is we have like, and there's

43:15

like, there are ways to solve this with

43:18

client's side, like, like, there are ways to

43:20

solve this with client's, like, classic, like, there

43:22

are ways to solve this with client's, like,

43:24

classic, like, like, there are ways to solve

43:27

this with client's, like, like, like, like, like,

43:29

like, like, like, like, there are ways to

43:31

solve this, like, like, like, like, like, there

43:34

are ways to solve, like, like, like, like,

43:36

like, like, like, like, like, there are, there

43:38

are, there are, there are ways to solve,

43:40

like, like, like, like, there are, like, like,

43:43

there are, like, there are, there are, there

43:45

are, there are, that's the real benefit because

43:47

we can now let the server and the

43:50

client side frameworks and essentially what it is

43:52

is it's a service side inertia adapter working

43:54

with the client side inertia adapter and they're

43:56

working together to make sure that things are

43:59

working properly so what happens is every single

44:01

time you make an inertia visit we keep

44:03

track of you know what let me back

44:06

up before I even go there might be

44:08

easier if I explain it this way when

44:10

you define your inertia setup in rails, you

44:12

have the option on every single page, like,

44:15

you know, kind of like, does, does rails

44:17

have this concept of like some sort of

44:19

like base, like application service provider where you

44:21

do kind of like default work, could it

44:24

like happen to like a middleware or just

44:26

like kind of like something that gets run

44:28

on every single page request, is that's, I'm

44:31

sure, middleware, right. So imagine, I forget exactly

44:33

how. the gents who put together the inertia

44:35

rails adapter did this but just imagine that

44:37

somewhere in your inertia configuration in your rails

44:40

application you basically say this is the version

44:42

of my assets. Your assets being your JavaScript

44:44

basically could also be your your CSS. So

44:47

yeah, so you you have some sort of

44:49

version number that indicates the current version of

44:51

your assets like the way I do it

44:53

in Laerville is I literally just do I

44:56

just get an MD5 of the assets and

44:58

and if it changes it changes it changes.

45:00

So what you do is you say inertia

45:03

version and you pass it the current version

45:05

and you pass it the current version and

45:07

you pass it the current version and that

45:09

happens on every single request. So I've talked

45:12

about this page object that gets passed around,

45:14

which includes the component name and the props.

45:16

Well, another property in that page object is

45:19

the asset version. So the client side, inertia,

45:21

always, so the client side, inertia, always knows

45:23

what the current version, always knows what the

45:25

current version of the current version of your

45:28

assets are. So then, when you now click

45:30

from one page to the next, you want

45:32

to go to the user index page and

45:35

the data for the index page, page, inertia

45:37

automatically passes what it believes is a current

45:39

version to rails. Then rails, the rails inertia

45:41

adapter says, okay, I got this request coming

45:44

in, it's saying that the current asset version

45:46

is 123, but we can see now that

45:48

it's a new deploy is happened in the

45:51

new asset version that is actually 456. And

45:53

what inertia does is it actually stops the

45:55

request at that point, and it then gives

45:57

returns a four, I believe it's, I think

46:00

it's, it returns, so imagine this XHR request

46:02

gets an immediate. 409 conflict response back from

46:04

rails and then what happens is inertia gets

46:07

that 409 conflict response back and it says

46:09

oh assets are out of date so when

46:11

inertia then does it automatically does not an

46:13

XHR request to that page. So going from

46:16

the user show page to the user index

46:18

page, it's going to say the assets are

46:20

out of date because the server just told

46:23

me that. And it just cuts that XHR

46:25

inertia request short. And it now does an

46:27

automatic full page visit to the user index

46:29

page. And then because you're doing a full

46:32

page visit. you have the opportunity to use

46:34

cash busting to reload your assets and you're

46:36

right back in business. So for the end

46:39

user, it does mean that they'll have to

46:41

redown all those assets, of course, but that's

46:43

what you want because otherwise you want to

46:45

deploy them. So they can continue browsing your

46:48

inertia, like they can continue browsing your inertia

46:50

app like a classic, or they want, because

46:52

otherwise you want to deploy them. So they

46:55

can continue browsing your inertia app like a

46:57

classic app, we make that request, do that

46:59

409 response, and like we automatically reflash data.

47:01

So if there was any, if you had

47:04

any flash data that was going to be

47:06

used, it automatically reflash does that. So even

47:08

though you're doing a full page reload, you're

47:10

going to still get that flash data come

47:13

available. So that's a really, really, really cool

47:15

feature of inertia that is like, I think

47:17

it would be harder to do with a

47:20

classic SBA, but because of the way that

47:22

the client side and service side adapters adapters

47:24

work, work, work, work, refreshing and asset versioning.

47:26

Like you literally all you have to do

47:29

is tell server side tell inertia what the

47:31

current version of the assets are and you're

47:33

done and it handles it. which is also

47:36

really nice from a development perspective because if

47:38

you're developing you're constantly changing your files and

47:40

a nurse you don't have to like constantly

47:42

hit refresh you can just click a link

47:45

and it'll just update automatically for you. No

47:47

I agree that is super cool I mean

47:49

to be frank I've been used to rails

47:52

handling asset management to me for so long

47:54

that it is frustrating every time that I

47:56

have to deal with it because I just

47:58

at this point in my development career I

48:01

just think that I shouldn't have to deal

48:03

with it because I know exactly. I literally

48:05

could not. I mean, shoot. We didn't even

48:08

have that problem in rails one because we

48:10

weren't serving assets on the project that I

48:12

was working on. Yeah. Yeah. Just it was

48:14

so long ago. Yeah. And there's there's some

48:17

really the last thing you so the last

48:19

thing I want to just mention. about inertia

48:21

that we kind of didn't talk about yet

48:24

and is the fact that inertia visits are

48:26

not limited to get requests. So you can

48:28

make inertia visits for post requests, put

48:30

requests, patch requests, and deletes as well.

48:32

And this is really cool. And it's

48:34

kind of a complex thing to explain

48:37

maybe on a podcast, but what it

48:39

does is it makes forms a lot.

48:41

more like classic rails form submissions, except

48:43

it's all done by XHR and it's

48:45

like it's like the most wonderfully simple

48:47

thing ever. So I'll explain kind of

48:49

how it works real briefly in layer

48:52

bell and then you guys hopefully can

48:54

kind of hopefully it'll make sense in

48:56

rails as well. So what you do

48:58

is if you have a form, say

49:00

a view form with all the reactive inputs,

49:02

right? And then you then a user presses

49:05

submit so to submit that data to the

49:07

form. you know down to the server in

49:09

that situation you would still submit that using

49:11

inertia so what you would have is you'd

49:14

have a submit interceptor right where you prevent

49:16

the default browser full page submission and then

49:18

you would say so imagine we're on the

49:20

create user page right and you hit create

49:22

user hit the button the form submits we

49:25

catch it and then in your JavaScript in

49:27

your view page component or in your react

49:29

page component whatever you would then say

49:31

inertia dot post, or we're creating a

49:34

user, yet post, and you would say,

49:36

we're going to post that to slash

49:38

users and pass in the data from

49:41

that component. So it's just like literally

49:43

a one-liner. But you don't then do

49:45

a bunch of work after that. You

49:48

don't say, well, give me the response

49:50

back and let me inspect the response

49:52

back and let me inspect the response

49:55

to see if there's, well, give me

49:57

the response, and let me inspect the

49:59

response, there's a happy path the user

50:01

was created and there's the unhappy path

50:03

there was a validation error service I

50:05

validation error so do happy path first

50:08

user you hit the user create page

50:10

or the user store end point so

50:12

that controller end point to store the

50:14

user validation all passes it creates the

50:16

user and then server side in that

50:18

XHR inertia request you then just do

50:20

a classic redirect to wherever you would

50:22

have normally gone. You would, if it

50:24

was just like a regular standard full

50:26

page application, you would just do a

50:28

redirect to wherever you want that user to

50:31

go after they created the user. So maybe

50:33

you send them to the user show page

50:35

at that point, right? So what you would

50:37

do, you would do the same thing with

50:39

inertia. You'd literally just say, however, in rails

50:41

or in layerbell, you return a redirect to.

50:44

that new user's page. So then that redirects

50:46

going to happen within that XHR request. And

50:48

what's going to do is it's going to

50:50

go now to that show user page. And

50:52

that show user page is going to load.

50:54

Keep in mind, this is all happening within

50:57

the initial inertia, the initial inertia post request.

50:59

So that redirects happening, you're now landing on

51:01

the user show page and it's just giving

51:03

you a response. But it knows that it

51:06

wasn't an inertia request because that X

51:08

inertia header actually gets forwarded on. when

51:10

that redirect happens. And then on the

51:12

user show page, it just returns, because

51:14

it knows it's an inertia request, it

51:16

just returns the the the Jason payload

51:18

back, which includes the the page component

51:20

name and the page data, which would

51:22

be the show user page and the

51:24

user data for that page. So that

51:26

all then comes back to your create

51:28

user. Hello, it is Ryan, and we

51:30

could all use an extra bright spot

51:32

in our day, couldn't we? Just to

51:34

make up for things like sitting in

51:36

traffic, doing the dishes, counting your steps,

51:39

you know, all the mundane stuff.

51:41

That is why I'm such a

51:43

big fan of Chumba Casino. Chumba

51:45

Casino has all your favorite social

51:47

casino style games that you can

51:49

play for free anytime anywhere with

51:52

daily bonuses. That should brighten your

51:54

day, Lop? Actually a lot. So

51:56

sign up now at Chumba Cumba

51:58

Cacino.com. That's Chumba Casino.com. page, you

52:00

know, that form, and inertia automatically now

52:02

dynamically swaps out the create user page

52:05

for the show user page and passes

52:07

the component. So you don't need to

52:09

do any work to like. redirect the

52:11

user, it just automatically happens because you're

52:13

redirecting server side. So that's the happy

52:16

path. The unhappy path is validation fails

52:18

and it essentially works the same way.

52:20

The user submits the form via post,

52:22

inertia post, that goes to the store

52:25

controller endpoint, the validation fails, it automatically

52:27

redirects you back to the page that

52:29

you're back to the page that you're

52:31

on. So, Laravel, if I go to

52:33

create a user and maybe it's missing

52:36

the first name, automatically does a redirect

52:38

back to the user page but then

52:40

includes some flash data saying well there

52:42

was an error and here's the error

52:45

which if you're using server-side classic server-side

52:47

templates you would then take that error

52:49

and repopulate the page with your old

52:51

values and display the errors. However with

52:53

inertia you get an inertia response back

52:56

so what it will do is a

52:58

redirect back to the create user page

53:00

and it will pass along the all

53:02

the data that you would have for

53:05

that page anyway. So the create user

53:07

page, maybe there is no data because

53:09

you're creating a user, but it would

53:11

say it's a create user page, and

53:13

then it would have some data, which

53:16

is the errors that just happened. Those

53:18

errors now get passed back to inertia.

53:20

And inertia now get passed back to

53:22

inertia. And inertia sees that were on

53:25

the same page still. of the page

53:27

component, so you're going to still be

53:29

on the create user page, but what

53:31

it now has is the errors. And

53:33

all you do, and those errors come

53:36

through as props, so they will, you

53:38

don't have to do any work to

53:40

update, as long as you're taking, as

53:42

long as your page component, your client's

53:45

side page components design, that any time

53:47

your create user page component is rendering

53:49

any errors that come through as a

53:51

prop, it's just going to because it's

53:54

all reactive. explain over a podcast. But

53:56

the point is, because it's all reactive,

53:58

because that's the way view and react

54:00

is felt worked, when that response comes

54:02

back and has the errors, the props

54:05

come in and they automatically update. So

54:07

you literally, it just ends up making

54:09

for these really, really simple forms, because

54:11

you literally, it just ends up making

54:14

for these really, really simple forms, because

54:16

you don't have to do a whole

54:18

bunch of wrangling to like, It's not

54:20

like you're having to repopulate that because

54:22

it's all there still because that page

54:25

component wasn't destroyed It was it's still

54:27

persistent there. Does that make sense? Oh,

54:29

it totally makes sense. I think it's

54:31

I think that's very close to what?

54:34

what we would have in rails, right?

54:36

I mean, I think rails does some

54:38

magic with that stuff, right? Like you

54:40

kind of like add some stuff to

54:42

your forms, some JavaScript stuff already, right?

54:45

Well, I mean, if you have rails,

54:47

not really. So the way that it

54:49

would, okay, so if I just had

54:51

vanilla rails, right, I would submit my

54:54

form, right? Happy Path would redirect me

54:56

to like a show page or an

54:58

index page, maybe the failed path, you

55:00

know, I would come back. because rails

55:02

is gonna render that template and rails

55:05

is going to conditionally now render some

55:07

new things kind of depends on maybe

55:09

what gems you have installed other things

55:11

like that but that's that's usually gonna

55:14

be what it is yeah but yeah

55:16

it's really close it's really close yeah

55:18

well that's good yeah so awesome I

55:20

mean yeah I think I think the

55:22

basic gist here that I'm understanding is

55:25

that inertia is going to make it

55:27

pretty easy for me as a rails

55:29

developer to say you know what I

55:31

have this maybe legacy application or something

55:34

Like I'm seeing a lot of use

55:36

cases with already existing applications where I

55:38

then want to sprinkle some view or

55:40

some react or something on a page

55:42

or two and and have it be

55:45

a little bit of a spot there

55:47

for a while. That's kind of what

55:49

I'm seeing the major use case with

55:51

Railsby. I mean I guess you could

55:54

design this with this in mind too.

55:56

I don't see anything wrong with that.

55:58

Yeah that's what most people are. doing.

56:00

People are upgrading like existing apps to

56:03

use inertia but like most people are

56:05

using it. it's kind of like Greenfield

56:07

projects at this point. But that's also

56:09

because it's a pretty new project. Yeah,

56:11

excitement, things like that. Also, always play

56:14

into this stuff. Yep. Any other questions

56:16

from you look before we kind of

56:18

roll into picture? Do we want to

56:20

talk about GitHub sponsorship? Sure. Do we

56:23

want to talk about get hub sponsorship?

56:25

Sure. Do we want to talk about

56:27

get hub sponsorship? Sure. Do we want

56:29

to talk about get hub sponsorship? I've

56:31

been doing open source for a long,

56:34

long time. And it's always a challenge.

56:36

We're going to open source, you know.

56:38

Justifying spending time on if you run

56:40

into business and if you have a

56:43

family and life's busy It's difficult to

56:45

justify committing large large chunks of time

56:47

to open source Just strictly from a

56:49

business or you know personal time management

56:51

perspective And so the what I did

56:54

with inertia when get hub sponsorships came

56:56

out I said you know what this

56:58

is a project that I think has

57:00

legs for the long term and this

57:03

is something I want to work on

57:05

but I've seen how much work tailwind

57:07

CSS took and what it takes to

57:09

make a really really successful project open

57:11

source project and I thought you know

57:14

I want to try to monetize it

57:16

in some way to help me justify

57:18

spending a bit of time on this

57:20

thing so I put out the get

57:23

up sponsorships and it was really I

57:25

totally didn't expect much of a response

57:27

but I got over 50 over 50

57:29

sponsors which is you know not enormous

57:31

amount of money but it's you know

57:34

upwards of about a thousand dollars a

57:36

month which was doubled it was like

57:38

$2,000 a month from get hub for

57:40

a while, which was awesome. I think

57:43

that's just, I didn't know what to

57:45

think of the get hub sponsorship stuff

57:47

at first. I'm like, are people actually

57:49

going to help contribute out of their

57:51

own pockets toward open source? And obviously,

57:54

get hub believed that that would open

57:56

source and obviously get hub believed that

57:58

that would happen. And now, you know,

58:00

it's crazy what some people are working

58:03

on open source. a kind of just

58:05

it's it's recognizing the amount of time

58:07

and effort it takes for for people

58:09

to work on open source and build

58:12

quality software that you know it's crazy

58:14

at the amount of at least for

58:16

me I've always worked in the layer

58:18

of L-P-P-P-P-P space like it's it's all

58:20

free software right and this is what

58:23

we're using to run our businesses and

58:25

everything else and to me it only

58:27

makes sense that some of that money

58:29

goes back if nothing else to just

58:32

help people spend business hours on open

58:34

source and not have to feel like

58:36

they're losing hours on open source and

58:38

not have to feel like they're they're

58:40

losing money or you know running the

58:43

issues with their boss because they feel

58:45

bad working on the journey work hours

58:47

or whatever. enough money and open source,

58:49

but I do think it's a definitely

58:52

piece of the puzzle. I'm pretty pleased

58:54

with it myself. Yeah, yeah, I totally

58:56

agree with that sentiment. Yeah. Awesome. Well,

58:58

I'm glad that you were able to

59:00

get some people to support you. So

59:03

let's, I guess before we move into

59:05

PICS, if people want to like get

59:07

a hold of you, follow you, things

59:09

like that, how do you recommend they

59:12

do that? Yeah, so I'm active on

59:14

Twitter, that's kind of like the go-to

59:16

place, just my last name, Ryan Inc,

59:18

Ryan Inc, Ryan Inc, Ryan Inc, Ryan

59:20

Inc, Ryan Inc, Ryan Inc, Ryan Inc,

59:23

Ryan Inc, Ryan Inc, Ryan Inc, Ryan

59:25

Inc., Ryan Inc., Ryan Inc., Ryan Inc.,

59:27

Ryan Inc., R, R, R, R, R,

59:29

R, R, R, R, R, R, R,

59:32

R, R, R, R, R, R, R,

59:34

R, R, R, R, R, R, R,

59:36

R database and layer of all stuff

59:38

there. So if you're interested, follow me

59:40

there. And then my website, Renwick, so

59:43

same, same handle, Renwick, R-E-I-N-I-N-K-I-N-K-D-C-A, I blog

59:45

on there. And yeah. And then obviously

59:47

in Nursia, if you Google, if you

59:49

Google, if you Google, or Nursia, if

59:52

you Google, if you Google, or Nursia,

59:54

JS, you'll. If you. recently unlucky enough

59:56

to lose our server developer who has

59:58

been building our Kubernetes stack for us

1:00:00

and this means that I've been spending

1:00:03

the whole week doing Kubernetes non-stop Kubernetes

1:00:05

this week. I had used it before

1:00:07

back in 2018 but The Kubernetes is

1:00:09

in a bit of a state of

1:00:12

flux at the moment. So coming back

1:00:14

to it, especially if you're kind of

1:00:16

running on Google, Kubernetes engine or something,

1:00:18

there's been a lot of changes. So

1:00:21

my pick for this week is a

1:00:23

book on Kubernetes. It's by... It is

1:00:25

Ryan here and I have a question

1:00:27

for you. What do you do when

1:00:29

you win? Like are you a fist

1:00:32

pumper? A woo-hooer! A hand clap or

1:00:34

a high fiver? I kind of like

1:00:36

to high five, but if you want

1:00:38

to hone in on those winning moves,

1:00:41

check out Chumba Casino at Chumba Casino.com.

1:00:43

Choose from hundreds of social casino style

1:00:45

games for your chance to redeem casino.

1:00:47

I lost in terms of conditions 18

1:00:49

plus. A English man. the English IT

1:00:52

mafia coming in here and it's called

1:00:54

imaginatively another Kubernetes book. It was updated

1:00:56

in February 2020 and it's been very

1:00:58

helpful getting up the speed with the

1:01:01

Kubernetes. Awesome. Any other picks for us

1:01:03

or is that your zetty force? That's

1:01:05

it. I'm not going to pick Kubernetes

1:01:07

itself. Make that what you will. That's

1:01:09

fair. I'd have to play a plane

1:01:12

if you did. I feel like anything

1:01:14

to make it easier. Do you know

1:01:16

what, we've got time for a quick

1:01:18

run here, we go, Kubernetes, right? You're

1:01:21

learning a Kubernetes, you think, right? I've

1:01:23

got my book, I've got my, my,

1:01:25

my docket desktop, I'm going to go

1:01:27

into settings and tick, tick the box.

1:01:29

I've got a requirement for Windows, so

1:01:32

we're doing all on Windows. And I

1:01:34

say to, I say to, docket desktop,

1:01:36

make me a Kubernetes cluster. Yes. Would

1:01:38

you like to guess how much RAM

1:01:41

this uses on my my desktop machine?

1:01:43

It should take a wild guess how

1:01:45

much this ticking this little box costs

1:01:47

me. All of it. It's free. It's

1:01:49

free gigabytes of RAM and I haven't

1:01:52

I haven't made any pods yet. I

1:01:54

haven't I haven't run my app. It's

1:01:56

just sitting there's each and three. It's

1:01:58

the first time like this machine's cracked

1:02:01

10 gig. two sticks of amnesty and

1:02:03

this is the first time the second

1:02:05

one's had to wake up. Yeah. That

1:02:07

makes sense, the typical Kubernetes cluster, right,

1:02:09

cluster, is you have a box that's

1:02:12

just running Kubernetes, right? All the other

1:02:14

stuff comes later, right, after that box.

1:02:16

I wonder if your little ticked box

1:02:18

right there is just spinning up the

1:02:21

Kubernetes, sort of. Yeah, if you, you

1:02:23

can see what the master machine or

1:02:25

whatever it is. Yeah, sort of. I

1:02:27

found a box, you can see what

1:02:30

it's doing, but, I mean, the plus

1:02:32

side, keep it, keep it's keeping positive.

1:02:34

There's some things to like there. Declaratives

1:02:36

are all good, but that's been around

1:02:38

for a while. The language of it

1:02:41

is nice and clean. So there's some

1:02:43

good signs. I'm a little confused though.

1:02:45

I thought all rails developers use Taroku.

1:02:47

So why are you even on Kubernetes?

1:02:50

Oh, I know. I know there's lots

1:02:52

of people that do. Don't get doing

1:02:54

around. I haven't. I have it. I've

1:02:56

always been very devops like person and

1:02:58

things like that. And things like that.

1:03:01

I don't, because I don't get a

1:03:03

lot of value in it personally. But

1:03:05

if you don't, if you're not really

1:03:07

into that, I can totally see that.

1:03:10

Just a little joke, because I know

1:03:12

that's kind of like a big part

1:03:14

of Rooku's background, right? A lot of

1:03:16

Ruby rules. I think so, yeah. They

1:03:18

came from our community, so yeah. It's

1:03:21

very great. That's my understanding. Yeah, yeah,

1:03:23

no, they're not bad. just I'm not

1:03:25

using them. Okay, I guess guess it's

1:03:27

on me now. So the first thing

1:03:30

that I'm picking today is we grew

1:03:32

tomato plants like we do every year.

1:03:34

So yesterday our tomato plants have been

1:03:36

producing for like about a month and

1:03:38

the average amount that I'm bringing in

1:03:41

is a bowl full that's like about,

1:03:43

you know, 10 or 12 inches big

1:03:45

and like six inches deep. Like we

1:03:47

have like, I don't know, like six

1:03:50

or seven tomato plants and they go

1:03:52

nuts and it all is because we

1:03:54

basically watch some YouTube videos on like

1:03:56

how to like prune them and not

1:03:58

like kill them and all these things

1:04:01

and so I'll paste them I'll paste

1:04:03

them in here so if you like

1:04:05

totally, there's probably more stuff out there.

1:04:07

There's probably somebody that knows how to

1:04:10

like take care of other kinds of

1:04:12

plants, but I'm definitely like pushing the

1:04:14

watch some YouTube videos if you're if

1:04:16

you're doing like some home gardening things,

1:04:18

you know, especially if you're like growing

1:04:21

stuff because it's like COVID and everybody

1:04:23

seems to be into that this year.

1:04:25

Maybe it's a little late for you

1:04:27

because maybe you're growing seasons past, but

1:04:30

definitely for if you keep doing it

1:04:32

next year. in the session, Luke was

1:04:34

like, hey, I don't want to have

1:04:36

to go to my logs to for

1:04:39

queries and stuff. Well, I did some

1:04:41

looking during. Well, I'll tell you why,

1:04:43

I can reveal why now, because blasted

1:04:45

apps and Kubernetes, and you can't get

1:04:47

at the thing. Okay, maybe what I

1:04:50

should give you is a link to

1:04:52

tutorial on how to read logs and

1:04:54

Kubernetes, because that I think is your

1:04:56

actual problem. query, debugging, tracing to the

1:04:59

exact spot in your code, explaining. So

1:05:01

I'll just link those because they were

1:05:03

cool anyway. So yep, those are my

1:05:05

picks. Jonathan, did you have anything for

1:05:07

us? Yeah, I didn't have anything at

1:05:10

the beginning, but I kind of, as

1:05:12

you guys were talking, I've come up

1:05:14

with three. One of them is, as

1:05:16

I've mentioned earlier, project that I was

1:05:19

involved with is called, tailwind CS test,

1:05:21

and this is a kind of a

1:05:23

unique approach to your audience to check

1:05:25

out, it's become really, really popular and

1:05:27

it's honestly changed the way that I,

1:05:30

you know, handle CSS. I pretty much

1:05:32

don't write CSS anymore because I'm using

1:05:34

Tailwind, which is, if that's confusing to

1:05:36

you, then it's, you should definitely check

1:05:39

it out. And I will warn you

1:05:41

if you've come from like a SAS

1:05:43

or a less background or just even

1:05:45

just plain old CSS, and you look

1:05:47

at this approach, you will probably be

1:05:50

disgusted at first. than you were before.

1:05:52

And the maintenance is. wonderful moving forward

1:05:54

because it's just a lot easier to

1:05:56

manage because it's all in each email

1:05:59

and not in CSS. So pick number

1:06:01

one, tail one, CSS. Pick number two

1:06:03

is, I mentioned earlier that I put

1:06:05

out a database course. Now I should

1:06:07

mention that this course was primarily, primarily

1:06:10

designed for Laerville developers. Well. totally designed

1:06:12

for layervel developers, but there is a

1:06:14

lot of a crossover between layervels ORM,

1:06:16

which is called eloquent, and active record

1:06:19

in rails. So there's interesting techniques. So

1:06:21

if you are a Larabelle developer listening

1:06:23

to this, or just even a rails

1:06:25

developer who wants to learn some techniques

1:06:27

about databases and how to make your

1:06:30

database queries faster. Check out my course

1:06:32

eloquent dash course dot rannic.ca which I'm

1:06:34

assuming will end up in the notes.

1:06:36

Yeah, so that's my second pick and

1:06:39

my third one is less software related,

1:06:41

but I live on a farm and

1:06:43

this week I've so a little bit

1:06:45

of background. I live on a farm

1:06:48

so I've wireless internet internet which basically

1:06:50

means that I have an antenna on

1:06:52

a tenantana on my property that points

1:06:54

to another antenna about two kilometers away

1:06:56

from this internet service provider. And this

1:06:59

year the tree line between us and

1:07:01

the tower that we point to is

1:07:03

like really growing in, the trees are

1:07:05

really growing in, the trees are really

1:07:08

growing in, the trees are really growing

1:07:10

in, the trees are really growing in,

1:07:12

the trees are really growing in, the

1:07:14

leaves are really growing in, the leaves

1:07:16

are really growing in, the leaves are

1:07:19

really growing in, the leaves are really

1:07:21

growing in our house is right. the

1:07:23

tower, I get perfect line of vision

1:07:25

to this tower. But the problem is

1:07:28

I have to then get it from

1:07:30

there to my house and my and

1:07:32

my barn as well. So I've been

1:07:34

playing around and been researching a bunch

1:07:36

of ubiquity products. And if you are

1:07:39

in the similar sort of position as

1:07:41

me, I can't recommend this stuff enough.

1:07:43

It's so cool. I've been playing around

1:07:45

with a product called the nano beam,

1:07:48

which are really like they're small little

1:07:50

things or maybe like circular, six or

1:07:52

seven inches wide. 15, I think 15

1:07:54

to 28 kilometers. Like I only need

1:07:56

it for like 300 meters or something

1:07:59

and it just makes it really really

1:08:01

easy to create these wireless connections between

1:08:03

like long-range wireless connections between different places

1:08:05

in my property so whatever I'm just

1:08:08

kind of nerding out on the ubiquity

1:08:10

products right now because I'll give you

1:08:12

a plus one for that. Yeah, you've

1:08:14

worked with them before? Yeah, so my

1:08:16

job that I had like over a

1:08:19

decade ago, one of the things that

1:08:21

we did is we broadcast auctions and

1:08:23

a lot of the barns that these

1:08:25

auctions would be done in, they didn't

1:08:28

have good internet connections. And so we

1:08:30

were using wireless equipment all the time

1:08:32

and we swore by this by ubiquity

1:08:34

so just just saying that was 10

1:08:36

years ago but but as far as

1:08:39

I know like you know good stuff

1:08:41

yeah it's it's pretty cool stuff I

1:08:43

actually have one already set up in

1:08:45

my property between two spots and we

1:08:48

actually had a white like a buried

1:08:50

wire under the ground and it gave

1:08:52

us all kinds of trouble and then

1:08:54

we put in a couple nano beams

1:08:57

and it's just like it's it's almost

1:08:59

like they are wired because that's what

1:09:01

it looks like from a network perspective

1:09:03

and they just they're they just work

1:09:05

flawlessly so that's my picks awesome all

1:09:08

right well thanks everybody for joining us

1:09:10

and we'll see you again another time

1:09:12

how to have fun anytime anywhere step

1:09:14

one go to chumba casino.com got it.

1:09:17

Step two, collect your welcome bonus. Come

1:09:19

to Papa welcome bonus. Step three, play

1:09:21

hundreds of casino style games for free.

1:09:23

That's a lot of games, all for

1:09:25

free. Step four, unleash your excitement.