Inertia.js - The Modern Monolith with Jonathan Reinink - RUBY 659 - Ruby Rogues

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:05):
Hello, and welcome to Ruby Rokes. I'm John Epperson, and
we are we have a couple of panelists today.

Speaker 2 (00:13):
We have Luke I welcome, and we have Jonathan Nni.

Speaker 1 (00:18):
Your thing like cut off and gave me the dots
right as I was looking at it, and I was like,
oh my gosh, Rinie, welcome. Jonathan is the author or
creator however you want to say that of a nurser
JS and we just have him here today to yap
about it. Can you just give us a little bit
just to start out about your background and how why
you might be famous, and then we can go ahead
to a nursery after that.

Speaker 3 (00:38):
Yeah, for sure.

Speaker 4 (00:39):
I am a web developer and I've been doing web
development for almost two decades by now, and I hang
out mostly in the Layra bell community, so I contribute
to that framework and kind of like doing all things
PHP and yeah, my main projects have been some libraries
and some phree libraries. I was also involved early on

(00:59):
in the tail when CSS framework if you're familiar with that.
Me and my buddy Adam Weathern built that, and more
recently I have focused on inertia as well as a bunch.

Speaker 3 (01:08):
Of database stuff.

Speaker 4 (01:09):
I'm a big fan of databases and optimizing databases and
active record and so I put out a course recently
about that. So those are kind of the things I
mostly work on. I work for myself. Outside of that,
I run a small SaaS business solo SaaS and that's fun.

Speaker 2 (01:23):
That's pretty much me awesome.

Speaker 1 (01:25):
So, since we were planning to talk about inertia, let's
go ahead and dive in what exactly is inertia.

Speaker 4 (01:30):
Yeah, so it's always fun when you come up with
a new project that's a little bit different than other things.
It's certainly been one of the most challenging things. It's
just explaining what inertia is. And kind of the simplest
way to describe it is it's a way to build
single page applications without needing an API, Meaning you can
build a single page app using a classic server side

(01:53):
framework such as Rails or layer bel and you can
use classic service side routing, classic server side control. But
the only difference is with inertia there is no server
side views. All the views are done with view or
they're done and react or done using spell And what
happens is you basically return some data from our controller

(02:14):
and where you'd normally return a view and they'll put
that data. You instead return a JavaScript page component. So
just imagine a JavaScript page component being rendered on the
page instead of like an EERB template I guess is
what they would be considered in rails. And obviously that's
client side rendered, so it's not server side rendered. But
what happens is every single time you navigate from one

(02:34):
page to the next, inertia intercepts any page clicks so
that you don't do full page reloads, but instead, when
you click a link, inertia will intercept that link click
and instead of doing a full page reload, it'll run
off to the server making what's called an inertia request,
and the server will pick it up saying okay, this
is the inertia request, and it'll fire back the data
needed for the next page. And the data is the

(02:56):
JavaScript page component, be view or react or whatever, the
data the props for that component. And then what happens
is client side, so that's made as an age AX request,
that data comes back, the response comes back, and then dynamically,
client side, the page component is swapped out, and that's
using dynamic components, which is a feature of all three
of the popular client side frameworks view Reaction SPELT, so

(03:19):
it's dynamically swapped out and it's given its new page props.
And the big, big, big benefit there is one when
you're navigating from one.

Speaker 3 (03:27):
So there's like three key benefits.

Speaker 4 (03:28):
One, you're navigating page page, you're not doing full page reloads,
so there's a performance benefit to that. Two when it's
doing that because you're not doing a full page reload,
it's not having to reboot, view or react every single time.
So it's like really like silky smooth kind of experience.
It's just like a it's like you're working with an SPA,
except you're not. You're just navigating from one page to
the next, and it's just swapping out those components, those

(03:49):
page components dynamically.

Speaker 3 (03:51):
And three and I knew this was going to happen.

Speaker 4 (03:53):
I don't remember my third third benefit, but oh, the
third one is the obvious one. You get to build
an app using client side technology. And really kind of
what pushed me down this road is I was building
more like in my applications that I built and I build,
I always use layravel, which is very similar to rails.
So for this audience just kind of think of them
more or less as the same thing I was. You know,

(04:14):
much of my apps were starting to contain more and
more like rich UI and more client side functionality, more
JavaScript requirements to basically make the UI's work a certain
way that just kind of wasn't possible using classic server
side rendering. And what I was basically doing is I
was in my page responses, I was returning server side renderview,
which would then have view components mixed into the page.

(04:38):
So what would happen is the response would come back
from the server, then view would kick in the gear,
and any of the view components on the page there'd
be like a little flicker and then they would show
up right, and then you'd have those individual components would
be reactive and whatnot right. And so by going that
kind of comes with a whole bunch of interesting problems.
I mentioned the flicker and just kind of having to
manage each one of those separate components.

Speaker 3 (04:57):
So by going this way with.

Speaker 4 (04:59):
A NURSE, you're really like fully committing to client side
render views, So you give up server side rendered views.
That is a trade off, but that means is anytime
you're working with any of the templates within your application.
You have the power of JavaScript, you have the power
of view or React, and you can do whatever you
need to do.

Speaker 3 (05:15):
And it's just a really really nice way of working it.

Speaker 4 (05:18):
Yeah, so that's kind of a longer description. I would
say that, like, I definitely built it for people who
have traditionally worked with server side rendered applications like frameworks
like again layer Bell, Ruby, Django, that kind of stuff.
People who are familiar with creating controllers and getting data
from the database and then passing that data to a view.
The whole paradigm is very, very similar and much different

(05:40):
than the classic, the more standard SPA approach where you
have some separate API, some separate app that provides like
ar rest API or graphic you LAPI.

Speaker 3 (05:49):
So it's definitely targeted.

Speaker 4 (05:51):
At that audience, and kind of, as I've said to
people before, I kind of joke that Inertia is like
the gateway drug to creating single page applications because if
you're coming from a monol with background in er should
just makes it so easy to get up and running
with creating like what essentially feels exactly like a client
side single page app of kind of using the technology
that you know and love already.

Speaker 1 (06:10):
Yeah, I actually find it super interesting. I mean I've
been for at least the past day or so kind
of checking out some of the stuff on the side
and things like this, and there's a lot of interest.
So it kind of sounds just to make sure that
I understand this the way that I think that I
understand this, You're more or less going to, obviously, being
familiar with rails here, You're going to create like this

(06:31):
kind of high level sort of meta layout as you
will or whatever. And then instead of creating a whole
bunch of views for all of my pages, I'm just
returning this inertia thing which has a props attribute or whatever,
and then I'm just basically returning data is Jason, so
kind of a bit like an inline API kind of
thing almost like I'm just kind of rendering Jason almost there,

(06:52):
And that's more or less how my page is going
to run, and that's how my back end's going to run.
And then I basically just have a single page.

Speaker 2 (06:59):
App on the page.

Speaker 1 (06:59):
That's it, and all these props get passed down and
I just do with it what I want to in
that single page.

Speaker 2 (07:05):
Of Yes, so a couple interface as you will.

Speaker 4 (07:08):
Yes, I like, yeah, So a couple of things to
be aware of. Like, I like to compare inertia in
a lot of ways to almost React router or view router,
because in a way, all Inertia is is a specialized
router like client side router that lives between your server
and your controllers, which is returning data as Jason and
your client.

Speaker 3 (07:29):
Side page components. So it's the piece that connects the two.

Speaker 4 (07:31):
But unlike with a classic app, you know, with view router,
React router, whatever, you don't have any client side state
management at all, So you're not using any client side
like view x or whatever the React equivalents are. You're
not using any of that stuff because all your data
and all your state is essentially at the server, So
it's not like you're making requests to the API client side,

(07:54):
saving that in your client side's vieux library or database
or whatever you want to call it, and then rendering
components based on that. Basically, every single time you visit
a page, the data's coming straight from your controller and
go into your your client side page component.

Speaker 5 (08:10):
All right, I got a dumb question. You're going to
have a few votes from me. So I wanted to
kind of have a go at this. And I've been
building this view app. And the way I populate my
VU is it a view or VU view? It's the accent,
isn't it. I can't I can't even tell. I think
I'm trying to make it English. The way I populate
my component is I go off with my HERB, my

(08:32):
ERB template downloads, and then I do a get to
get the initial data from the page, and then it
drops in when to get returns. You've got your view
building there. Yeah. Now in the examples on the inertia
JS site, then it uses Laravelle. And we could take
a nice divergence here because I'm starting to get Laravelle

(08:53):
envy some of the tooling, some of the tooling that
you show off on the inertia jas website. I don't.
I didn't think the Ruby or rails community have. I'm
sure John no more. But there's a there's a plug
in where you can see the database queries being done
on that page like the sequel, and I saw that.
Oh would have been useful. I mean for years if

(09:17):
I could just see what the what the page was hitting.
You know, does that exist for rails.

Speaker 1 (09:22):
I'm pretty sure I've seen various things, and you can
definitely see it in your logs.

Speaker 5 (09:26):
I know, I know I can see it in my logs,
but you know to have it.

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

Speaker 5 (09:46):
No, I don't actually no, I didn't find a tab.
Where's the tab?

Speaker 4 (09:50):
Every code snippet, every code snippet there is on the site?
It defaults to Larvel, but you can switch it over
to rails.

Speaker 5 (09:56):
Oh no, some basic fail going on here.

Speaker 2 (09:59):
No worry.

Speaker 1 (10:00):
So what I'm saying is you're very appreciative of how
awesome Laaravel is on a review podcast.

Speaker 5 (10:05):
All right, listen, I'll be honest.

Speaker 3 (10:08):
This is not the first time this has happened.

Speaker 5 (10:11):
That's a nice workflow, you know. I like the tool.
I can't find this finger I don't believe it.

Speaker 2 (10:17):
Exists, right, now I'll take a screenshot.

Speaker 4 (10:20):
Yeah, So the tool and layer bel in the PHP
community it's called it's called the PHP debug bar, and
there's a Layervell debug Bar version built on top of that.

Speaker 3 (10:30):
And it's fantastic because it's exactly what you can.

Speaker 4 (10:33):
You know, you can figure out all your database queries
and your logs and whatnot. But what the layravel debug
bar does is it just puts them right in the
bottom of your screen, just like it's almost like a
Chrome console right where it shows you exactly what database
queris you're making, and what models you're loading from the database,
and how much memory you're using. It's super super helpful,
helpful you identify N plus one issues and slow queries

(10:53):
and stuff.

Speaker 5 (10:54):
Where's my Rails debug bar? That's what I want to know,
Moving swiftly on from my basic ability to use a website.
So I was asking about the way you cook it
in what there's for the benefit of people who can't
use website like me. How does Rail send down that
lump that cut because there's two things, aren't there. There's
the kind of layout and there's the and the props.

Speaker 3 (11:15):
Yes, yeah, yeah, so I'll walk you through.

Speaker 4 (11:17):
That's I often failed to kind of explain this just
because you know, you forget sometimes kind of where to
start after you've talked about something for long enough. But
so what essentially happens, and I'll explain it as best
I can kind of using Rail's lingo, but I'm not
super familiar with with it all, but like.

Speaker 3 (11:32):
Work with me.

Speaker 4 (11:33):
So basically, a request is going to come in, so
through the very first time that someone hits your inertia application,
your inertia rails application. What's going to happen is it's
going to notice that it's just it's a standard full
page visit, right, And what it's going to do is
it's going to hit rails and it's going to see
that it's not an inertial request. So it's not going
to return some JSON. It's just going to go through
the normal flow. And what it's going to do is

(11:55):
it's going to return your base ERB template, so your
layout file, right, and that layout file, well, it's just
like a standard layout file that has your head which
is going to have your script tags and it's gonna
have your style tags kind of just your standard layout.
The difference is what it's not going to do is
it's not going to keep in mind that someone may
land on your app on any different page. It doesn't

(12:15):
have to be the homepage, of course, of the index page.
It could be any page in your application, right, So
it's going to see that request coming in, so it's
going to return or it's going to server side render
that layout. Except the only difference is within the body
of that server side rendered HTML file, it's not going
to have any page content, So the page content will
not exist. So you landed on, say the user's page
within your application, it's not going to have a bunch

(12:36):
of HTML server side HTML generated and rendered. What it's
going to do instead is there is a base DIV
that it's that you need to put in your base layout,
and that's the DIV that your client side application is
going to mount to. So what happens is that based div,
your client side app, view, React whatever mounts to that.

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

(13:16):
So imagine ATIV has an idea of app, which is
what your Viewer React apps can amount into, and then
it has an attribute called data dash page and the
contents of that data dash page attribute is just a string,
but it's actually a Jason encoded string, and what it's
including is all the necessary information that INERTI needs in

(13:37):
order to boot up that particular client side page component.

Speaker 3 (13:41):
So it's going to include two main things that the
most important things to know are. One the component name,
So the component name is going to be the viewer
React component page component name, so in this case it
might be the user page, which is going to have
a corresponding user page dot view file or user page
dot react file. And then the second piece of information
that's going to be in that Jason payload is the props,

(14:01):
which is the data. I call them props because they're
considered when you're working with viewer React. Props are the
properties there, the attributes the data that gets passed to
that component. So it's essentially the data.

Speaker 4 (14:12):
So if you imagine now if we hit the Rails app,
it's the user's page which gets which causes the routing
to go to the user's controller, the index method of
the user's controller. Your index method is going to go off,
and it's gonna use active record to get some data
from the database for the users that you want to
display on that page.

Speaker 3 (14:30):
And then in a classic.

Speaker 4 (14:31):
Rails app and jump in if I get any of
the terms wrong here, gents, because I'm you know, I'm
gonna use more kind of lingo that I know. But
what it's going to do is normally you would then
return an ERB template that you pass the user index
view too, and pass the data which is the users
you just looked up from the database, use an active record,
and that's going to go off and generate your HTML.

(14:52):
In this situation, you would instead return an inertia response.
So it's but the clever thing about the inertia response
is so it's basically the exact same thing. You basically
return inertia. You pass it the name of the page component,
and you pass it the data. So the controller itself
doesn't know if it was a full page visit like
a standard get visit, or if it was an actual

(15:14):
inertia visit. Inertia takes care of that. All the controller
has to do is to return the page component name,
so the client side page component name and the data
for that component. Then the Inertia behind the scenes, it
inspects the request and says, okay, was this a full
page visit? You know, so where we need to display
the layout? Well, if that's the case, well then we're
going to display the layout. We're going to render its

(15:35):
server side, and we're going to inject that base div
with the idea of app and with the data page
attribute with all the data for it, and then we're
just going to render that out. It's kind of just
a standard htam olt page. Then Inertia will grab that
data and boot up the client side application. However, on
subsequent visits, when inertia, so if you go then and
click to a different page, maybe you click on one

(15:56):
of the users you want to view the user, when
inertia does is it intersect that click that page visit
and it then makes the XHR request to the server.

Speaker 3 (16:04):
It's going to hit in the exact same way.

Speaker 4 (16:06):
Now imagine it's going to hit your user's controller again,
but this time it's going to hit the show method.

Speaker 3 (16:10):
So again, what would you.

Speaker 4 (16:11):
Do just an standard layer or standard layer belt or
rails app is you go off, you'd get that user
from the database, use an active record, right, and then
you would normally just return a response to show the
user show page with the user data. Except again with inertia,
you wouldn't do that. You would do you'd return an
inertial response that would then have the user show page component,
client side page component, and the data which would be

(16:33):
the user data maybe their ID and their first name,
their email and their last name and whatever else. Right,
So when that request comes through the XHR request, what
inertia does is it passes through an ex inertia header
which is set to true so that your rails app
knows that this isn't a full pagreload. This is this
is like an inertia request, So it's an XHR request,
and what it does instead is it returns not the

(16:57):
full body and the full layout and everything else.

Speaker 3 (16:59):
It just turns the Jason data that it requires.

Speaker 4 (17:02):
So that's the same Jason data that we put in
the data page attribute if it was like the full
you know, HTML layout render kind of on the first visit,
except it just returns the Jason and nothing else and
it returns out obviously is adjacent response, which that's gonna
have your component name and all your props and then
kind of getting back to what I explained earlier, and
Nursa's gonna then take that. It's gonna dynamically swap out

(17:24):
the client side page component with the new page component
and dynamically swap out the data the props for that
component and like service sorry for the for the user
and the browser, it's.

Speaker 3 (17:35):
Gonna look like you went to a whole new page.

Speaker 4 (17:37):
But the reality is it's just done some really nice
magical work in the background to just kind of flip
it for you. And then, of course, like I said,
Inertia is essentially in its simplest form, it is a
client side routing library. So it's gonna update your URL
in the browser, and it's gonna update the necessary page
state so that you have like you know, proper history
and stuff so you can navigate back and forth and
stuff like that. So that's kind of like the trickiness

(17:59):
that we do with the reality is from a development
experience for people who are using rails or layervell who
are kind of used to working with that, Hey, I
got a controller, I got a controller method, I got
to get some data from the database and I got
a return of you with some data. It literally feels
the exact same way, except the difference is you're ending up.
You're working with viewer React templates, you're not working with

(18:19):
EARB templates.

Speaker 5 (18:20):
All right, I found it. Now It's super easy. And
for the other kind of web challenge people who are listening,
there is a gem. There is. This is the this
is the key component I was missing. There is an
inertia under school rails gem that does it for you.

Speaker 3 (18:35):
Yes, yes, I should have mentioned that probably too. Yes,
so you don't got to do any of this work.

Speaker 4 (18:40):
This, like I said, when inertia does all the magical
work for you, it's actually and when I say magical,
it's really not that.

Speaker 3 (18:45):
It's not magical at all. It's in its most basic form.
It's imagine this.

Speaker 4 (18:49):
You have a page response, The inertia gem looks to see,
Hey was the x HR Sorry was the ex inertia
header set to true? Well yeah, if it is, then
return Jason instead of HTML. It's like literally that basic,
and there is you know, some other interesting features that
kind of go along with it, such as automatic asset
refreshing and partial reloads so it does get more complicated,

(19:09):
but in its basic form, like I tell people that
if you didn't have the gem, like so, we do
have an official Inertia gem for Rails, and we also
have an official layer bel package for this as well,
so it kind of just makes it really really easy.
But there's all kinds of people who are making adapters,
client side adapters for other languages and frameworks, and it's
in its most basic form, it's really does not take

(19:30):
that much.

Speaker 3 (19:30):
We actually have a page that kind of explains.

Speaker 4 (19:32):
A spec I kind of call it a protocol because
in a way, that's really what it is. And as
long as you implement that protocol, which is a very
simple protocol, you can do this in other language. I
tell people I've literally seen this done. Somebody reached out
and they had done this in cold Fusion. I didn't
even know cold fusion was still a thing, but somebody
has created an inertia cold Fusion adapter, and there's there.
I know there's been one creative for Django and all

(19:53):
kinds of other frameworks. Now, the challenge for me as
a library maintainer is normally in the past, anytime I've
created library I've always worked with the language that I'm
familiar with. So I've worked with PHP and layer Vell
and it's not been that or even JavaScript, and it's
not been that hard making the you know, maintain the library.
The challenge where the ertia is I'm finding myself becoming
more proficient in other languages and frameworks because in order

(20:15):
to maintain the Rails adapter, I got to now be
more of a Ruby expert on anything about an expert
I should even said that, but like I got to
know the basics of those frameworks.

Speaker 3 (20:23):
But fortunately I've had some a lot.

Speaker 4 (20:25):
Of people kind of like jump in and help out
on framework specific adapters. Really that my job at the
end of the day is managing the client side adapters,
because that's, honestly, that's really the hard part. The view
the React and the Spelt adapters are the tricky kind
of piece because they're all they kind of got little differences.
The way they do dynamic components swapping, the way they
do data handling, the way they do reactivity. All that

(20:46):
stuff is it's a little bit different each one of
those client side frameworks.

Speaker 3 (20:49):
So that's kind of like.

Speaker 4 (20:50):
Really the heart of my job. And even there I
actually have somebody who's helped on the project. One guy
who's managing the so I managed to view adapter, another
guy manages the React adapter, and another guy manages be
spelt adapter. So that's been It's really quite a collaborative
project in that sense.

Speaker 2 (21:04):
All right.

Speaker 1 (21:05):
Now that we theoretically know how to make an app
with inertia, why am I making an app with inertia?
Like what where do you see inertia kind of fitting
into the space? And what kinds of apps are we
using it for?

Speaker 2 (21:16):
Things like that?

Speaker 4 (21:17):
Yeah, that's a really good question to ask, because I
think it's important. I think sometimes what happens is people
come out with new projects, and I think people like
the idea of saying, well, this, this whatever, this new
piece of technology is, this is now the one way
to do all the things, and we just like we
want to like double down and fully commit to that
for everything. And if it doesn't do everything, well, then

(21:38):
we don't like it. Yeah, we get disappointed if it
isn't appropriate for all use cases.

Speaker 3 (21:42):
And I'm generally.

Speaker 4 (21:44):
Like slow to say use the right tool for the job,
because I find quite often we're just most effective using
the tool we know and that's tends to be what's
worked out better for me. I know that, you know, yeah,
I know that Electra might be better or no, it
might be better for creating certain apps nowadays, but I'm
just so stinking fast with layer Bell that I just
I use that because it's a tool I know and love.
But I do I will say that kind of in
response to that question.

Speaker 3 (22:05):
I do think that.

Speaker 4 (22:06):
Inertia is super suited, super well suited for some situations
and not others. So the one that it's not well
suited for is in a situation where it actually does
make sense to make a full on API. So if
it makes sense for you to have a full rest
API and a full graph QLAPI, then Inertia maybe not
the right choice because with inertia, the whole like my
goal with this is to avoid you having to create

(22:28):
this whole separate project, this whole separate API, figuring out
all the authentication figuring out with all the old off
stuff and all that Hoopla and the separate hosting account
and everything else.

Speaker 3 (22:37):
Like, my goal is that I just want to build
an app.

Speaker 4 (22:39):
I want to get some data from the database to
use an active record, and I want to spit that
to I you and render it like that's what I
want to do with inertia. It's a like the very fast,
classic monolith way of building an application. But if you
did have a use case that you really truly did
need an API. So maybe you're building a web app
that has an iOS app and an Android app, and
maybe you have maybe you have a native desktop applications

(23:00):
or whatever. If you have that use case, then inertia
may not be the right choice because it might just
make sense in that situation to actually just go off
and build that HOLYPI. But in my experience, there's a
ton of applications that get built and I would say,
like especially like a lot of just like business level
applications that never ever ever go past being a web app.

Speaker 3 (23:19):
That's what they always are.

Speaker 4 (23:20):
So yeah, there is there a chance that it could
eventually need an API, sure, but so often you don't
need that. And you know what you think about any
application that's built with just Classic LAYERVELT and built with
just Classic rails using Classic Rails service side rendering or
layveel service side rendering, you've already made that decision. You've
already said this is the web app. And if I
ever need an API, well, then I going to go

(23:41):
off and build this a great API for it. So
that's really where inertia fits. If you were planning and
building a server side rendered application, you've already given You've
already said.

Speaker 3 (23:50):
No to the API.

Speaker 4 (23:50):
So my thing here is I really wanted Anertia to
be for those developers, those who said, you know, I
want to build a service side application. I was gonna
build it with layer bel or I was gonna build
with rails using the standard monolith approach. I've already decided
I'm not going to build an API. Well, then inertia
is a wonderful fit because then it allows you to
build a rich client side application using viewer react will
still completely working within the paradigm the monolith approach that

(24:13):
you know, and you can be really really really fast
with that approach. And in my experience as well, I
have built applications that use Inertia.

Speaker 3 (24:21):
As kind of the web app tool.

Speaker 4 (24:23):
And even in those applications I've have like my own application,
I do have an iOS and Android app that I'm
building right now, but the iOS and Android app is
so simple compared to the web app, because that's what
makes sense for.

Speaker 3 (24:33):
My business that I didn't.

Speaker 4 (24:34):
Even then, I still went in my layer of bel
app and I just built a really light rest API
for my native iOS and Android apps. I still didn't
need to fully double down and make my whole web app,
you know, run on on this API. It's still made
sense to build a web app using using Reactor, View
and Inertia without an API. And then literally I have
like five endpoints, five API en points for this core

(24:56):
functionality that I'm making available natively to iOS and Android.
So I hope that kind of explains it. So that's
really I would say. The reality is there are probably
a ton of situations. Basically, anytime you were planning on
building just a classic rails application, that's a good use
case for an inertia app if you have any sort
of more interesting client side needs. And by that, and

(25:16):
this is maybe the last distinction I should make, I
wouldn't personally use Inertia for anything that needs to be
public facing. So that's and the reason why is Inertia
is still a client side rendered application, meaning it doesn't
work great from an SEO perspective. Yes, Google is getting
better at indexing View and React apps. The JavaScript apps

(25:36):
it is, and it probably only will continue to get better.
But I think if I was building an application, if
I was building a blog, or if I was building
a news side, or I was building anything that had
a public face that where SEO Search engine optimization was
a concern, I probably wouldn't use inertia because of that limitation. Really,
I designed inertia for you know, admin control panels, applications,
you know SaaS applications where you need to log.

Speaker 3 (25:58):
In all those kind of tools.

Speaker 4 (26:00):
And one great use cases I've done this as well
is you could absolutely say, build a RAILS application that's
completely server side rendered for your public facing pages. Maybe
you're building a SaaS app. You have a bunch of
documentation that you want to make sure it's SEO friendly.
You have your pricing page, and you're about page, and
all those feature pages. You could build all that stuff
using RAILS with classic server side rendering, will still having

(26:20):
the application in the background. For the actual SaaS application
be an inertia application, but that's only available after you
log in. And that's a really common combo where you
use server side rendering on the front end and you
use inertia and client side rendering on the back end.

Speaker 5 (26:35):
Can we talk about the flicker.

Speaker 4 (26:37):
Yes, yes, So the simple answer is there is no flicker,
no flicker at all. That's why it's so wonderful. So
there was a flicker. Building it the old way. So
the old way I do this is anytime I needed
some view of view component or React component in my application,
I would be using classic server side rendering in layer vow,
which would return my full document, which would have all
the page content, but somewhere in the page. So imagine

(26:59):
it's maybe like a create user page, and maybe I
want to create the form to create the user.

Speaker 3 (27:03):
Maybe I wanted to.

Speaker 4 (27:04):
Build that in view because I like the reactivity of it.
I like be able to handle errors and everything else,
just kind of using that view approach. Right, So maybe
i'd have the whole page load, except the form itself
would just be a view component that.

Speaker 3 (27:13):
Would boot up after the page loaded. Right, And that's
what I mean by a flicker.

Speaker 4 (27:17):
That little thing takes a second to boot up because
view has to viewed boot up, and it's minor, like
we're talking milliseconds, but our eyes can perceive it, and
we especially notice it when that component takes no space
at first. But then if then it renders and it
takes a bunch of space and kind of like causes
the page to become longer, and you know, things move around,
and if you have a lot of view components, maybe
you have a drop down component or modal or different

(27:38):
things like this, that problem just becomes worse and worse.
Where with inertia that totally totally goes away because you're
getting exactly what you'd have with like a Classic view
or Rails or sorry, a view or React app, where
when you go to visit another page, it's going to
just render that new view component and nothing's getting destroyed
in the in between because you're not doing a full
page reload.

Speaker 3 (27:59):
View and React are long living.

Speaker 4 (28:01):
So when I go to the next page, it's going
to load that file in the background, it's going to
load the data in the background via that exit tour request,
and then when it's ready, it's going to swap it
out and you can you know, there's load ways to
have loading graphics and stuff in between that, but the
point is nothing's being destroyed when you go from one
page to the next that's causing any sort of flicker.

Speaker 3 (28:19):
It's really really smooth.

Speaker 5 (28:21):
So you sound like you care a lot about kind
of responsibility and user experience. Yes, very much, So let's
talk milliseconds here. Let's talk some real numbers, because I
can see we could take an enormous effort into kind
of making this to help people improve the experience so
they use this. Let's face it, the whole point is
to make the site nicer for the people we write

(28:42):
the software for. So what looks like a good load
page for you?

Speaker 4 (28:46):
Yeah, So my goal generally on a regular web app
is two hundred milliseconds or less. If I'm building a
new application, That's really what I'm going for. Now, That's
what I would consider like a typical server response. But
as you know, there's more that goes into a website
loading than just your server response. You also have your
client side, the time that it needs to render there,
the time that it needs to actually painted it on

(29:07):
the page, the time that it needs to download, and
JavaScript bundles and different things like that. So yeah, for me,
this is honestly, this is one of the reasons why
I like this approach so much, is because I've been
very frustrated in the past building rest APIs or even
graph Q on the graph QL is amazing, but you
can run into performance issues really easy with graph u L.
If you're not careful, you can run into n plus

(29:27):
one issues just depending on the sort of graph of
data you're returning. It can be tricky from a performance
perspective in real applications to have every response from your
API be really quick. And that's because these APIs, especially
a rest API, is generic. It's generic because it needs
to work for multiple different any application that wants to
consume that that API. The wonderful thing about rails, and

(29:49):
the wonderful thing about layer val is that every single
control or method you are going to get the data
exactly as you need it for that page. There's no
generalized A there. It's like, okay, I'm displaying the user's page.
I want to go to the database and I want
to get these ten users if it's paginated for example,
and I want to get their name, and I want
to get their ID, and I want to get their

(30:11):
email address, and maybe I want to egarload their company
company along with it. So what inertia And this isn't
really an inertia feature. This is really just this is
really just a rail. This is like a monolith features,
like when each end point is only responsible for getting
the data that it needs for the page that it's
going to display, you can highly highly optimize the data
retrieval for those endpoints for exactly what's needed in that application.

(30:32):
So that's one of the reasons why I really just
like monolith apps in general, because I feel like that
that approach.

Speaker 3 (30:38):
Just leads to fast applications.

Speaker 4 (30:40):
And I've talked you know, I mentioned earlier that I
love databases and I love writing learning how to you know,
kind of make the most of the database, create proper
indexes and return the minimal amount of data, and that
run the fastest career as possible. That's that's stuff that
I'm super interested in and focus on. So roundabout way
of answering your question, I like two hundred milliseconds or
less from a response time from the server, which would

(31:00):
be the inertia response. But then there's also this whole
client side performance side of things, So let me talk
briefly about that as well, because that is absolutely a
tradeoff you get when you build a client side application.
So one of the trade offs we've talked about already
is you the sdo tradeoff if SEO is important to you,
probably not going to make sense to build a fully
client side rendered application unless you have some sort of

(31:21):
service side rendering in place. And there's all kinds of
fancy tools nowadays even to do that with JavaScript stuff.
But you know what I'm saying, if SEO is important
to you, you're not going to want to have client side
rendering as your primary way. So the other trade off
is that you now need to send all that to
all your client side views. So all your page components,
all your view components, are your your React components or
your spell components, they all need to now be sent

(31:43):
over the wire as JavaScript bundles to the client.

Speaker 2 (31:45):
Right.

Speaker 4 (31:46):
So Inertia what it does, and this is kind of
like a really just I think a cool feature, is
it will automatically like it makes you can use because
it is just really a plain old regular view or
React app. It supports code splitting. So if you use
code splitting, what happens is you land on the very
first page. So maybe you know, going back to our
example from earlier, let's say you hit for the very
first page, the user index page. What it's gonna happen

(32:08):
in Inertia app is it's gonna go and get whatever,
only the minimal amount of JavaScript that's required to display
that page. So it's gonna get your typically kind of
like your core bundle, which is gonna have like view
or React and maybe some like core dependencies that are
used kind of by the you know, all pages on
the site. So it's gonna grab that core bundle, which
is small because it doesn't have all the pages through

(32:29):
your whole applications, just the core bundle, and then it's
gonna load whatever whatever components are required for that page.
So it could be the if it's the user index page,
it's gonna go off and get the user index JavaScript
bundle and download that, and then once it's downloaded, you
never have to download it again because it's cash right
and the browser knows to not go off and download
it again.

Speaker 3 (32:46):
So what that.

Speaker 4 (32:47):
Practically means is you hit an inertia endpoint. It's gonna
it's gonna only get the minimal amount of JavaScript that
you need to actually display that page, and it's gonna
get the minimal amount of data from the server because
that's the way a rails app works, and the page
can load like loads extremely quick, So I actually have
a demo app if you want to try it out,
if you call the demo apps called ping CRM, which
is available on the Inertia Gas website, and you can actually,

(33:09):
you know, click around this application and see exactly what
the performance is like.

Speaker 3 (33:13):
And I think, like, so it's hosted on I host it.

Speaker 4 (33:15):
On Heroku, and I do that intentionally because anytime you
host in Heroku, there's even a performance cost in saying
having a one off linot or Digital Ocean, you know, server,
because one for one, the database is the Postcrest database,
which is not hosted on the same site as the
actual web dinos, so there's always a performance cost that
comes with that, which often you know, of course makes
sense if you want to have multiple web dinos and whatnot.

(33:35):
So I've hosted it that way because I feel like
that's a good representation of a real life application. And
most responses from the server come back in about one
hundred milliseconds, and I think, you know, that's a pretty
awesome experience.

Speaker 5 (33:46):
I've tried it. It is disgustingly quick.

Speaker 3 (33:50):
That's what I want to hear.

Speaker 5 (33:51):
For me in the UK comes back in well under
one hundred well under one hundred to the extent that
I'm quite suspicious that you're loading the next page the
ground that terming me first or doing some kind of
dirty trick like that isn't you know?

Speaker 3 (34:04):
It's funny that you mentioned one hundred percent. Absolutely it is. Yeah, absolutely,
it is hitting the database.

Speaker 4 (34:09):
And that's interesting you mentioned that because because it is
a JavaScript application, there is really some cool opportunities to
even do stuff like that. So if you hover over
a link for more than a certain period of time,
go off and eager load that data. And even if
you don't want to egerload the data, what we can
do is eiger load the next JavaScript page component that
that page, that link would require. So even if you

(34:29):
are using code splitting, we can be smart about eger
loading that next page component that you may want.

Speaker 3 (34:35):
To click to. So yeah, there's that's a kind of
the neat thing.

Speaker 4 (34:37):
Because it is ultimately a real view or ultimately a
real React app, you kind of get some of the
cool things that you can do with those pieces of
technology as well. I've been working on another feature that
even allows you to do kind of like placeholder pages.
So if you were to click on a if you're
on the user index page and you were to click
on the user like a show user page. I've got
a working prototype where it could show kind of like

(35:00):
a shell of the show user page while inertia is
still in the background grabbing that data just again using
a classic rails controller show endpoint.

Speaker 3 (35:07):
And then swap it out when it has the data ready.
And these are like those.

Speaker 4 (35:11):
It's not necessarily something so the inertia, So the Pinxi
r M demo doesn't do any of that, but it's
I just think it's neat that if you had an
application that you were that concerned about the user experience
and you just really wanted to show something right off
the bat when someone clicked a link to view a
new page, that inertia allows you to will allow you.

Speaker 3 (35:28):
To do that. It technically doesn't allow you to do
that yet, but that's something I'm working on.

Speaker 1 (35:31):
Yeah, I certainly like speed, but I certainly don't get
as excited necessarily as other people do about speed. But
I know that a lot of people do care about it.
I think the thing that's most interesting here is so
I know that it might be heresy, but I for
a long time have more or less said that to me.
The controller in NBC right, really is an API provider

(35:52):
and you're just consuming that API with your view and
that's sort of like the typical way that people use it.
And so I think that inertia like just kind of
leverages that. In my mind, you're just leveraging that and
making it really easy for people who are just used
to using views to just be like not have to
think about it. Yeah, it's an awesome evolution in my opinion.

Speaker 4 (36:11):
Yeah, I love that comment that that comment that it's
just essentially an API.

Speaker 3 (36:15):
It is.

Speaker 4 (36:16):
The difference is with a rails or layer ofl app,
you've accepted that there is this type coupling between this
back end controller and the front end view.

Speaker 3 (36:24):
That's just an accepsolutely, you know. And you know, some people.

Speaker 4 (36:27):
Say, well, that coupling's bad because now I can't use
the sendpoint for other things, and I say, no, actually,
that coupling is awesome because one, it makes it really fast.
You can create these these applications really quickly, and you
can optimize them from a performance perspective because you're only
worrying about this one request. You're not worried about thirty
possible different permutations.

Speaker 3 (36:44):
It's just one request. That you're concerned about.

Speaker 2 (36:46):
Absolutely.

Speaker 1 (36:46):
Really, the only benefit to thinking about it that way
is when you're suddenly ready to break the rules, right,
So yeah, awesome.

Speaker 2 (36:53):
Anything else that we should know about.

Speaker 1 (36:56):
Inertia that you you're just like, haven't talked about this,
you guys?

Speaker 2 (36:59):
Yeah, thinking about this?

Speaker 3 (37:00):
Yeah?

Speaker 4 (37:01):
So yes, there's maybe a couple different things that I
think inertia does really well and stuff that I'm even
proving on is one is scroll management. So what happens
by default when you browse from one page to the next,
just using like standard normal, plain old website, and you
scroll down and you visit the next page, and then
you scroll down, you visit the next page, you know whatever,

(37:21):
and then you hit back in the browser. The browser
is smart enough to remember exactly where you were on
each one of those pages, and that helps maintain context, right,
which is a really nice thing.

Speaker 3 (37:30):
Inertia allows you to do that.

Speaker 4 (37:32):
Because that basically is for free out of the box,
if you just do a standard page. But where it
becomes tricky, and this is becoming more and more common,
is people have like essentially what are considered like scroll
areas within your UI. So one really common use case
for this is imagine you have kind of like your
standard layout. Left hand side is your navigation and the
right hand side is your content, and maybe along the

(37:53):
top you have a bar right when you scroll the content,
you maybe want to scroll the content but not have
your left hand nav change.

Speaker 3 (37:59):
Or even the other way around.

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

Speaker 3 (38:19):
So that kind of like goes out the window. What
goes out the window when you're using scroll areas like
that is scroll position management. So if you were to
do that and you would go to visit the next
page and you go back, the browser has no idea
that you were scrolled in this container down three hundred pixels.

Speaker 4 (38:33):
It's like that, don't care, not my problem. All it
cares about is restoring the body scroll position. So inertia,
we're we have support for basically automatically automatic scroll restoration
of containers as well, and you can and you don't
have to. That doesn't happen to all containers. You can
actually define on a per container basis, like inertia track
the scroll position for this, and that's like a really

(38:55):
really nice feature that you basically Yeah, so that's one thing.
Another thing that in or she does really well is
asset version ing. So this is a problem that a
lot of people run into with modern client side rendered
applications is imagine you have a user, right and they
go to your application, they go to your website, and
they click through a few different pages and while they click,

(39:15):
you know, maybe they're on the user's page, and then
when the user show page and right at that moment,
you had to fix a bug or do something in
that template and you redeployed it, so you would deployed
those assets to the server. The problem is right now
is with a typical client side rendered application is if
you now go back to visit that user index page,
because it's not doing a full page reload, there's no

(39:36):
way for the browser to know that maybe that user
index page template changed, so they're going to see the
old page template, which might be fine, or it might
not because you might be expecting data back from the
server that's now out of sync with your template. You
remember that type coupling that we're talking about between these
two things, and would be no different if you're working
with an API, if there's an expectation for the data
to be there and it's not, and that old template

(39:56):
could now generate an error the Appleic application craft simply
because you deployed.

Speaker 3 (40:01):
An update to the application.

Speaker 4 (40:02):
And this is something that rails and layerbelt developers never
have to worry about if you use some service side
render views because when you go to the new page,
it's doing a full page reload. You're getting a full page,
all the new assets, everything else. So what inertia does
is we have like and there's like there are ways
to solve this with client side like Classic viewer, React apps,
but it's complicated and they use people use service workers

(40:22):
and I'm not going to get into details of how
that gets solved, but it's kind of complicated, whereas with inertia.
What's really cool about inertia is that the front end
and the back end are coupled together. So that's like,
you know, this coupling that we keep talking about, like,
that's the real benefit because we can now let the
server and the client side frameworks, and essentially what it
is is it's a service side inertia adapter working with
a client side inertia adaptor, and they're working together to

(40:44):
make sure that things are working properly. So what happens
is every single time you make it an inertia visit,
we keep track of you know what, Let me back
up before I even go there. It might be zero
to explaining it this way. When you define your inertia
set up in Rails, you have the option on every
single page, like, you know, kind of like does it
does Rails have this concept of like some sort of

(41:05):
like base like application service provider where you do kind
of like default work. Could it like happen in like
a middleware or just like kind of like something that
gets run on every single page request?

Speaker 3 (41:14):
Is that right?

Speaker 4 (41:16):
So imagine I forget exactly how the gens who put
together the inertiative Rails adapter did this, but just imagine
that somewhere in your inertia configuration in your Rails application,
you basically say this is the version of my assets.
Your assets being your JavaScript basically could also be yours. Yeah,

(41:37):
so you you have some sort of version number that
indicates the current version of your assets.

Speaker 3 (41:43):
Like the way I do it in layer.

Speaker 4 (41:44):
Bel is I literally just do I just get an
empty five of the assets and and if it changes,
it changes.

Speaker 3 (41:50):
So what you do is you.

Speaker 4 (41:51):
Say inertia version and you pass it the current version,
and that happens on every single request. So what happens
then is that version gets past to the client side.

Speaker 3 (41:59):
So that's one.

Speaker 4 (41:59):
And so I've talked about this page object that that
gets passed around, which includes the component name and the props. Well,
another another property in that that page object is the
asset version. So the client side Inertia always knows what
the current version of your assets are. So then when
you now click from one page to the next, so
you're on the user show page and you want to

(42:19):
go to the user index page. Well, you you click
the user index page, Inertia goes off and it makes
the XHR request, the inertial inertial request to your server
to get the index page and the data for the
index page. Inertia automatically passes what it believes is a
current version two rails, then rails the rails. Inertia adapter says, okay,
I got this request coming in, it's saying that the
current asset version is one, two, three, but we can

(42:41):
see now that it's a new deploye has happened and
the new asset version that is actually four or five six.
And what Inertia does is it actually stops the request
at that point and it then gives returns a four
oh I believe it think it's a yeah it returns.
So imagine this XHR request gets an immediately immediate four
oh nine conflict response back from Rails, and then what

(43:03):
happens is Inertia gets that four h nine conflict response
back and it says, oh, assets are at a date.
So what Inertia then does is that automatically does not
an XHR request to that page. So going from the
user show page to the user index page, it's gonna
say the assets are at a date because the server
just told me that, and it just cuts that XHR
INNERSI request short and it now does an automatic full

(43:24):
page visit to the user index page. And then because
you're doing a full page visit, you have an off
the opportunity to use cash bussing to reload your assets
and you're right back in business.

Speaker 3 (43:34):
So for the end user.

Speaker 4 (43:35):
It does mean that they'll have to redownload those assets,
of course, but that's what you want because otherwise you
want to deploy them so they can continue browsing your
Inertia app like a classic SPA until the assets are
aut a date, and then they're gonna be forced without
their they won't even notice really that it's happening other
than that request will reload the whole page and it'll
look like a full page visit and you're gonna be
right back in business on the page. And we do

(43:57):
some smart things about the way we make that request,
that four nine response, and like we automatically reflash data,
so if there was any if you had any flash
data that was going to be used, it automatically reflashes that.
So even though you're doing a full page reload, you're
going to still get that flash data come available. So
that's a really, really, really cool feature of Inertia that is,
like I think it would be harder to do with

(44:19):
a classic SBA, but because of the way that the
clients side and service side adapters work together, it basically
takes all the work out of asset refreshing and asset
versioning like you Literally, all you have to do is
tell service side, tell Inertia what the current version of
the assets are, and you're done and it handles it.
Which is also really nice from a development perspective because
if you're developing, you're constantly changing your files, and inertia

(44:40):
you don't have to like constantly hit refresh.

Speaker 3 (44:41):
You can just click a link and it'll just update
automatically for you.

Speaker 1 (44:44):
No, I agree, that is super cool. I mean to
b Frank, I've been used to Rails handling asset management
to me for so long that it is frustrating every
time that I have to deal with it because I
just at this point in my development career, I just
think that I shouldn't.

Speaker 2 (44:58):
Have to deal with it because I know exactly I
literally cannot.

Speaker 1 (45:03):
I mean, shoot, we didn't even have that problem in
Rails one because we weren't serving assets on the project
that I was working on.

Speaker 2 (45:09):
So yeah, yeah, it was so long ago.

Speaker 4 (45:13):
Yeah, and there's there's some really the last thing, you so,
the last thing I want to just mention about inertia
that we kind of didn't talk about yet, and is
the fact that inertia visits are not limited to get requests,
so you can make inertia visits for post requests, put requests,
patch requests, and delete as well. And this is really
cool and it's kind of a complex thing to explain,

(45:35):
maybe on a podcast, but what it does is it
makes forms a lot more like classic Rails form submissions,
except it's all done ya xhr, and it's like it's
like the most wonderfully simple thing ever. So I'll explain
kind of how it works real briefly in layer Bell
and then you, guys, hopefully you can kind of hopefully it'll
make sense in Rails as well. So what you do

(45:56):
is if you have a form, say a view form
with all the React of inputs right, and then you
then a user presses submit to submit that data to
the form, you know, down to the server. In that situation,
you would still submit that using inertia. So what you
would have is you'd have a submit interceptor where you
prevent the default browser full page submission and then you

(46:17):
would say, so imagine we were on the create user
page right and you hit create user, hit the button,
the form submits, We catch it, and then in your jabscript,
in your view page component or in your React page
component whatever. You would then say inertia dot post if
we're creating a user yet post and you would say,
we're going to post that to slash users and passing
the data from that component. So it's just like literally

(46:38):
a one liner. But you don't then do a bunch
of work after that. You don't say, well, give me
the response back and let me inspect the response to
see if there is errors, and if there's errors, I'm
going to go and manually update the view display those errors.
And if there's no errors, well then we're going to
redirect to somewhere else. You don't do any of that.
All you say is inertia post to the user's page.
Then what happens is there's two paths. There's a happy

(46:59):
path the user created and there's the unhappy path. There
was a validation error service sidevalidation error, So do happy path. First, user,
you hit the user create page or the user store endpoint,
so that controller endpoint to store the user validation all passes,
it creates the user, and then server side in that
exit that XHR inertial request, you then just do a

(47:19):
classic redirect to wherever.

Speaker 3 (47:21):
You would have normally gone.

Speaker 4 (47:22):
You you would if it was just like a regular
standard full page application. You would just do a redirect
wherever you want that user to go after they created
the user, so maybe you send them to the user
show page at that point, right, So what you would do,
you would do the same thing with inertia. You'd literally
just say, however, in rails or in layer bel you
return a redirect to that new user's page. So then

(47:43):
that redirects going to happen in within that XHR request,
and what's going to do is it's going to go
now to that show user page, and that show user
page is gonna load. Keep in mind, this is all
happening within the initial inertia, the initial inertia post request. Okay,
so that that redirects happening, you're now landing on the
user show page and it's just given you a response,
but it knows that it was an inertial request because

(48:05):
that ex inertia header actually gets forwarded on when that
redirect happens. And then on the user show page, it
just returns because it knows it's an inertia request. It
just returns the Jason payload back, which includes the page
component name and the page data, which would be the
show user page and the user data for that page,
so that all then comes back to your create user page.

(48:29):
You know that form and Inertia automatically now dynamically swaps
out the create user page for the show user page
and passes the component. So you don't need to do
any work to like redirect the user. It just automatically
happens because you're redirecting server side. So that's the happy path.
The unhappy path is validation fails, and it essentially works
the same way. The user submits the form via post

(48:50):
inernship post that goes to the store controller endpoint, the
validation fails, and the way at least this is how
it works in layer about when the validation fails, it
automatically redirect you back to the page that you're on. So,
Lara Bell, if I go to create a user and
maybe it's missing the first name, Larva automatically does a
redirect back to the user page, but then includes some

(49:11):
flash data saying well, there was an error and here's
the error, which if you're using server side classic server
side templates, you would then take that air and repopulate
the page with your old values and display the errors. However,
with inertia, you get an Inertia response back. So what
it'll do is so redback, redirect back to the create
user page, and it will pass along all the data

(49:33):
that you would have for that page anyway. So the
create user page maybe there is no data because you're
creating a user, but it would say it's a create
user page and then it would have some data, which
is the errors that just happened. Those errors now get
passed back to inertia, and Inertia sees that we're on
the same page still, so we went to the create
post page. It failed and redirected us back to the
create user page. But now we have this bucket of
errors and what but in those errors have been provided

(49:56):
from Inertia as props, so the page component doesn't change,
so there's no swapping of the page component. So it's
you're gonna still be on the create user page, but
what it now has is the errors, and all you
do and those errors come through is props, so they
will you don't have to do any work to update
as long as you're taking as long as your page component,
your client side page components designed that anytime your page

(50:17):
create user page component is rendering any errors that come
through as a prop, it's just gonna because it's all reactive,
it's just going to automatically display those errors. So, like
I said, this is a tough thing to explain over
over a podcast, but the point is because it's all reactive,
because that's the way view and reactings felt work. When
that response comes back and has the errors, the props
come in and they automatically update, so you literally it

(50:39):
just ends up making for these really really simple forms
because you don't have to do a whole bunch of
wrangling to like figure out what the response was and
update it.

Speaker 3 (50:48):
It just kind of all happens magically.

Speaker 4 (50:50):
And because you're not doing a full page load, you're
not having to repopulate all that data that you put in,
so that whatever data they put into the form, it's
not like you're having to repopulate that because it's all
they're still because that page component wasn't.

Speaker 3 (51:01):
Destroyed, it was, it's still persistent.

Speaker 2 (51:04):
There. Does that make sense, Oh, it totally makes sense.

Speaker 1 (51:06):
I think it's I think it's very close to what
what we would have in Rails, right because.

Speaker 4 (51:10):
Rails doesn't magic with that stuff, right, Like it kind
of like adds some stuff to your form, some JavaScript
stuff already.

Speaker 1 (51:16):
Right, well, I mean if you have rails, not not
really so the way that it would Okay, So if
I just had vanilla Rails, right, I would submit my
form right, happy path would redirect me to like a
show page or an index page maybe the failed path,
you know, I would come back and what would probably
happen is validation. Things that weren't there before would now

(51:37):
suddenly be there because Rails is going to render that template,
and Rails is going to conditionally now render some new things.

Speaker 2 (51:43):
Kind of depends on maybe what gems you have.

Speaker 1 (51:45):
Installed other things like that, but that's that's usually going
to be what it is.

Speaker 2 (51:49):
Yeah, but yeah, it makes it really close. It's really close. Yeah.

Speaker 3 (51:51):
Well that's good.

Speaker 2 (51:52):
Yeah, so awesome.

Speaker 1 (51:54):
I mean yeah, I think I think the basic gist
here that I'm understanding is that inertia is going to
make it pretty easy for me as a rail developer
to say, you know what, I have this maybe legacy
application or something like. I'm seeing a lot of use
cases with already existing applications where I then want to
sprinkle some view or some react or something on a

(52:15):
page or two and have it be a little bit
of a spa there for a little while. That's kind
of what I'm seeing the major use case with rails
B there. I mean, I guess you could design this
with this in mine too. I don't see anything wrong
with that.

Speaker 4 (52:26):
Yeah, that's what most people are doing. People are upgrading
like existing apps to use inertia. But like most people
are using it there. It's kind of like greenfield projects
at this point. But that's also because it's a pretty
new project.

Speaker 1 (52:37):
Yeah, excitement things like that also, always playing to this stuff. Yeah,
any any other questions from you, Luke before we kind
of roll into picks here?

Speaker 5 (52:44):
Do we want to tool amount gate, hubs, bumster shit?

Speaker 2 (52:47):
Sure? Why not?

Speaker 5 (52:48):
So?

Speaker 1 (52:49):
In the notes that you sent us, John Nathan, you
said that you had started to get hub sponsorship campaign.
You want to talk a little bit about that before
we get wrong?

Speaker 3 (52:55):
Yeah, sure, that's cool.

Speaker 4 (52:56):
I was just trying to think of interesting things that
might be fun talking about. That's kind of a of
a newer thing, is so this. You know, I've been
working I've been doing open source for a long long time,
and it's always a challenge working an open source you know,
justifying spending time, and if you're running a business and
if you have a family and life's busy, it's difficult
to justify committing large, large chunks of time to open

(53:17):
source just strictly from a business or.

Speaker 3 (53:19):
You know, personal time management perspective.

Speaker 4 (53:21):
And so the what I did with Inertia when gethub
sponsorships came out, I said, you know what, this is
a project that I think has legs for the long term,
and this is something I want to work on. But
I've seen how much work tailwind CSS took and what
it takes to make a really really successful project, open
source project, and I thought, you know, I want to
try to monetize it in some way to help me

(53:42):
justify spending a bit of time on this thing. So
I put out the GitHub sponsorships and it was really
I totally didn't expect much of a response, but I
got over fifty over fifty sponsors, which is, you know,
not an enormous amount of money, but it's you know,
upwards about you know, one thousand dollars a month.

Speaker 3 (53:57):
Which was double.

Speaker 4 (53:58):
So it was like two thousand dollars a month for
getthub for a while, which was awesome.

Speaker 3 (54:02):
I think that's just I didn't know what to think
of the GitHub sponsorship stuff at first.

Speaker 4 (54:05):
I'm like, are people actually gonna help contribute out of
their own pockets toward open source? And obviously Gethub believe
that that would happen, and and now you know, it's
it's crazy what some people are able to do with
their GitHub sponsors. And it's there's some people working on
open source full time making making a lot more money
than that on their GitHub sponsors, which I think, honestly

(54:25):
is a really really cool thing for open source. It
kind of just it's it's recognizing the amount of time
and effort it takes for for people to work on
open source and build quality software that you know, it's
crazy at the amount of at least for me, I've
I've always worked in the layer vel, PHP space, like
it's it's all free software, right and this is what
we're using to run our businesses and everything else. And

(54:46):
to me, it only makes sense that some of that
money goes back, if nothing else, to just help people
spend business hours on open source and not have to
feel like they're they're losing money or you know, running
the issues with their boss because they feel bad working
on a during work hours or whatever.

Speaker 1 (55:00):
You know, I think it's pretty cool too. I I
do not think it's the end all be all, because
I think there's a limit right to if programmers are
the only people contributing to open source, like there's we're
just not going to have enough money in open source.
But I do think it's a definitely piece.

Speaker 2 (55:12):
Of the puzzle. I'm pretty so pleased with it myself.

Speaker 3 (55:15):
Yeah, yeah, I touly agree with that sentiment.

Speaker 2 (55:17):
Yeah, awesome. Well, I'm glad that you are able to
get some people to support you. So let's I guess
before we move into picks, if people.

Speaker 1 (55:23):
Want to like get a hold of you, follow you
things like that, how do you recommend they do that?

Speaker 4 (55:27):
Yeah, So I'm active on Twitter. That's kind of like
the go to place. Just my last name renik ari
e I n I n K on Twitter, and I
talk about you know, all kinds of inertia and database
and layer bell stuff there. So you're interested follow me there,
and then my website reanik so same same handle, Renick
ari I n I n K dot ca A. I

(55:48):
blog on there, and yeah, and then obviously inertia if
you if you google inertia JS you'll find inertiajs dot
com if you want to learn more about that project.

Speaker 2 (55:56):
Awesome.

Speaker 1 (55:56):
Well, we'll make sure that those links are in the
show notes too. So sweet, let's go and move on
into picks. Luke, do you have any picks for us
this week?

Speaker 5 (56:04):
My word, do I have a pick for you? This week?
We were recently unlucky enough to lose our server developer
who has been building our Kubernetes stack for us, and
this means that I've been spending the whole week doing Kubernetes,
non stop, non stop Kubernetes this week. I have had
used it before, back in twenty eighteen, but the Kubernetes

(56:29):
is in a bit of a state of flux at
the moment, so coming back to it, especially if you're
kind of running on Google Kubernetes engine or something's been
a lot of changes. So my pick for this week
is a book on Kubernetes. It's by another Englishman, the
English it Mathia coming in here, and it's called imaginatively enough,

(56:50):
the Kubernettes Book. It was updated in February twenty twenty
and it's been very helpful getting up the speed with
the Kubernetes.

Speaker 2 (57:00):
Any other picks for us? Is that you're Is that
it for us? That's it.

Speaker 5 (57:03):
I'm not going to pick Kubernettes itself. Make of that
what you will.

Speaker 2 (57:08):
That's fair.

Speaker 1 (57:08):
I'd have to push chaplaine if if you did, I
feel like anything to make it easier.

Speaker 5 (57:13):
Do you know what we got? We've got time for
a quick rant. Here we go. Cubernettes. Right, you're learning
a Cubernettes, you think. Right, I've got my book, I've
got my my my Docker desktop. I'm going to go
into settings and tick tick the box. I've got a
requirement for Windows, so doing all the windows. And I
say to I say to docer desktop, make me a
Kubernettes cluster.

Speaker 2 (57:33):
Yes.

Speaker 5 (57:33):
Would you like to guess how much RAM this uses
on my desktop machine? It's to take a wild guess
how much this ticking this little box costs me?

Speaker 2 (57:42):
All of it?

Speaker 5 (57:42):
It's free gigabytes of RAM. And I haven't I haven't
made any pods yet. I haven't. I haven't run my app.
It's just sitting there. It's eating free. It's the first
time this machine's cracked ten gig there's two sticks of
raminist scene and this is the first time the second
ones had to wake up.

Speaker 2 (58:02):
Yeah, that makes sense.

Speaker 1 (58:03):
The typical Kubernetes closter right cluster is you have a
box that's just running Kubernetes right. All the other stuff
comes later right after that box. I wonder if if
your little ticked box right there is just spinning up
the Kubernetes sort.

Speaker 5 (58:16):
Of yeah, ground stuff. Yeah, I found a box. You
can see what it's doing. But I mean the plus side,
keep it positive. The the the interface, the a p
I is quite nice, not perfect, but there's some there's
some things to like. The declaratives all good, but that's
that's been around for a while. The the the language

(58:40):
of it is nice and clean, so there's there's some
good signs.

Speaker 4 (58:43):
I'm a little confused though, I thought all rails developers
used Roku.

Speaker 3 (58:47):
So why are you even on Kubernetes.

Speaker 2 (58:52):
I know, I know that there's lots of people that
don't doing around. I haven't.

Speaker 1 (58:56):
I've always been I've always been very devaps like personally
and and things like that, and so like, I don't
because I don't get a lot of value at it personally.
But if you don't, if you're not really into that,
I can totally see that just a.

Speaker 4 (59:08):
Little joke because I know, I know that that's kind
of like a big part of Roku's background, right, A
lot of I think.

Speaker 1 (59:13):
So, yeah, they came from our community. So yeah, it's
least that's my understanding. Yeah, yeah, no, they're not bad.
Just I'm not using though. Okay, I guess guess it's
on me now. So the first thing that I'm picking
today is we grew tomato plants, like we do every year,
So yesterday, our tomato plants have been producing for like
a bottom month, and the average amount that I'm bringing

(59:35):
in is a bowl fowl. It's like about, you know,
ten or twelve inches big and like six inches deep.
Like we have like I don't know, like six or
seven tomato plants and they go nuts. And it all
is because we basically watched some YouTube videos on like
how to like prune them and not like kill them
and all these things, and so I'll paste them. I'll

(59:56):
paste them in here. So if you're like totally, there's
probably more stuff out there, probably somebody that knows how
to take care of other kinds of plants, but I'm
definitely like pushing the watch some YouTube videos. If you're
if you're doing like some home gardening things, you know,
especially if you're like growing stuff, because it's like COVID
and everybody seems to be into.

Speaker 2 (01:00:13):
That this year.

Speaker 1 (01:00:13):
Maybe it's a little late for you because maybe you're
growing seasons past, but definitely for if you keep doing
it next year. So gardening videos awesome. The other thing
that I was that I wanted to plug here so
earlier in the session, Luke was like, Hey, I don't
want to have to go to my logs too for
queries and stuff.

Speaker 2 (01:00:32):
Well I did some looking during Well.

Speaker 5 (01:00:34):
I'll tell you why. I could reveal why now because
but blasted apps and kubernettes and you can't get at
the thing.

Speaker 1 (01:00:39):
Okay, maybe what I should give you is a link
to tutorial on how to read logs and kubernetes, because
that that I think is your actual problem. Then all right,
But I actually I couldn't find a gem that did that.
But I did find some pretty sweet gems that give
you all sorts of extra query debugging tracing to the
exact spot in your code explaining, So I'll just like

(01:01:02):
those because they were cool anyway.

Speaker 2 (01:01:04):
So yep, those are my picks. Jonathan, did you have
anything for us.

Speaker 4 (01:01:07):
Yeah, I didn't have anything at the beginning, but it
kind of as you guys were talking, I've come up
with three. One of them is, as I've mentioned earlier,
project that I was involved with is called Tailwind CSS,
and this is a kind of a unique approach to
building and a unique approach to CSS and building applications
that I would highly recommend to your audience to check out.
It's become really really popular and it's honestly changed the

(01:01:29):
way that I handled CSS. I pretty much don'trite CSS
anymore because I'm using Tailwind, which is If that's confusing
to you, then it's you should definitely check it out.
And I will warn you if you've come from like
a SAS or a less background or just even just
plain old CSS and you look at this approach, you
will probably be disgusted at first, but it is really
really great. Give it a chance, and I pretty much

(01:01:51):
guarantee you you'll be making webuis faster than you were before.
And the maintenance is wonderful moving forward because it's just
a lot easier to manage because it's all in HTML
and not in CSS.

Speaker 3 (01:02:02):
So pick number one, tail in CSS. Pick number two is.

Speaker 4 (01:02:06):
I mentioned earlier that I put out a database course.
Now I should mention that this course was primarily primarily
designed for layveel developers.

Speaker 3 (01:02:15):
Well totally designed.

Speaker 4 (01:02:16):
For layravel developed developers, but there is a lot of
crossover between larravels or m which is called Eloquent and
active record in rails.

Speaker 3 (01:02:24):
So there's some interesting techniques.

Speaker 4 (01:02:26):
So if you are a layerbel developer listening to this,
or just even a rails developer who wants to learn
some techniques about databases and how to make your databases
your database queries faster, check out my course eloquentdas course
dot renik dot CA, which I'm assuming we'll end up
in the notes. So yeah, So that's my second pick,
and my third one is less software related. But I

(01:02:48):
live on a farm and this week I so a
little bit of a background. I live on a farm,
so I wireless at Internet, which basically means that I
have an antenna on my property that points to another
antenna about two kilometers away from this Internet service provider.
And this year, the tree line between us and the
tower that we point to is like really growing in.
The trees are really grown in, the leaves are really

(01:03:10):
grown in and our internet's getting more and more unstable.
So I've been pricing out some new hardware because it
turns out that if I move my antenna about one
hundred meters south of where my house is right now,
which is out in basically the middle of my field
of a small, little fifty acre property, so we have
a bit of land, so I have the flexibility to.

Speaker 3 (01:03:26):
Move the tower.

Speaker 4 (01:03:27):
I get perfect line of vision to this tower. But
the problem is I have to then get it from
there to my house and my barn as well. So
I've been playing around and been researching a bunch of
ubiquity products, and if you are in the similar sort
of position as me, I can't recommend this stuff enough.
It's so cool. I've been playing around with a product
called the Nanobeam, which are these like they're really like

(01:03:48):
they're small little things or maybe like they're circular, maybe
six or seven inches wide, and they're rated for fifteen
I think fifteen to twenty kilometers, Like I only need
it for like three hundred meters or something, and it
just makes it really really easy to create these wireless
connections between like long range wireless connections between different places
of my property. So whatever, I'm just kind of nerding

(01:04:09):
out on the Ubiquity products right now.

Speaker 2 (01:04:11):
Because I'll give you a plus.

Speaker 3 (01:04:12):
Yeah you've worked with them before.

Speaker 1 (01:04:14):
Yeah, So my a job that I had like over
a decade ago. One of the things that we did
is we broadcast auctions and a lot of the barns
that these auctions would be done and they didn't have
good Internet connections and so we were using wireless equipment
all the time and we swore by this by Ubiquity.
So just just saying that was ten years ago. But
as far as I know, like you know, good stuff, it's.

Speaker 3 (01:04:36):
It's pretty cool stuff.

Speaker 4 (01:04:37):
I actually have one already set up on my property
between two spots and we actually had a wire like
a buried wire under the ground and it gave us
all kinds of trouble. And then we put in a
couple of nanobeams and it's just like it's it's almost
like they are wired, because that's what it looks like
from a network perspective, and they just they just work flawlessly.

Speaker 3 (01:04:54):
So that's my picks.

Speaker 1 (01:04:55):
Awesome alrighty, well, thanks everybody for joining us, and we'll
see you again.

Speaker 2 (01:04:59):
Another that

All Episodes

Inertia.js - The Modern Monolith with Jonathan Reinink - RUBY 659

Episode Transcript

Popular Podcasts

Stuff You Should Know

My Favorite Murder with Karen Kilgariff and Georgia Hardstark

The Joe Rogan Experience

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}Inertia.js - The Modern Monolith with Jonathan Reinink - RUBY 659