WEBVTT

1
00:00:05.639 --> 00:00:10.519
Hey, welcome back to another episode
of the Ruby Rogues podcast. This week,

2
00:00:10.519 --> 00:00:15.119
on our panel, we have Valentino
Stole. Hey. Now, I'm

3
00:00:15.199 --> 00:00:19.399
Charles Maxwood from Top Endevs. We
already have people coming in on the live

4
00:00:19.440 --> 00:00:23.160
stream, which is awesome. I
think they're all coming in on Twitter.

5
00:00:24.079 --> 00:00:29.280
We have a special guest this week
that is Stephen marg I'm Steven. Welcome

6
00:00:29.280 --> 00:00:33.240
to the show. Do you want
to introduce yourself for real quick? Yes?

7
00:00:33.320 --> 00:00:36.079
Thank you for having me. As
you said, my name is Stephen.

8
00:00:36.320 --> 00:00:40.960
I am living here in Berlin,
Germany, though I am originally American.

9
00:00:42.640 --> 00:00:48.000
Just gotten married earlier this month.
I saw that on Instagram. Congratulations.

10
00:00:48.119 --> 00:00:53.039
Yeah, thank you and excited to
be here and talk about sequel light

11
00:00:53.159 --> 00:01:00.200
and Rails. Very cool. So
where do we start. I'm just going

12
00:01:00.240 --> 00:01:04.480
to give a little bit of context
because I mean, I've used sql light,

13
00:01:06.480 --> 00:01:10.480
but I mean everything I do I
do on Postgress. I think most

14
00:01:10.719 --> 00:01:15.599
Rails developers go that way, but
I think seql light is also the default

15
00:01:15.640 --> 00:01:18.519
if you start a new Rails project, or at least it used to be.

16
00:01:19.599 --> 00:01:23.879
Anymore, I just tell it no, I want Postgress. So yeah,

17
00:01:25.079 --> 00:01:30.200
if you know you're talking about seql
Light, like it's a serious database

18
00:01:30.120 --> 00:01:36.239
on Twitter. I know, weird, right, I know. I couldn't

19
00:01:36.239 --> 00:01:38.000
think of a better way to put
it. But the way you talk about

20
00:01:38.040 --> 00:01:41.079
it and the way we talked about
it on the Ruby Dev Summit, it

21
00:01:41.120 --> 00:01:45.239
made it. You made it sound
like you could honestly use this in other

22
00:01:45.280 --> 00:01:49.959
places. And I've heard other people
being interviewed. I think somebody from Planet

23
00:01:49.959 --> 00:01:57.519
Scale or one of the Internet hosted
databases was talking about how sequal light is

24
00:01:57.560 --> 00:02:02.640
the real deal now to not just
my SQL or Postgress. So yeah,

25
00:02:02.840 --> 00:02:10.159
is it the real deal and why
change our minds? M Well, it

26
00:02:10.360 --> 00:02:16.560
is the real deal. But like
with any database, and this is I

27
00:02:16.560 --> 00:02:27.479
think the key point, there are
trade offs. So at like a very

28
00:02:27.759 --> 00:02:30.639
high level, just my sort of
sense of things, right, Like,

29
00:02:30.800 --> 00:02:38.439
Postgress is great because it comes with
a lot of functionality out of the box,

30
00:02:38.080 --> 00:02:46.680
and it has a really rich community
of developers and set of extensions.

31
00:02:46.719 --> 00:02:50.400
So you want to be doing stuff
with vector databases. You've got pg vector,

32
00:02:50.479 --> 00:02:57.000
you can plug that into your Postgress
database. But compare that with my

33
00:02:57.120 --> 00:03:02.479
sequel and the v tests sort of
layer that can be put on top of

34
00:03:02.520 --> 00:03:07.360
that, and the scaling that has
been done in the last two decades on

35
00:03:07.400 --> 00:03:15.280
my sequel, there aren't the same
sort of solutions that are as battle tested

36
00:03:17.599 --> 00:03:23.400
at the same level of scale for
POSTCRIS right, so something like planet scale,

37
00:03:23.599 --> 00:03:29.599
which is sitting on top of the
test is a relatively unique offering for

38
00:03:29.759 --> 00:03:38.639
my SQL. And then sqlight has
I think a unique sort of value proposition

39
00:03:39.879 --> 00:03:46.520
because it offers you, like the
full range of sequel, Like there's really

40
00:03:46.879 --> 00:03:51.680
nothing that you need to do with
SQL, the language that sqlight doesn't offer,

41
00:03:53.479 --> 00:03:59.400
you can if you want to run
it in a client server architecture.

42
00:04:00.599 --> 00:04:04.879
The libseql project, which is a
fork of the cql I codebase by the

43
00:04:04.919 --> 00:04:12.199
Turso guys, and the platform that
they are building on top of that is

44
00:04:12.240 --> 00:04:18.480
like breaking the client server architecture on
top of seqlite for edge computing. But

45
00:04:19.199 --> 00:04:25.800
you have the option, which is
unique with SQL ie right to run it

46
00:04:26.160 --> 00:04:35.360
on your application server machine right next
to your rails process and just simply remove

47
00:04:35.759 --> 00:04:46.279
network latency as a consideration. And
I think that the major shift that has

48
00:04:46.319 --> 00:04:55.800
been happening in web development lately has
been a growing recognition that seqal light is

49
00:04:56.079 --> 00:05:04.199
production grade software for web applications,
with the caveat that you do have to

50
00:05:04.680 --> 00:05:11.959
configure it to be ready to use
for web applications. And where I think

51
00:05:12.040 --> 00:05:15.839
there has been this odd disconnect is
that there's been the sense that like,

52
00:05:15.879 --> 00:05:23.879
oh yeah, postcress my sequel these
are obviously web application databases. Just get

53
00:05:23.920 --> 00:05:26.920
them up and you're ready to go. But of course you have to configure

54
00:05:26.920 --> 00:05:31.399
those as well, Like there isn't
really a database that is completely blind,

55
00:05:31.480 --> 00:05:40.279
plug and play. And as people
have started lowering that barrier to entry and

56
00:05:40.360 --> 00:05:44.720
just started to demonstrate, hey,
there is a lot of power here,

57
00:05:44.759 --> 00:05:48.480
there's a lot of flexibility here.
This is a model for building and deploying

58
00:05:48.480 --> 00:05:56.920
applications that offers some unique value adds, whether it's to developer experience or to

59
00:05:57.000 --> 00:06:02.759
performance, or to simplicity of deployment. And it I think it really is

60
00:06:02.839 --> 00:06:11.120
just a question of education around what
it takes to get a robust, resilient,

61
00:06:11.720 --> 00:06:17.360
production grade deployment of an application backed
by Sequelite out into the world.

62
00:06:17.519 --> 00:06:23.439
And that education has been growing in
the last couple of years. So yes,

63
00:06:23.600 --> 00:06:29.959
it is the real deal. So
I want you said production grade like

64
00:06:30.680 --> 00:06:32.920
twelve times. I wasn't counting.
I'm just throwing the number out there.

65
00:06:32.920 --> 00:06:40.959
But what do you mean by production
grade. Yeah, So I think that

66
00:06:41.120 --> 00:06:47.480
there have been three major barriers to
using Sequelite out of the box in a

67
00:06:47.519 --> 00:06:53.800
web application, and I think it
has led to the sense that Seqlite isn't

68
00:06:53.800 --> 00:07:01.000
production grade. So the first barrier
is concurrency. So everyone who has read

69
00:07:01.079 --> 00:07:05.360
even a little bit about using c
qlite for a web application will very quickly

70
00:07:05.360 --> 00:07:11.959
come across people claiming, hey,
you absolutely could never use this for a

71
00:07:12.000 --> 00:07:17.879
web application, because in order to
have a web server that can deal with

72
00:07:18.480 --> 00:07:25.839
even just a reasonable amount of requests
coming in, you're going to take advantage

73
00:07:25.879 --> 00:07:32.759
of the stateless stature of HCTP and
deal with multiple web requests concurrently with your

74
00:07:33.040 --> 00:07:42.839
application process. But Sequelite running on
that same machine is going to linearize your

75
00:07:43.120 --> 00:07:46.319
interactions with the database. And by
default, if you don't touch anything,

76
00:07:46.399 --> 00:07:56.360
you're using the original model that they
have for ensuring transactionality. You're going to

77
00:07:56.439 --> 00:08:01.079
have linear operations, whether there reads
or write. If you want to do

78
00:08:01.160 --> 00:08:03.759
anything, you do them one at
a time. So the fact that you

79
00:08:03.839 --> 00:08:11.319
have concurrent web requests is negated.
You everything bottlenecks at your database, and

80
00:08:11.360 --> 00:08:16.720
people say, of course that's never
going to scale. Now there are two

81
00:08:16.759 --> 00:08:20.519
key points to make on this barrier. The first one is people really too

82
00:08:20.639 --> 00:08:28.240
quickly forget to do like the basic
math on if you remove latency and you

83
00:08:28.279 --> 00:08:35.799
give yourself some head from so you
go from talking to a postcos database over

84
00:08:37.639 --> 00:08:43.840
a web connection which can take some
number of milliseconds, to talking directly in

85
00:08:43.919 --> 00:08:48.639
process to seq light, which can
take some number of microseconds. You have

86
00:08:48.320 --> 00:08:54.399
ten, one hundred up to one
thousand more opportunities to do things right when

87
00:08:54.440 --> 00:09:00.440
you move from milliseconds to microseconds.
So even as you linearize things dealing with

88
00:09:00.440 --> 00:09:05.360
different orders of magnitude of latency,
and that gives you possibilities. And then

89
00:09:05.399 --> 00:09:13.279
the second one is that you can
configure sequlite to have concurrent reads, but

90
00:09:13.480 --> 00:09:16.840
as of now there is no way
to get concurrent rights. So out of

91
00:09:16.879 --> 00:09:24.759
the box, sequlite is linear operations. Web applications tend to deal with concurrent

92
00:09:24.799 --> 00:09:28.720
operations, and people think, well, that's a hard a hard no,

93
00:09:30.039 --> 00:09:35.279
but it isn't. That's barrier one, barrier two, and I'll just stop

94
00:09:35.279 --> 00:09:39.720
at barrier two is the main one
or these are the main two? Would

95
00:09:39.720 --> 00:09:45.240
be around backups, right, People
are like, hey, this is ridiculous.

96
00:09:45.320 --> 00:09:48.960
If you want to have something that's
like key money on the internet,

97
00:09:50.159 --> 00:09:54.679
or is in some way trying to
be valuable, you need to make sure

98
00:09:54.720 --> 00:09:58.519
that it's resilient. Something happens.
We know how the world is. The

99
00:10:00.240 --> 00:10:05.639
can get unplugged, or storms come
in. Who knows what. If you

100
00:10:05.679 --> 00:10:09.399
have everything running on one machine,
including your persistent data, and that machine

101
00:10:09.399 --> 00:10:15.840
goes down and your persistent data is
now gone, well, it's easy to

102
00:10:15.879 --> 00:10:18.919
spin up a new machine in a
new application process, not so easy to

103
00:10:18.000 --> 00:10:24.080
recover lost data. So the fact
that seqlight is on that same machine that

104
00:10:24.120 --> 00:10:31.519
you don't have network latency is a
vulnerability for persisting your data and keeping your

105
00:10:31.559 --> 00:10:37.879
system resilient to system failures. And
in the last couple of years, there

106
00:10:37.919 --> 00:10:46.080
have been a number of tools that
have been built to back up seqallied databases

107
00:10:46.120 --> 00:10:50.360
to some other place and to make
it easy to take those backups and spin

108
00:10:50.480 --> 00:10:54.879
up a new instance of that database
somewhere else. Probably the most well known

109
00:10:54.919 --> 00:10:58.799
one now, the one that I
have used the most is a project called

110
00:10:58.879 --> 00:11:05.200
light stream, which just streams rights
to your sql ie database to an S

111
00:11:05.240 --> 00:11:09.360
three bucket or really any S three
compatible bucket service, and has a very

112
00:11:09.399 --> 00:11:13.519
simple CLI. You can just pull
it back down onto any machine. So

113
00:11:15.320 --> 00:11:18.919
when I say production grade, I
tend to mean these kinds of ideas where

114
00:11:18.919 --> 00:11:22.120
people think about like, sure,
I can do this like quick script on

115
00:11:22.159 --> 00:11:26.639
my laptop, and it's nice to
have some quasi persistent storage. But if

116
00:11:26.639 --> 00:11:28.919
I'm trying to build a business,
if I'm trying to build a SaaS,

117
00:11:28.919 --> 00:11:33.360
if I'm trying to build an application
that I want to have some meaningful presence

118
00:11:33.399 --> 00:11:39.039
on the Internet, I'm going to
need to have the ability to handle concurrent

119
00:11:39.080 --> 00:11:41.240
web requests. I'm going to need
to have the ability to spin up new

120
00:11:41.960 --> 00:11:48.399
web servers with my application and keep
my data persistent across them. And there

121
00:11:48.480 --> 00:11:54.080
wasn't always a clear story for how
simple or easy or possible that was to

122
00:11:54.120 --> 00:11:58.000
do a SQL, and that story
is being written much more clearly now.

123
00:11:58.320 --> 00:12:01.720
First of all, you have a
great serious blog series that we should link

124
00:12:01.759 --> 00:12:05.919
to on uh, you know,
successful usage of sequel light in rails and

125
00:12:05.960 --> 00:12:11.480
configuration and performance metrics and all kinds
of great stuff that I think people should

126
00:12:11.480 --> 00:12:18.440
read and dive into. And I
guess, like my biggest you know,

127
00:12:18.080 --> 00:12:22.240
I've been on the same boat of
incorrectly thinking for the longest time that sequel

128
00:12:22.279 --> 00:12:26.519
light is not performant, and oh
like don't use in production, but you

129
00:12:26.519 --> 00:12:30.919
know, sure in development or whatever, you know, testing or you know,

130
00:12:31.080 --> 00:12:33.399
even just like small like hobby apps, sure it could be. You

131
00:12:33.399 --> 00:12:37.600
know, fine, but once you
get above a certain level or scale or

132
00:12:37.679 --> 00:12:41.399
whatever it may be, then it, you know, don't use it.

133
00:12:43.480 --> 00:12:48.159
And I'm sure I don't. I'm
not alone thinking this, right all.

134
00:12:48.360 --> 00:12:52.679
So, right, and so you
do shed quite a lot of light on

135
00:12:52.320 --> 00:12:58.919
you know, Okay, there's a
lot of butts in a lot of those

136
00:12:58.279 --> 00:13:03.679
you know, ways of thinking,
and I definitely agree with you there,

137
00:13:03.799 --> 00:13:07.320
and I'm kind of curious, like
to get some further insight there on well,

138
00:13:07.360 --> 00:13:13.320
like what are the limitations? Right? Like, well, what point

139
00:13:13.399 --> 00:13:16.720
do you hit SEQL light and then
it no longer worked for your app?

140
00:13:16.799 --> 00:13:20.519
Right? Because I think that's where
a lot of people are still hesitant to

141
00:13:20.600 --> 00:13:24.159
dive into it because they still don't
know what that barrier is. And then

142
00:13:24.200 --> 00:13:28.039
you it's one of those things where
okay, you don't know it till you

143
00:13:28.120 --> 00:13:31.240
know it, and then it's too
late and then you're trying to scramble to

144
00:13:31.279 --> 00:13:35.440
find another solution. Right, So, like what are those things right?

145
00:13:35.440 --> 00:13:39.120
Like what should you be looking out
for to know if sql light is the

146
00:13:39.200 --> 00:13:46.639
right option for you. Yeah,
it's a good question. It's the question

147
00:13:46.679 --> 00:13:54.960
I get most often. And there
are a few different angles to take on

148
00:13:54.960 --> 00:14:11.039
an answer. One of them is
where are you comfortable in investing your right

149
00:14:11.120 --> 00:14:16.960
So if you're someone who has you're
trying to start up a side project,

150
00:14:16.039 --> 00:14:22.600
you're you're hoping to get some money
with it or just sort of do something

151
00:14:22.879 --> 00:14:28.440
of interest and value, and you
have a decade of experience with Postcrest and

152
00:14:30.879 --> 00:14:37.399
really feel comfortable, like with the
path two, evolving a system over time

153
00:14:37.480 --> 00:14:48.679
with postgris, you know, just
stick with them. These days, it's

154
00:14:48.080 --> 00:14:54.000
there's really not actually a lot of
limitations with sequel I. So here's here's

155
00:14:54.039 --> 00:14:58.279
like the first big one that used
to be more of a limitation. Right,

156
00:14:58.399 --> 00:15:03.679
So there's a major difference between seqlight
and postcress, my sqel Oracle,

157
00:15:03.799 --> 00:15:11.039
like pick any of the others.
Most database engines follow the client server architecture.

158
00:15:11.080 --> 00:15:16.639
So it's like you have you minimally
have two different processes, and most

159
00:15:16.679 --> 00:15:20.919
of the time you have two different
machines. You've got a machine running your

160
00:15:20.960 --> 00:15:28.240
application, you've got a machine running
your database, and you most often I

161
00:15:28.279 --> 00:15:31.799
have multiple clients, have multiple machines
running application in one machine running your database,

162
00:15:33.519 --> 00:15:39.279
and you talk to your database through
web requests, and there are like

163
00:15:39.720 --> 00:15:45.720
there's been decades and decades of exploration, are like different ways to scale that

164
00:15:45.799 --> 00:15:50.679
kind of architecture, to make that
kind of architecture resilient. And when you

165
00:15:50.720 --> 00:15:56.279
go from an embedded database, there's
one machine, there's one process. Everything

166
00:15:56.320 --> 00:16:02.799
is just happening right there too.
You know, something like get Hub scale,

167
00:16:02.840 --> 00:16:10.399
Shopify scale, like there's no vertical
scaling, will never be able to

168
00:16:10.399 --> 00:16:14.399
handle that. You're going to have
to horizontally scale. So then how do

169
00:16:14.440 --> 00:16:21.000
you horizontally scale in your database is
living on each machine? That was a

170
00:16:21.000 --> 00:16:23.360
problem, that has been a problem
for a long time, and so I

171
00:16:23.440 --> 00:16:29.600
have said, you know, if
you are starting a project, and the

172
00:16:29.639 --> 00:16:32.559
way that it succeeds is it gets
to that scale, right Like if you

173
00:16:32.600 --> 00:16:37.559
go and get venture money, you
probably should have chosen my SQL from day

174
00:16:37.559 --> 00:16:42.240
one, right, Like you're shooting
for planet scale, not TM from day

175
00:16:42.279 --> 00:16:51.519
one. But that's actually not even
a technical limitation anymore. So, whether

176
00:16:51.600 --> 00:16:59.200
it is the predecessor to the light
Stream project light FS from Ben Jonson at

177
00:16:59.200 --> 00:17:08.039
fly Io, which is a tool
to have a replicated logical database spread across

178
00:17:08.200 --> 00:17:15.839
multiple machines Sequlite database obviously, or
whether you're using a platform like Turso,

179
00:17:17.880 --> 00:17:22.319
which, as I said, like
brings that client server architecture but also allows

180
00:17:22.359 --> 00:17:26.200
you to have read replicas on each
of your machines and it'll you know,

181
00:17:26.440 --> 00:17:33.799
manage consistency for you. Like there
are now and there are others. There

182
00:17:33.839 --> 00:17:37.480
are multiple tools now to allow you
to horizontally scale the sequel lie database.

183
00:17:38.200 --> 00:17:48.640
So is is that particular scaling path
as battle tested as like the test on

184
00:17:48.680 --> 00:17:52.680
my sequel. No, it's not
been around for two decades. You don't

185
00:17:52.720 --> 00:17:56.000
have a company like YouTube that's running
it. So again it goes back to

186
00:17:56.039 --> 00:18:02.359
like your your risk profile. If
you think, on day one, I

187
00:18:02.400 --> 00:18:06.799
really want to be at that scale, you probably should just use my sql

188
00:18:06.880 --> 00:18:11.880
env tests, right because the why
take the risk if you know that's where

189
00:18:11.880 --> 00:18:18.119
you're going. But for someone who
is like unsure of what the future looks

190
00:18:18.160 --> 00:18:21.920
like, I really do think that
there are so many wins that you get

191
00:18:22.559 --> 00:18:27.160
on day one and week one and
year one with the developer experience and the

192
00:18:27.200 --> 00:18:33.839
performance characteristics and the power and simplicity
of like leaning into vertical scaling for as

193
00:18:33.839 --> 00:18:41.400
far as that'll take you, that
you should really give SQL a long look

194
00:18:41.960 --> 00:18:47.079
and you can really fall back on
the security be like, if you really

195
00:18:47.119 --> 00:18:52.240
do get very successful successful such that
like vertical scaling can't work for you anymore,

196
00:18:53.160 --> 00:19:00.920
you don't have to change databases necessarily. But the other thing that's true

197
00:19:00.960 --> 00:19:03.880
is like, if you do get
to that scale, you're probably making money,

198
00:19:04.400 --> 00:19:10.759
and probably good money, and at
that point you probably could change databases

199
00:19:10.759 --> 00:19:18.720
if you want to. And going
from a sequelite schema, which is you

200
00:19:18.759 --> 00:19:22.799
know it's going to be a looser
schema typically two postcress for my sqel,

201
00:19:22.960 --> 00:19:29.680
I think it is generally easier than
the reverse direction. So I talked around

202
00:19:29.759 --> 00:19:32.599
your answer. The short answer is
I really can't think of like really hard

203
00:19:32.680 --> 00:19:36.079
limits, to be perfectly honest with
you, but I do think that there

204
00:19:36.119 --> 00:19:40.079
are different risk profiles and there are
different reasons why you might or might not

205
00:19:40.359 --> 00:19:45.720
choose to use it. But like
as of today, well, okay,

206
00:19:45.880 --> 00:19:49.279
I say that, of course I
should stay out loud. There is the

207
00:19:49.319 --> 00:19:55.279
one key limitation, right which is
if you have like massive right through but

208
00:19:55.440 --> 00:19:59.400
if you're building an analytics platform to
compete with Google Analytics, and you're just

209
00:19:59.440 --> 00:20:03.119
going to get like the core of
your businesses, you need to deal with

210
00:20:03.319 --> 00:20:14.000
massive amounts of rights. Don't choose
sequal Light today. That would be a

211
00:20:14.000 --> 00:20:19.359
hard limitation. They are working on
concurrent rights, so that limitation might not

212
00:20:19.400 --> 00:20:25.480
be true in one year, but
for today, I would not build a

213
00:20:25.480 --> 00:20:29.559
analytics platform on top of Sequlite.
How about that? Yeah that makes sense.

214
00:20:29.839 --> 00:20:33.519
I mean I'm thinking more. I
mean we should also not build an

215
00:20:33.519 --> 00:20:41.119
APM with sqlid. Yeah. Again, it does sort of like come back

216
00:20:41.160 --> 00:20:48.079
to your your expected growth profile.
I have built an APM with sqlight and

217
00:20:48.119 --> 00:20:51.599
it's a very like it's an internal
small one, right, But I was

218
00:20:51.640 --> 00:20:56.279
like, I'm not expecting if you
know, the thirty seven Signals crew have

219
00:20:56.359 --> 00:21:04.839
talked about load testing their seql light
back Campfire application and on the biggest machines

220
00:21:04.880 --> 00:21:08.079
that they have, you know,
with their cloud exit, they're they're running

221
00:21:08.519 --> 00:21:12.359
their own machines in a in a
data center and like their bfous machines,

222
00:21:12.720 --> 00:21:22.720
they're getting fifty thousand concurrent requests.
Are there APMs that could handle that?

223
00:21:23.240 --> 00:21:26.960
Yes? Right? If you like, I want to build a business and

224
00:21:27.119 --> 00:21:33.000
I am either the next app signal
or I have failed. Yeah, I

225
00:21:33.079 --> 00:21:36.480
probably would not choose eqlight on day
one. I gain my sort of hot

226
00:21:36.519 --> 00:21:42.440
take on this is and all of
the recent Internet drama aside, I personally

227
00:21:44.119 --> 00:21:49.880
would probably choose either sql or Planet
scale on day one. Those are the

228
00:21:49.880 --> 00:21:53.359
two options I would choose. It's
like, I'm either going for big scale

229
00:21:53.400 --> 00:21:57.519
and I know that, like that's
the characteristics up the app I'm building,

230
00:21:59.160 --> 00:22:07.000
or I'm just a regular scale and
seqal light handles regular scale quote unquote right

231
00:22:07.039 --> 00:22:11.519
like, good luck getting if you
can build an application and you have fifty

232
00:22:11.599 --> 00:22:15.880
thousand concurrent requests, like, good
on you you have, you have definitely

233
00:22:15.920 --> 00:22:26.039
succeeded. So sure answer is maybe, you know, honestly, maybe it's

234
00:22:26.119 --> 00:22:29.920
it's just funny to me because seql
light comes out of the box of the

235
00:22:29.960 --> 00:22:33.559
reels and for the longest time,
you know, you question it, like

236
00:22:33.640 --> 00:22:37.279
everybody's using sql light, And the
more you use reels and you the more

237
00:22:37.559 --> 00:22:41.880
like one off apps that you start
to make, right like, even just

238
00:22:41.920 --> 00:22:45.359
like trying something out like it's great. It does most of what you need,

239
00:22:45.519 --> 00:22:48.359
right like, And I feel like
most people won't even hit the limitations

240
00:22:48.400 --> 00:22:52.640
of it or see any side effects
of that, you know, until much

241
00:22:52.720 --> 00:22:57.960
much later to your point where there
is an actual you know, limitation and

242
00:22:59.200 --> 00:23:03.519
you have the knee the financial uh
you know ability to navigate that, right

243
00:23:04.119 --> 00:23:07.680
uh, And I feel like most
people won't even get there, you know,

244
00:23:07.880 --> 00:23:12.920
to be honest and uh, I
mean and in all honestly thanks to

245
00:23:14.200 --> 00:23:18.599
the shopify folks for all of their
efforts with it as far as like a

246
00:23:22.000 --> 00:23:23.920
you know, live stream as an
example, but you know, all all

247
00:23:23.960 --> 00:23:30.000
of the other integrations to just make
it super straightforward to get set up and

248
00:23:30.359 --> 00:23:38.480
operational. Like I don't know,
I feel like, why bother? Why

249
00:23:38.519 --> 00:23:45.319
bother having Like I'm definitely coming around
to that off the cloud idea for for

250
00:23:45.359 --> 00:23:52.039
it specifically of you know, why
have all these extra services that just aren't

251
00:23:52.079 --> 00:23:59.119
needed and it's just to help you
scale maybe right? Yeah, I mean,

252
00:23:59.160 --> 00:24:06.440
this has been one of I like
major realizations and principles that drive a

253
00:24:06.480 --> 00:24:15.240
lot of my personal interest in the
topic is recognition that for me, myself,

254
00:24:15.759 --> 00:24:25.000
I really am trying to be conscientious
about fighting off unnecessary complexity, like

255
00:24:25.480 --> 00:24:30.079
it's just swarming around us, and
especially like for where we are at in

256
00:24:30.119 --> 00:24:36.240
the evolution of the Internet and the
economy, of the internet, right like,

257
00:24:36.559 --> 00:24:40.039
everything is assas. Now everything is
a product now like, hey,

258
00:24:40.079 --> 00:24:45.039
you need authentication, here's the sass
you buy. You need emails, here's

259
00:24:45.079 --> 00:24:52.200
the sass you buy. It's and
it is, you know it just like

260
00:24:52.480 --> 00:25:00.599
greats on me to see how like
common the I don't know, the mind

261
00:25:00.720 --> 00:25:07.680
virus, I'll be sassy. Is
that the correct way to build a web

262
00:25:08.759 --> 00:25:18.079
application, a service, a business
is to sign up for fifteen different SaaS

263
00:25:18.119 --> 00:25:26.319
platforms, stitch your things together,
have no real ownership or understanding of like

264
00:25:27.279 --> 00:25:33.039
what your rankin app is doing.
Then, like I mean, and we've

265
00:25:33.039 --> 00:25:36.440
been seeing more and more of it, right like, and then you actually

266
00:25:36.480 --> 00:25:41.680
get some success or more commonly,
the actual noise of the internet and the

267
00:25:44.960 --> 00:25:51.559
people who just like doing naughty things
and having their little bot farms run and

268
00:25:51.640 --> 00:25:53.319
you just like boom all of a
sudden like whoops, like I have a

269
00:25:53.359 --> 00:26:00.319
bill for ten thousand dollars from this
one service for this month. And yeah,

270
00:26:00.359 --> 00:26:03.400
as you said, I mean,
it's like it's actual like statistics,

271
00:26:03.759 --> 00:26:11.119
like most applications are not going to
actually need like there's real value there.

272
00:26:11.160 --> 00:26:14.039
I'm not saying that most of these
businesses shouldn't exist. They should exist,

273
00:26:14.079 --> 00:26:19.319
but most people shouldn't pay for them, right like we servers are cheap,

274
00:26:19.400 --> 00:26:25.480
servers are easy. Like I'm no
DevOps genius. I'm certainly not an obstenist.

275
00:26:25.519 --> 00:26:29.960
I barely can use Docker, you
know. But I have spun up

276
00:26:30.720 --> 00:26:37.839
many many servers in my day,
and it's not rocket science. I have

277
00:26:37.039 --> 00:26:44.720
maintained them. That's also not rocket
science. It's not incredibly stressful. It

278
00:26:44.799 --> 00:26:48.599
can be when you make like mistakes, and that's why this concept of production

279
00:26:48.640 --> 00:26:52.519
grade is important to have a sense
of like what does it mean, you

280
00:26:52.519 --> 00:26:56.839
know, to give to give one
specific example, I had an application that

281
00:26:56.920 --> 00:27:06.000
we use at work for business that
provides profit running on sql I and I

282
00:27:06.000 --> 00:27:07.640
had been thinking for a while,
you know, I really need to go

283
00:27:07.759 --> 00:27:12.400
in and install light stream and set
that up. But I didn't get around

284
00:27:12.440 --> 00:27:23.160
to it. And then one day
I was cleaning up and renaming my applications

285
00:27:23.200 --> 00:27:29.839
to make them more consistent, and
I did not recognize that in the little

286
00:27:29.920 --> 00:27:34.119
web platform that when I rename an
application, what it's going to do on

287
00:27:34.160 --> 00:27:41.920
the server? Is this going to
do our MRF? And then redeployed and

288
00:27:42.160 --> 00:27:47.200
it wiped my sequel like database,
you know, and I spent like a

289
00:27:47.200 --> 00:27:49.240
full day trying to recover it from
memory and it did not work and I

290
00:27:49.960 --> 00:27:55.480
had to go back to the business
and yeah, you know, that was

291
00:27:55.519 --> 00:28:00.279
a shitty day. And I to
put in backups after that, Right,

292
00:28:00.319 --> 00:28:02.640
So this is why I do bring
up production. It's like, yeah,

293
00:28:02.759 --> 00:28:06.319
you know, you can footgun yourself, but you can set up backups for

294
00:28:06.440 --> 00:28:11.279
postcards or my syqul or anything.
But like, none of these things are

295
00:28:11.319 --> 00:28:15.519
difficult. And it just saddens me
to think that so many developers and especially

296
00:28:15.559 --> 00:28:19.359
newcomers like come into web development and
think like a, you have to understand

297
00:28:19.559 --> 00:28:25.319
docer and Kuber needes and server lists, you have to pay for fifteen SaaS

298
00:28:25.319 --> 00:28:29.759
platforms. It's like, man,
it's going to take a PhD in web

299
00:28:29.799 --> 00:28:34.200
development and at least five hundred dollars
a month to even like start to do

300
00:28:34.240 --> 00:28:38.359
something. It's like that just isn't
true. Like more people can get started

301
00:28:38.599 --> 00:28:48.000
with less prep and less upfront money, and I really want to make it

302
00:28:48.039 --> 00:28:52.039
as widely known as possible like this, there is this alternative path. You

303
00:28:52.039 --> 00:28:56.240
know, you can just go get
a digital Ocean droplet, put a rail

304
00:28:56.319 --> 00:29:00.039
server in a sequel like database,
like you have one machine and you can

305
00:29:00.119 --> 00:29:06.039
grow that you're just in your little
digital otion dashboard, Like you could just

306
00:29:06.160 --> 00:29:08.240
bump it up over time, and
you can do that for a long time.

307
00:29:08.680 --> 00:29:12.799
Like go and look at the biggest
machine on there. It's really big

308
00:29:14.599 --> 00:29:18.200
and it can handle a lot of
requests, and sql I can handle a

309
00:29:18.200 --> 00:29:19.960
lot of requests. And these things
like can be cheap and they can be

310
00:29:21.000 --> 00:29:25.599
simple, and that opens up opens
up so much opportunity for like experimentation and

311
00:29:25.640 --> 00:29:29.720
more people coming in and trying things
out. And that's like that's what drives

312
00:29:29.759 --> 00:29:33.240
the passion behind it, right,
It's like doesn't have to be this other

313
00:29:33.359 --> 00:29:40.559
way, Yeah, I feel Yeah, it just reminds you of CGI,

314
00:29:40.839 --> 00:29:45.480
right, Like back in the day, you had a directory CGI and you

315
00:29:45.680 --> 00:29:52.480
uploaded a programmable file and it ran, and you know, it was that

316
00:29:52.640 --> 00:29:56.720
easy. Yeah, everybody had FTP
line or whatever. You know, you

317
00:29:56.839 --> 00:30:02.160
just uploaded the file and then you
were ready to go, and like people

318
00:30:02.559 --> 00:30:07.039
ran like legit businesses off of it, you know where you know, guitar

319
00:30:07.200 --> 00:30:11.920
tab sites or like you know,
all of the original search engines. You

320
00:30:11.960 --> 00:30:17.559
know. It was just like a
handful of programmatical files in a directory somewhere

321
00:30:17.960 --> 00:30:21.519
and it just ran and I feel
like, you know, maybe maybe we're

322
00:30:21.559 --> 00:30:25.599
like a little bit beyond that,
right, but it should still be that

323
00:30:25.720 --> 00:30:30.160
easy. You know. It's like
the underlying technologies haven't really changed that much.

324
00:30:30.880 --> 00:30:34.960
Uh, you know, like you
still have servers and clients and a

325
00:30:36.000 --> 00:30:41.960
browser, you know, and it's
it's those three things. Uh yeah,

326
00:30:42.000 --> 00:30:47.559
I why make it more busy?
I was just going to add with all

327
00:30:47.599 --> 00:30:52.200
the different SaaS products you can add, right, So top endevs for a

328
00:30:52.200 --> 00:30:56.799
long time ran the authentication through one
of the authentication services out there that you

329
00:30:56.880 --> 00:31:03.839
pay for, and yeah, it
was more work to set up and manage

330
00:31:03.920 --> 00:31:07.599
that than it was for me.
Eventually, I just switched it back over

331
00:31:07.680 --> 00:31:12.039
to deviz, right because I set
it up once and then yeah, occasionally

332
00:31:12.079 --> 00:31:17.039
I have to help somebody reset their
password or something stupid. Right, Hey,

333
00:31:17.039 --> 00:31:19.319
oh yeah I jacked that up.
Let me fix you, right,

334
00:31:22.160 --> 00:31:25.119
And yeah, I feel this on
the rest of the infrastructure too, right.

335
00:31:25.640 --> 00:31:29.400
I Mean, one of the things
I really like about camal is that

336
00:31:30.359 --> 00:31:33.720
it kind of does that, right. So it pulls down the postcress doctor

337
00:31:33.759 --> 00:31:37.400
image, it pulls down the red
as a Docker image, it pulls down

338
00:31:37.119 --> 00:31:41.680
you know, a Ruby Docker image
and then runs my doctor file against it

339
00:31:41.039 --> 00:31:44.400
and then it says, hey,
that's over there and that's over there,

340
00:31:44.440 --> 00:31:48.519
and that's it right, and load
balancer. It does the load balancer too,

341
00:31:48.079 --> 00:31:52.680
and that that's what I love about
this. So yeah, having something

342
00:31:52.720 --> 00:31:55.079
simple where it's just like, oh, yeah, it's just going to run

343
00:31:55.119 --> 00:31:59.519
alongside the app, the app server, right, run alongside Puma or whatever.

344
00:32:00.039 --> 00:32:04.480
Yeah, that is beautiful, right, I don't have to fuss about

345
00:32:04.480 --> 00:32:10.079
it, yeah, exactly. And
then on top of it, you get

346
00:32:10.160 --> 00:32:21.240
like these really nice benefits of like
it's I would recommend for developers to just

347
00:32:21.359 --> 00:32:25.039
like spin up an app and throw
it up somewhere, right, use camal,

348
00:32:25.119 --> 00:32:28.359
use hashbox, like use whatever,
like do it quick an do it

349
00:32:28.440 --> 00:32:35.039
easy, and just like play around
and get a feel for what it feels

350
00:32:35.079 --> 00:32:37.200
like on like two fronts. And
this is where it like really sold me

351
00:32:37.400 --> 00:32:45.880
and I like became passionate about it. So the one is it is it's

352
00:32:45.200 --> 00:32:51.640
just really nice to have a simple
enough system that you can keep it in

353
00:32:51.680 --> 00:32:55.079
your head. And so the fewer
moving parts, the simple as the system.

354
00:32:55.720 --> 00:33:00.599
And like I have these applications that
I have built at works, you

355
00:33:00.640 --> 00:33:06.839
know, sort of like these R
and d applications that I am effectively the

356
00:33:06.920 --> 00:33:12.599
sole developer and maintainer of them.
And you know, I'm an engineering manager.

357
00:33:12.680 --> 00:33:15.200
I'm in a lot of calls.
I have like these thirty minute windows

358
00:33:15.200 --> 00:33:20.799
sometimes between calls, and I have
to debug production issues that come up,

359
00:33:21.519 --> 00:33:25.400
and I can actually do that.
I can go from like I haven't heard

360
00:33:25.440 --> 00:33:30.000
anything, I get a Slack message, I read the problem from that moment

361
00:33:30.079 --> 00:33:36.440
to I have checked that the fix
is live and fixes the problem in production.

362
00:33:37.880 --> 00:33:40.720
I have consistently been able to do
that inside of a thirty minute window

363
00:33:42.000 --> 00:33:46.640
for over a year, and that
is like a magical feeling. I every

364
00:33:46.640 --> 00:33:50.920
single time I do it, I'm
like, Wow, this feels amazing compared

365
00:33:50.960 --> 00:33:57.160
to most of my work experience.
And that is like driven by I have

366
00:33:57.559 --> 00:34:02.599
a rails app and see collide astaut
That is it. I have nothing else.

367
00:34:02.880 --> 00:34:07.200
I don't have Rettis, I don't
have. I have nothing. I

368
00:34:07.240 --> 00:34:10.679
have like four different sequent databases,
right, I've got my Q database and

369
00:34:10.719 --> 00:34:16.800
my cash database and my model's database
or you know, production database is what

370
00:34:16.840 --> 00:34:22.599
it's called. But I have this
one piece of software, and that piece

371
00:34:22.599 --> 00:34:28.280
of software I don't have to do
anything weird or fancy it just runs inside

372
00:34:28.320 --> 00:34:30.519
of my application process. There's nothing
to like spin up. I don't need

373
00:34:30.559 --> 00:34:37.960
to have a PROC file necessarily.
It's just is there, and that like

374
00:34:38.079 --> 00:34:42.400
developer experience is so nice. And
then like on top of it, it's

375
00:34:42.480 --> 00:34:45.400
just like a file. And so
if I need to which I've done many

376
00:34:45.440 --> 00:34:49.639
times, right, like a production
issue comes in and I can tell,

377
00:34:49.800 --> 00:34:52.880
uh, you know, some data
has gotten out of sync here, but

378
00:34:52.920 --> 00:34:55.840
I don't know exactly how or where
or what I need to dig into the

379
00:34:55.880 --> 00:35:02.079
data. And I can literally like
do a safe backup. I can use

380
00:35:02.119 --> 00:35:05.599
the fact that I have these light
stream backers. I can just tell light

381
00:35:05.639 --> 00:35:09.639
Stream on my laptop, hey,
replicate the database to my laptop please,

382
00:35:09.719 --> 00:35:13.000
as of right now, what is
the current stay of the day. So

383
00:35:13.039 --> 00:35:16.119
I get a mirror of the production
database on my laptop, I spin up

384
00:35:16.239 --> 00:35:20.480
the app on local host. I've
got all the production data, and I

385
00:35:20.519 --> 00:35:23.679
can mess around and figure out like
where is the where did the data go

386
00:35:23.760 --> 00:35:29.039
wrong? Where's the bug in the
background job that messed this up? And

387
00:35:29.079 --> 00:35:30.679
I know it's completely safe. I
don't have to remember to do the dash

388
00:35:30.760 --> 00:35:36.559
dash sandbox in my Rails console or
any of that, And it's like,

389
00:35:36.639 --> 00:35:38.519
you know, one CLI command to
get it down there, and there's like

390
00:35:39.800 --> 00:35:44.719
so many of these little things,
you know, whether it's the one of

391
00:35:44.760 --> 00:35:52.519
the first articles I wrote was on
doing database branching locally with get and it's

392
00:35:52.559 --> 00:35:54.679
like the simplest thing in the world
to set up with Rails, and it

393
00:35:54.840 --> 00:36:00.440
just removes an entire class of problem
that has annoyed me for a decade of

394
00:36:00.480 --> 00:36:07.119
web development when you're working across these
different branches and your you know, your

395
00:36:07.119 --> 00:36:12.280
schema gets borked and it's just like
they stack, they stack all these things,

396
00:36:12.679 --> 00:36:15.360
and then at the very end of
it, you're like, oh man,

397
00:36:15.800 --> 00:36:19.880
every single database operation I have done
went from n number of milliseconds to

398
00:36:19.960 --> 00:36:22.960
n number of microseconds. Like I
just got one hundred x performance improvement,

399
00:36:23.719 --> 00:36:29.280
you know, like action pack is
my bottleneck for all of the Rails apps

400
00:36:29.320 --> 00:36:37.079
that run the stack, you know, So that is awesome. Real quick,

401
00:36:37.800 --> 00:36:40.880
just dive in deeper to the branch
specific databases you're talking about, because

402
00:36:40.880 --> 00:36:45.039
I thought this was fascinating reading through
this. Uh, like how does that

403
00:36:45.079 --> 00:36:50.519
set up work? And what are
you saving there? Yeah, it's it's

404
00:36:50.519 --> 00:36:53.000
a really nice feature. Let me
start off by explaining, like the problem.

405
00:36:53.400 --> 00:37:00.280
So here's the scenario that many of
your listeners are likely to have experienced.

406
00:37:01.119 --> 00:37:06.840
You're working in a feature branch,
so you get check out B Feature

407
00:37:06.880 --> 00:37:09.840
A. You get to work.
It's a long running feature branch, kind

408
00:37:09.840 --> 00:37:14.119
of complicated. As a part of
the future work, you have to make

409
00:37:14.199 --> 00:37:16.840
changes to your schema, so you
generate let's say two different migration files.

410
00:37:17.559 --> 00:37:22.440
You added a new table and you
have renamed a couple of colmns on an

411
00:37:22.480 --> 00:37:30.119
existing table. While you are in
the middle of working on this feature branch,

412
00:37:30.159 --> 00:37:37.880
a major production issue is reported and
a bug fix needs to be made.

413
00:37:37.159 --> 00:37:43.840
Someone has created a hot fix branch
and they ask you to review it.

414
00:37:44.280 --> 00:37:45.440
You're like, okay, I did
the code review, but I want

415
00:37:45.440 --> 00:37:51.719
to make sure before we push this
live that like the fix is actually doing

416
00:37:51.960 --> 00:37:57.440
what we wanted to do. So
you get check out hot fix one and

417
00:37:58.400 --> 00:38:04.559
run your application and things aren't working, maybe like your Rails app won't even

418
00:38:04.559 --> 00:38:06.960
boot. Maybe as you boot into
the app, things are there, and

419
00:38:07.000 --> 00:38:07.920
you're like, what in the world
is going on? What is like?

420
00:38:07.960 --> 00:38:13.199
What is broken here? Something is
very clearly broken. And what has happened

421
00:38:13.320 --> 00:38:16.360
is that the schema changes that you
made to your single only local. You

422
00:38:16.400 --> 00:38:22.599
know, development database in future branch
a are still there when you checked out

423
00:38:22.800 --> 00:38:28.119
hop fix one, but hopis one
doesn't expect those changes to be there.

424
00:38:28.159 --> 00:38:32.719
You name some tables or some columns
on some tables, and the code in

425
00:38:32.800 --> 00:38:37.400
hotpics A expects the database to be
in the schema that existed in main,

426
00:38:38.039 --> 00:38:43.239
but your schema locally is different,
and so database and the app have a

427
00:38:43.239 --> 00:38:45.599
mismatch and things blow up. Ah, this is so annoying. So you

428
00:38:45.679 --> 00:38:51.800
have to like get your database state
back into a correct place and then be

429
00:38:51.880 --> 00:38:55.519
able to once you're done reviewing that
topics or however you know, you change

430
00:38:55.559 --> 00:38:59.719
branches and you get back into the
future work, you want to bring those

431
00:38:59.800 --> 00:39:02.880
change. So that's like the problem, and it's an annoying problem, and

432
00:39:02.920 --> 00:39:07.920
there are various gems out there to
try to help you with that. Here

433
00:39:07.000 --> 00:39:14.039
is the simplest, most resilient possible
way to solve that problem. If you

434
00:39:14.159 --> 00:39:20.280
could, in some magical way have
every single git branch have a completely separate

435
00:39:20.400 --> 00:39:23.679
database, well, then definitionally you
would never have this problem. That would

436
00:39:23.719 --> 00:39:30.639
be nice. Now, when you're
running postcress, that might be tricky,

437
00:39:30.760 --> 00:39:34.880
might be possible, or it might
just be computationally expensive or space who knows.

438
00:39:35.039 --> 00:39:39.960
I've not really honestly tried it,
but with sqlight it is both cheap

439
00:39:40.159 --> 00:39:45.719
and easy. And all that it
requires is you take advantage of the fact

440
00:39:45.840 --> 00:39:52.519
that the database EAMO file that Rails
uses is processed by ERB, so you

441
00:39:52.519 --> 00:39:57.039
can just throw some RB in there, and in that ERB you can run

442
00:39:57.400 --> 00:40:00.400
shell commands, so you can just
PLoP in there, Hey, what is

443
00:40:00.480 --> 00:40:05.400
my current get branch name please,
and you can make that the name of

444
00:40:05.440 --> 00:40:10.599
your database. So now you have
dynamic database names. Then the only other

445
00:40:10.599 --> 00:40:17.599
thing you need. Sql I itself
will automatically touch non existent database. So

446
00:40:17.599 --> 00:40:22.760
if you say sql I, please
open database A, that file doesn't exist,

447
00:40:22.880 --> 00:40:25.840
QUL I'll just create an empty file. So all you need is to

448
00:40:27.000 --> 00:40:32.639
ensure that when you start your Rails
app, if your database hasn't been loaded,

449
00:40:34.000 --> 00:40:38.199
run your migrations load the schema.
However you do it, that it

450
00:40:38.320 --> 00:40:45.159
is right. So you just want
to say, take whatever the current encoded

451
00:40:45.239 --> 00:40:52.079
version of my schema is in my
repository and run that. So what I

452
00:40:52.119 --> 00:40:54.880
typically do, and I think what's
in the article is like it will run

453
00:40:54.920 --> 00:41:01.320
your migrations and you can do an
after prepare block in your development dot erb

454
00:41:01.679 --> 00:41:07.000
configuration file. So with those two
changes, what you have done is you

455
00:41:07.039 --> 00:41:15.679
have set up a system where whenever
you change get branches and in any form

456
00:41:15.880 --> 00:41:17.239
you boot your rails app. So
that can be starting the rail server,

457
00:41:17.320 --> 00:41:21.280
that can be starting a rails console, that can be using the rails runner.

458
00:41:22.840 --> 00:41:27.280
It will create, if it doesn't
exist, a new database file.

459
00:41:27.840 --> 00:41:31.360
It will run all of your migrations
and get the state set up. If

460
00:41:31.360 --> 00:41:35.639
a database file does exist but there
are some few migrations, it'll just run

461
00:41:35.679 --> 00:41:38.199
those new migrations and get the state
to where it needs to be. And

462
00:41:39.440 --> 00:41:44.159
you can then enhance that if you
want it to. That's like where I

463
00:41:44.159 --> 00:41:45.599
stop in the article. I need
to write some more about it, but

464
00:41:45.639 --> 00:41:50.159
it's very easy to enhance that in
like you can do seating. You know,

465
00:41:50.199 --> 00:41:54.039
you can have generic seeds that are
always run, so you can have

466
00:41:54.079 --> 00:41:58.480
a baseline set of data that's populated
into all of your branches. You can

467
00:41:58.519 --> 00:42:07.519
set up branch specific seating such that
you and you can make that more generic,

468
00:42:07.639 --> 00:42:09.000
like around scenarios. There's all kinds
of fun things, but in general,

469
00:42:09.480 --> 00:42:16.000
you have the ability to have completely
isolated like actually separate databases for each

470
00:42:16.000 --> 00:42:21.840
of your GET branches, and so
it simply becomes impossible to run into the

471
00:42:21.960 --> 00:42:24.280
super super annoying when it happens,
because it's like, you know, you're

472
00:42:24.320 --> 00:42:28.280
completely blocking me in the moment where
I don't want to have to deal with

473
00:42:28.280 --> 00:42:34.000
any of this these schema conflicts as
you move across GIT branches. That's interesting.

474
00:42:34.320 --> 00:42:37.719
I mean, how do you do
you do you not mind data getting

475
00:42:37.719 --> 00:42:43.159
blown away between branches at that point
or have you solved that problem? And

476
00:42:43.280 --> 00:42:52.320
like you know, stream sum updates. Yeah, so for local development,

477
00:42:52.559 --> 00:42:58.280
I I've ended up with a mix
of a couple of things, and I

478
00:42:58.280 --> 00:43:04.000
have a couple of later blog posts
about this, but I should honestly finish

479
00:43:04.079 --> 00:43:08.960
up writing some of the other stuff
I've done. But in general, I

480
00:43:09.039 --> 00:43:12.960
tend to start off with just like
a generic seeds file. It's like,

481
00:43:13.400 --> 00:43:23.159
let me have some usable data,
and yeah that seventy five percent of the

482
00:43:23.199 --> 00:43:30.280
time that is sufficient. For some
applications. I have ended up in a

483
00:43:30.280 --> 00:43:37.639
place where it's like, well,
I have kind of built up a whether

484
00:43:37.679 --> 00:43:40.199
it's like pulling down a production database
or pulling down a staging database, like

485
00:43:40.599 --> 00:43:52.239
I want to keep this across branches
and I have just written some Ruby scripts.

486
00:43:52.280 --> 00:43:58.679
Basically, I have a I have
a blog post about this. So

487
00:43:58.719 --> 00:44:02.280
it's like you know dB C,
and I just say, okay, I

488
00:44:02.320 --> 00:44:07.719
want to take this database and I
want to clone it into a new file

489
00:44:07.840 --> 00:44:13.880
with this name, and then I
am just wiring up the name that I

490
00:44:14.000 --> 00:44:17.280
point to in my data saml to
that, and there's some automations you can

491
00:44:17.360 --> 00:44:21.280
layer on top to connect that to
get if you want. For the most

492
00:44:21.280 --> 00:44:25.480
part, what I have found is
like when I want to control the actual

493
00:44:25.719 --> 00:44:29.880
data, the schema and the data
this I was like, I want this

494
00:44:29.920 --> 00:44:34.840
file that I sort of move away
from the automatic kit branching stuff, and

495
00:44:34.840 --> 00:44:40.719
I just manually go in and say
comment out my default database line and database

496
00:44:40.719 --> 00:44:45.199
EAML, and just point it out
a particular file. So if you were

497
00:44:45.239 --> 00:44:46.719
to look at like my laptop for
most of the apps I work in,

498
00:44:46.760 --> 00:44:52.840
and you look in my storage directory, on average, you will probably see

499
00:44:52.000 --> 00:44:58.079
at least twelve different seql I three
files in there. So I just create

500
00:44:58.239 --> 00:45:01.039
a bunch of these different scenarios.
I pulled down production on this date,

501
00:45:01.559 --> 00:45:06.320
I've pulled down staging on that date. I've created this Git branch and that

502
00:45:06.440 --> 00:45:09.800
kit branch and they all live there, and sometimes I manually point my app

503
00:45:10.159 --> 00:45:15.960
to one of them or branch off
and just do manual branching as if it

504
00:45:15.960 --> 00:45:19.599
were getting me, Like I want
to sort of play with the schema and

505
00:45:19.599 --> 00:45:22.800
the data in this direction, give
that a name, and wire the app

506
00:45:22.880 --> 00:45:27.920
up to that, and it's all. It's like quite simple, but it

507
00:45:28.000 --> 00:45:30.960
is quite nice to be able to
like have that flexibility or your schema,

508
00:45:30.039 --> 00:45:37.159
your data. You have the full
range of like logical branching that you could

509
00:45:37.199 --> 00:45:46.800
do with get and text files with
your database. Yeah, it's super cool.

510
00:45:47.679 --> 00:45:52.679
Yeah, I mean, look looking
more at looking more at the configurations

511
00:45:52.679 --> 00:45:57.639
you've got, for like having multiple
databases all SEQL light, like, do

512
00:45:57.679 --> 00:46:02.400
you find that there's like a limitation
point of like too many databases of the

513
00:46:02.440 --> 00:46:09.400
same sequel light server like serving for
uh or or where it's just like becomes

514
00:46:09.400 --> 00:46:15.679
too unmanageable to like reason about all
of the different things. Right, Because

515
00:46:15.679 --> 00:46:19.599
I saw you have like a solid
errors which is kind of interesting where you're

516
00:46:19.679 --> 00:46:22.440
like, you know, soaring all
of your errors off to its own database

517
00:46:22.840 --> 00:46:27.320
cash I imagine too, right,
like you start like stacking up all these

518
00:46:27.360 --> 00:46:30.159
different databases, is there is there
a limit to the madness or is it

519
00:46:30.280 --> 00:46:38.159
like still pretty reasonable, you know, for everything that you'd need. So

520
00:46:38.239 --> 00:46:43.199
if there is a limit, I
haven't hit it. The most databases that

521
00:46:43.239 --> 00:46:50.559
I have in production is like six, I think, and like operationally that

522
00:46:51.000 --> 00:46:52.280
it's nowhere close to that. I'm
not even sure if there is a limit.

523
00:46:53.639 --> 00:46:58.400
But conceptually, no, it hasn't
been that bad. What I have

524
00:46:58.440 --> 00:47:04.800
found is like, you know,
for the nature of the system, I'm

525
00:47:04.800 --> 00:47:07.039
going to have this bucket no matter
what. I'm going to have to do

526
00:47:07.079 --> 00:47:12.199
some kind of IO or some for
an object of this type, no matter

527
00:47:12.239 --> 00:47:24.880
what. And for me it is
a conceptual win to keep the actual operational

528
00:47:27.360 --> 00:47:34.000
infrastructure there like the same. You
know. I have been able to become

529
00:47:34.800 --> 00:47:39.159
a master of rails and SQLI and
that's it, and I can do everything

530
00:47:39.199 --> 00:47:44.800
I need. So I don't know
all of the reddest commands. I don't

531
00:47:44.880 --> 00:47:49.760
know all of the reddest data structures. I have a passing awareness of them,

532
00:47:51.159 --> 00:47:58.960
and I wouldn't know how to optimize
a reddest instance for caching. I

533
00:47:58.960 --> 00:48:04.199
don't know how to optimize I've read
as instance for background jobs. I don't

534
00:48:04.280 --> 00:48:07.320
know it would redd us be a
great choice or a terrible choice for the

535
00:48:07.360 --> 00:48:12.480
back end for something like solid errors, you know, storing exceptions that happen

536
00:48:12.519 --> 00:48:24.760
in your application somewhere. So being
able to leverage a flexible, powerful tool

537
00:48:25.599 --> 00:48:30.800
across these different problem domains, and
you know, give myself the challenge,

538
00:48:30.800 --> 00:48:35.639
but also give myself the time to
become a master to like, I know

539
00:48:35.719 --> 00:48:39.960
how to optimize SQL queries for caching, you know, I know, I've

540
00:48:40.000 --> 00:48:43.239
spent time and I've thought about that, and it's just SQL, and I

541
00:48:43.280 --> 00:48:45.360
know that language and I know it
well, and I know how to optimize

542
00:48:45.400 --> 00:48:50.039
like out of structure tables and what
kind of queries to run and make sure

543
00:48:50.039 --> 00:48:57.920
I know how to optimize SQL and
sqlight for a background job que and I

544
00:48:57.960 --> 00:49:01.760
know how to do that for errors. Each one of those I am able

545
00:49:01.800 --> 00:49:07.800
to leverage expertise that I have gained
in the past one. You know,

546
00:49:07.840 --> 00:49:09.880
like there's a lot of overlap.
So if you want to have a good

547
00:49:12.320 --> 00:49:21.199
schema for your active record models,
a lot of the wisdom and principles that

548
00:49:21.280 --> 00:49:24.559
are you're going to learn in that
problem area are going to roll over when

549
00:49:24.559 --> 00:49:28.440
you're like, well, what if
what would it look like to back a

550
00:49:30.239 --> 00:49:32.960
queue, a job queue with sql. Okay, let me think about how

551
00:49:34.000 --> 00:49:36.559
to you know, schema that out, what kinds of queries? How do

552
00:49:36.599 --> 00:49:40.280
I want to deal with this stuff
it is and what's really nice in the

553
00:49:40.360 --> 00:49:46.239
rails ecosystem. As thirty seven Signals
has gotten into building new applications, has

554
00:49:46.239 --> 00:49:53.199
gotten into Sqli, then has been
exploring the benefits of reducing the number of

555
00:49:54.039 --> 00:50:01.760
moving parts and publishing more of these
solid our gem, solid Q, solid

556
00:50:02.079 --> 00:50:09.159
cash, solid cable. I imagine
is being worked on is that I don't

557
00:50:09.159 --> 00:50:14.800
even have to be the only expert. You know, there is now a

558
00:50:15.000 --> 00:50:17.760
community of experts, and I read
through the like, for example, the

559
00:50:17.800 --> 00:50:27.159
solid q source code, and Rosa
did a way better job at it than

560
00:50:27.199 --> 00:50:30.239
I did, you know. So
it's like I just get to take advantage

561
00:50:30.239 --> 00:50:36.960
of the fact that she is a
really top notch developer who spent a lot

562
00:50:37.000 --> 00:50:44.480
of time thinking very deeply about how
to structure a queuing system backed by some

563
00:50:44.559 --> 00:50:50.760
persistent SQL database, And I just
get to run bund lad. You know.

564
00:50:52.000 --> 00:50:55.440
So I haven't gotten anywhere close to
a limit, and I have actually

565
00:50:55.480 --> 00:51:00.360
found like every single time I do
it, I'm like, you know,

566
00:51:00.599 --> 00:51:05.639
I should have more databases, Like
I'm right now working on another gem,

567
00:51:05.639 --> 00:51:08.519
which is like the conceptual sibling to
solid errors. I think I've named it

568
00:51:08.559 --> 00:51:15.039
solid metrics, which is just let
me keep track of the metrics. You

569
00:51:15.039 --> 00:51:17.960
know, I want to know them. I don't have super high needs.

570
00:51:19.000 --> 00:51:22.599
I don't have a lot of customizability. I just need to know the basics.

571
00:51:23.079 --> 00:51:27.719
Rails instruments itself already. It's the
same thing with airs. It's all

572
00:51:27.719 --> 00:51:31.400
instrumented. I just want to put
them somewhere and put a very basic WebUI

573
00:51:31.519 --> 00:51:36.320
on top of it. And you
know, I've got like three more ideas

574
00:51:36.320 --> 00:51:37.599
on top of it. So probably, you know, come back to me

575
00:51:37.639 --> 00:51:42.960
in two years. I'll probably have
like twelve different databases and some application somewhere

576
00:51:43.000 --> 00:51:49.239
in production and might not be ready
to stop there either. Very cool.

577
00:51:49.559 --> 00:51:54.239
So I guess my question is because
you said I know how to optimize sql

578
00:51:54.280 --> 00:51:59.440
light for a Q, I know
how to optimize it for something like solid

579
00:51:59.440 --> 00:52:04.440
air, know how to optimize it
for you know, whatever else. How

580
00:52:04.440 --> 00:52:07.400
do I figure that out? I
mean, do I just stack overflow the

581
00:52:07.440 --> 00:52:13.880
thing, or yeah, I know
how to tweak sql light for my use

582
00:52:13.920 --> 00:52:19.719
case. Well, I'll start by
just distinguishing one one small point, which

583
00:52:19.800 --> 00:52:23.800
just that you know, for those
particular domains, that's just SQL not SQL.

584
00:52:23.960 --> 00:52:28.119
You know, like what kinds of
tables with what kinds of columns and

585
00:52:28.159 --> 00:52:35.199
what kinds of indices you're structure if
you know. So somebody Mike had to

586
00:52:35.280 --> 00:52:39.719
think about which reddest data structures and
reddest commands should I use to have a

587
00:52:39.800 --> 00:52:46.800
resilient and performance job back end,
and other people I've thought about if I

588
00:52:46.880 --> 00:52:52.639
went to like have those same behaviors, but I wanted to back it with

589
00:52:52.119 --> 00:52:57.599
a relational database, how should I
structure my tables? What kinds of industries

590
00:52:57.599 --> 00:52:59.559
should I have? What kinds of
query should I write? How do I

591
00:52:59.599 --> 00:53:04.760
do that resiliently and performantly? That's
a sequel problem. But when it comes

592
00:53:04.840 --> 00:53:10.320
to SEQL light, I would say
there are sort of two parts to an

593
00:53:10.320 --> 00:53:15.960
answer to your question. So one
part is one of my goals is to

594
00:53:16.079 --> 00:53:21.960
make the amount that you or anyone
else would have to learn about seqlight to

595
00:53:22.039 --> 00:53:28.440
make it work incredibly well for a
rails application specifically and for a web application

596
00:53:28.519 --> 00:53:34.239
more generally, as close to zero
as possible. Right, So you know,

597
00:53:34.280 --> 00:53:37.719
we that's what I want the user, I think, and it's what

598
00:53:37.840 --> 00:53:44.599
I would have wanted where I not
the person who got you know, sort

599
00:53:44.599 --> 00:53:49.440
of infected with the bug of really
getting into it. But one of the

600
00:53:49.440 --> 00:53:54.880
great levers that is available in using
a web application framework is that these kinds

601
00:53:54.920 --> 00:54:00.719
of things can be pushed into the
framework itself. So you know, we

602
00:54:00.840 --> 00:54:05.960
made a number of changes to the
default configuration for sequel Light as a part

603
00:54:06.000 --> 00:54:10.800
of Rail seven to one, and
that like just there were six changes.

604
00:54:10.800 --> 00:54:14.519
I have a whole block was about
it. Like those six changes alone make

605
00:54:14.760 --> 00:54:20.239
a massive difference. And if you
had taken if you take a default Rail

606
00:54:20.280 --> 00:54:22.400
seven zero application and put it on
the Internet, you're going to experience pain.

607
00:54:23.159 --> 00:54:27.119
And if you put a Rail seven
one applicate Sequelight application of the Internet,

608
00:54:27.199 --> 00:54:31.800
you will experience notably less pain,
but still some pain. And we

609
00:54:31.920 --> 00:54:37.360
are solving the major pain points at
the rails level itself. So whether it's

610
00:54:37.519 --> 00:54:51.199
improving concurrency or improving the performance of
talking to seqlite sort of like the Ruby

611
00:54:51.239 --> 00:54:57.840
and c bridge, I really want
to have as much of that live in

612
00:54:57.880 --> 00:55:01.159
the framework as possible. But of
course, as for anything like your app

613
00:55:01.199 --> 00:55:07.719
is going to have some special use
cases and things where you're going to have

614
00:55:07.760 --> 00:55:13.239
to move beyond the framework and so
like, how do you learn to take

615
00:55:13.280 --> 00:55:20.159
advantage of Sequela? And I would
say that there are like compleately three things

616
00:55:20.320 --> 00:55:25.719
I would recommend. So the first
one is the sequel Like docs are extensive,

617
00:55:27.239 --> 00:55:32.039
and I personally find them quite approachable. I mean like it's not just

618
00:55:32.119 --> 00:55:38.360
like here's all the C code,
and it's not just like here's the the

619
00:55:38.440 --> 00:55:45.679
interfaces. There's I mean it's been
around for thirty plus years, and you

620
00:55:45.719 --> 00:55:52.559
can see they've talked about just about
everything that's in there. And it has

621
00:55:52.559 --> 00:55:57.559
a nice little search bar in the
top, and they also have a form

622
00:55:57.599 --> 00:56:01.039
and you can search that there,
and there's just a lot of valuable content

623
00:56:01.079 --> 00:56:06.360
there and you can really find a
lot of answers to many questions just search

624
00:56:06.440 --> 00:56:12.639
the forums, search the docs.
So reach for that first. Secondly,

625
00:56:14.960 --> 00:56:20.159
for like situations where you know,
I sort of have this unique problem or

626
00:56:20.159 --> 00:56:22.239
I kind of want to do this
somewhat unique feature, how can I do

627
00:56:22.239 --> 00:56:29.679
that with SQL? I there is
a quite I mean fairly robust. I

628
00:56:29.679 --> 00:56:31.519
don't know numbers. I haven't dug
deep into post chress, but there are

629
00:56:31.519 --> 00:56:38.400
a lot of sequel at extensions and
they add all kinds of different functionality.

630
00:56:38.599 --> 00:56:45.000
So whether it's you know, the
hot new stuff of storing vectors in your

631
00:56:45.039 --> 00:56:52.000
database so that you can run some
form of AI feature inside of your application.

632
00:56:52.960 --> 00:56:54.679
There's a sequel aid extension for that. You know, there is the

633
00:56:54.719 --> 00:56:58.639
equivalent of pg vector for sequel.
You can add it in, you can

634
00:56:58.679 --> 00:57:07.599
store vectors, you can query them
and retrieve them, and many many others

635
00:57:08.280 --> 00:57:10.559
start there, you know, see
like, hey, is there an extension

636
00:57:10.599 --> 00:57:17.079
to do this? And then the
third one would be if those things fail.

637
00:57:19.639 --> 00:57:23.400
There really has been a growing number
of people interested in working with this,

638
00:57:23.719 --> 00:57:30.159
and the online community in my experience, has been very welcoming and very

639
00:57:30.159 --> 00:57:36.559
positive. And you can just throw
something up on Twitter, on stack overflow

640
00:57:37.199 --> 00:57:43.840
and I think you're very likely to
get some useful and good responses. Super

641
00:57:43.840 --> 00:57:45.199
cool. Well, we're kind of
at the end of our time. Was

642
00:57:45.239 --> 00:57:51.119
there anything else that you wanted to
make sure that you covered? Valentino there

643
00:57:51.159 --> 00:57:53.039
was something I'm trying to think about, but he had you at machine learning.

644
00:57:53.079 --> 00:57:57.000
I know, yeah, I know, I got sidetracked in my head.

645
00:57:59.360 --> 00:58:02.320
I have a lot of questions there, but yeah, I guess,

646
00:58:02.400 --> 00:58:07.039
like, have you hit any limitations
as far as like I think of like

647
00:58:07.400 --> 00:58:13.239
as an example, you know,
Jason Collumns and postgraz Or, doing you

648
00:58:13.280 --> 00:58:17.280
know, database views or things like
that where you know, maybe seql light

649
00:58:17.360 --> 00:58:24.559
doesn't have the feature. Have you
found many limitations in that regard that where

650
00:58:24.599 --> 00:58:28.519
you had previously, you know,
reached for a certain tool that you no

651
00:58:28.559 --> 00:58:35.480
longer have available because of the the
database limitation. So the short answer is

652
00:58:35.599 --> 00:58:40.679
no. But let me just add
like I really hope people can will just

653
00:58:40.800 --> 00:58:45.320
believe me. I guess when I
say that, I really I'm not like

654
00:58:45.519 --> 00:58:50.119
killing right, sequel Light is not
paying me any money. I am not

655
00:58:50.159 --> 00:58:54.800
making any money by talking about it. I'm not trying to get you to

656
00:58:55.119 --> 00:59:00.079
you know, buy my Sequelight sasas
or anything. So this is I'm not

657
00:59:00.159 --> 00:59:05.159
just trying to like be a hype
man. There's there's no value or utility

658
00:59:05.159 --> 00:59:09.159
in it for me. Right,
it is interesting that like it I was

659
00:59:09.199 --> 00:59:12.239
in the exact same book, Like, I don't know what it is.

660
00:59:12.239 --> 00:59:16.960
There's just like something you know,
a general myth on the innate. It's

661
00:59:17.000 --> 00:59:22.239
like sequel Light is anemic, just
doesn't have a lot of functionality. It's

662
00:59:22.239 --> 00:59:27.360
small, it's weak, It's like
nope. Jason Columns, Gottam Jason Operators

663
00:59:27.400 --> 00:59:37.719
Gottam generated columns, Gottom views Gottom
store generated columns Gottom. Honestly, the

664
00:59:37.719 --> 00:59:39.400
there are really only two features I've
been like, you know, it'd be

665
00:59:39.440 --> 00:59:45.239
really cool if Sequelight added them.
So one is GIN indexes from Postcress,

666
00:59:45.280 --> 00:59:52.159
Like that's just a really useful,
I mean, generic index. It's nice

667
00:59:52.159 --> 00:59:57.760
to have. Sequel Light doesn't have
it. So you can have SEQUL like

668
00:59:57.880 --> 01:00:01.519
columns, but you can't in them
as easily. And if you wanted to

669
01:00:02.559 --> 01:00:06.639
do something like that, you do
have a workaround, like you can make

670
01:00:06.800 --> 01:00:10.760
a stored generated column sort of like
extract out the parts that you want the

671
01:00:10.800 --> 01:00:15.679
index as a as a store generated
column and then index that store generated column

672
01:00:15.679 --> 01:00:22.320
and query against that. But doesn't
have GIN would be nice. And then

673
01:00:22.400 --> 01:00:28.440
of course, right like it would
be cool if you could do concurrent rights,

674
01:00:28.880 --> 01:00:35.199
that would be great. You can't, but that would be nice.

675
01:00:35.199 --> 01:00:39.679
Aside from that, I personally have
not come across any feature that I have

676
01:00:39.880 --> 01:00:45.119
needed to or wanted to build that
sequel I didn't provide, and I was

677
01:00:45.159 --> 01:00:53.199
in fact surprised actually as I dug
into it, more like oh okay,

678
01:00:53.440 --> 01:00:57.800
sequel I actually does support like basically
the full you know, it supports the

679
01:00:57.800 --> 01:01:00.800
full Sequel standard and a lot of
the stuff that is in the standard that

680
01:01:00.920 --> 01:01:02.599
you know Postcress or My Sequel,
like, this would be a nice feature.

681
01:01:04.039 --> 01:01:05.920
So I was like, sure,
it sounds like a nice feature.

682
01:01:05.960 --> 01:01:13.559
I'll add it. So I'm not
just a blind hype man, and I

683
01:01:13.920 --> 01:01:16.119
don't think syquolid is the solution to
all things. But really, genuinely,

684
01:01:16.679 --> 01:01:22.320
I think there are a lot of
limitations, Like we need to start fighting

685
01:01:22.360 --> 01:01:27.559
back against this myth that it is
an anemic tool. It's the most widely

686
01:01:27.639 --> 01:01:30.880
used database in the world. It's
the best tested database in the world.

687
01:01:30.920 --> 01:01:35.559
It's one of the it is older
than the other two major databases, my

688
01:01:35.639 --> 01:01:40.119
Sequel and post Chris like. It
is resilient, it is powerful, it

689
01:01:40.239 --> 01:01:47.440
is well tested, it is flexible, it is easy to learn. There

690
01:01:47.480 --> 01:01:54.320
really aren't reasons to not use it
unless you're building the next you know,

691
01:01:54.360 --> 01:02:00.679
Fathom analytics and you really do need
one million rites per second, then yep,

692
01:02:00.760 --> 01:02:05.679
there's a reason not to use it. Just one last note, there's

693
01:02:05.840 --> 01:02:13.679
a a famous, you know,
learning experiment where if you wanted to like

694
01:02:13.800 --> 01:02:16.880
learn a new language. As an
example, there's a build your own SEQL

695
01:02:16.960 --> 01:02:23.480
light database kind of tutorial that lots
of people follow because it does, like,

696
01:02:23.800 --> 01:02:28.480
you know, everybody wants like a
rebel, right, Like everybody wants

697
01:02:28.480 --> 01:02:30.920
to build a store data read data
from files, right, and like seql

698
01:02:31.000 --> 01:02:35.920
light does all of these things that
are very just common patterns for languages.

699
01:02:36.239 --> 01:02:38.800
You have to learn to do the
core tenants of whatever it is to make

700
01:02:38.880 --> 01:02:44.360
it be a database like from a
file system, which is kind of interesting.

701
01:02:44.880 --> 01:02:47.320
So speaking of picks, you know, I might as well pick that

702
01:02:49.079 --> 01:02:52.159
it's like how to build a sql
light database. But I've definitely started one

703
01:02:52.199 --> 01:02:58.320
in Rust, which is just for
fun and it's it's amazing how simple,

704
01:02:59.119 --> 01:03:01.800
like as you mentioned and sequel light. You know, it really is under

705
01:03:01.800 --> 01:03:07.760
the hood as far as storing things, and this is fun. It made

706
01:03:07.760 --> 01:03:09.679
me think about it. Cool.
All right, Well, I'm gonna push

707
01:03:09.719 --> 01:03:15.239
just pics. Valentino, you got
some picks. Yeah, I've been loving

708
01:03:15.239 --> 01:03:20.760
a Lama, which I know has
been mentioned on the show before and by

709
01:03:20.800 --> 01:03:25.679
others. But it is a way
to run local inference on your machine against

710
01:03:25.679 --> 01:03:31.320
many different open source large language models. It's kind of fantastic. It runs

711
01:03:31.360 --> 01:03:38.599
as a server, so you can
serve many different models optimized automatically with whatever

712
01:03:38.679 --> 01:03:43.239
GPU you're running, and you configure
it to offload some of that to the

713
01:03:43.280 --> 01:03:46.880
CPU, and it's pretty fast and
just it has saved so much time,

714
01:03:47.039 --> 01:03:52.480
just like investigating and evaluating other models
that are out there, and you can

715
01:03:52.519 --> 01:03:55.920
even build your own models and serve
those locally, which is kind of wild.

716
01:03:57.719 --> 01:04:04.280
So I highly recommend checking it out
if you have awesome I'm gonna jump

717
01:04:04.360 --> 01:04:13.559
in with my board game pick first, so I'm gonna I went to salt

718
01:04:13.599 --> 01:04:20.840
Con, which is a local board
game convention, and I really had a

719
01:04:20.880 --> 01:04:24.719
good time, just hung out with
one of my buddies the whole time,

720
01:04:24.800 --> 01:04:29.639
and we ran into some other people
we knew there, so anyway, it

721
01:04:29.719 --> 01:04:32.719
was awesome. So shout shout out
to salt Con if you're in or around

722
01:04:32.920 --> 01:04:36.480
Utah. They're doing another one in
June, and I'm hoping to get a

723
01:04:36.519 --> 01:04:42.039
ticket to that one. I haven't
bought one yet, but we're kind of

724
01:04:42.039 --> 01:04:45.920
doing that thing. Also, before
I do that, I should probably mention

725
01:04:45.000 --> 01:04:49.800
that I am looking for work,
so if you're hiring contract or full time,

726
01:04:50.639 --> 01:04:55.360
I would love to hear it.
Chuck at topendevs dot com. All

727
01:04:55.440 --> 01:04:57.800
right, So the game I'm gonna
pick is a game I played there.

728
01:04:57.800 --> 01:05:05.360
It's called Apiary and uh so Board
Game Geek. I'm just gonna warn you

729
01:05:05.440 --> 01:05:10.320
this one's on the more complicated end. It was definitely fun. There were

730
01:05:10.360 --> 01:05:13.800
some unique things. But Board Game
Geek has has a weight of two point

731
01:05:13.920 --> 01:05:17.920
ninety six on it. That's out
of five, so you know there are

732
01:05:18.000 --> 01:05:24.840
fours and fives, and usually those
ones will run for hours. Apery did

733
01:05:24.840 --> 01:05:28.159
not. I think it took us
an hour to play it with four players.

734
01:05:28.360 --> 01:05:32.239
But it's pretty involved. So if
you don't like the games where you

735
01:05:32.320 --> 01:05:34.880
have a ton of stuff to keep
track of, then this isn't the one

736
01:05:34.880 --> 01:05:39.320
for you. But if you want
one that has some mechanics and you know

737
01:05:39.360 --> 01:05:41.880
you have to kind of figure out
which strategy you're going to jump on,

738
01:05:42.440 --> 01:05:44.760
it's a terrific game. It was. It was a lot of fun.

739
01:05:45.599 --> 01:05:51.599
It's kind of a blend between like
worker placement and I don't know. There

740
01:05:51.599 --> 01:05:58.480
were some pretty unique mechanics. So
every time your every time you placed your

741
01:05:58.519 --> 01:06:01.119
worker, if there wasn't room for
your worker, then you would bump somebody

742
01:06:01.119 --> 01:06:04.960
else off the board and that b
would go back to the hive. But

743
01:06:05.000 --> 01:06:10.320
it would get promoted, and then
once you got promoted, if a four

744
01:06:10.400 --> 01:06:15.400
got promoted at Hibernate, and then
go back to one right instead of level

745
01:06:15.440 --> 01:06:19.280
four, and so anyway, but
the number on the B and the number

746
01:06:19.320 --> 01:06:26.320
of the other b's on a particular
spot also determined what you could do there

747
01:06:26.639 --> 01:06:30.840
and so anyway, and the number
four is also have unique abilities at each

748
01:06:30.880 --> 01:06:34.920
space. So anyway, lots of
stuff, just really really interesting game.

749
01:06:38.280 --> 01:06:42.440
It was almost too much. There
were almost too many things going on to

750
01:06:42.519 --> 01:06:46.440
make it just super laid back fun. But anyway, I did really enjoy

751
01:06:46.480 --> 01:06:51.440
the game, and it's on my
list is one that I may eventually go

752
01:06:51.480 --> 01:06:55.800
by, so I'm gonna pick it
now. If you didn't pick up on

753
01:06:55.880 --> 01:07:00.719
the theme, Apary is like an
av areas for birds, Apire is for

754
01:07:00.840 --> 01:07:08.480
bees, and it's space bees,
so you're adding on to your spaceship and

755
01:07:08.519 --> 01:07:15.599
stuff like that. So anyway,
so yeah, so that's my board game

756
01:07:15.639 --> 01:07:23.559
pick. And uh yeah, I'm
I'm actually just exhausted because I've been working

757
01:07:23.599 --> 01:07:30.599
on been working on a bunch of
stuff for Super Tuesday because I'm involved in

758
01:07:30.000 --> 01:07:34.239
the state politics stuff here. So
I'm just gonna end my picks there and

759
01:07:34.280 --> 01:07:40.039
just remind you if you want to
hire me to let me know, Steven,

760
01:07:40.079 --> 01:07:47.159
what are your picks? Yeah,
so I am friends with bull Drapper

761
01:07:47.599 --> 01:07:54.840
who built and maintains the Flex jump. If anybody has heard of that,

762
01:07:54.920 --> 01:07:58.239
and if you haven't, let me
give you a quick intro there. Flex

763
01:07:58.519 --> 01:08:05.480
is a view component gem for Ruby, not the view component gem, but

764
01:08:08.239 --> 01:08:16.479
a gem for writing views in Ruby. And specifically it does everything in Ruby

765
01:08:16.600 --> 01:08:25.600
right, so it maps elements to
method names, and attributes to keyword arguments

766
01:08:25.840 --> 01:08:34.479
and children to blocks. It's a
really great gem and specifically, lately the

767
01:08:34.479 --> 01:08:41.159
core team has been working on a
really awesome feature that I want to make

768
01:08:41.199 --> 01:08:45.720
sure as many people as possible know
about because I actually think it can you

769
01:08:45.800 --> 01:08:48.840
know, I hate to even say
these words, but I think it could

770
01:08:48.920 --> 01:09:00.359
possibly revolutionize how we do our Rails
applications. And so what is the feature.

771
01:09:00.399 --> 01:09:05.920
The feature is selective rendering on the
server side. So conceptually it is

772
01:09:06.199 --> 01:09:10.760
very similar to how turbo frames work. Right, So you have a turbo

773
01:09:10.760 --> 01:09:16.000
frame on your page, it has
id turboframe one, and you click a

774
01:09:16.000 --> 01:09:23.359
link inside of that turbo frame the
way that would be managed by Rails presently,

775
01:09:23.640 --> 01:09:28.119
It's like that link gets sent up
to your application. The controller processes

776
01:09:28.159 --> 01:09:31.640
it, finds the appropriate view,
renders that view, sends that view back

777
01:09:31.680 --> 01:09:35.119
down to the client. On the
client side, there is javascriup that says,

778
01:09:35.279 --> 01:09:39.560
oh, you know, this is
a response from a turbo frame request

779
01:09:39.560 --> 01:09:45.439
that we made. We made that
request from turbo frame one. Let's parse

780
01:09:45.600 --> 01:09:49.600
this view and find where turbo frame
one sits inside of it, will pull

781
01:09:49.600 --> 01:09:55.520
it out, throw all the rest
of it away, and replace the contents

782
01:09:55.520 --> 01:10:01.680
of turbo frame one with the new
contents of turbo frame one. So you

783
01:10:02.479 --> 01:10:09.640
on the server, you're rendering everything, so you have some waste, but

784
01:10:09.680 --> 01:10:13.199
you have the benefit that you get
to use your existing rails routes. You

785
01:10:13.239 --> 01:10:18.279
get to keep all of your existing
controller logic, rendering logic, database access

786
01:10:18.319 --> 01:10:24.800
logic, so you treat it as
if it's just a regular page visit.

787
01:10:27.000 --> 01:10:33.600
But you have excess content that is
sent in the response, and then on

788
01:10:33.640 --> 01:10:39.680
the client side you have to take
all of that content. You have to

789
01:10:39.720 --> 01:10:45.239
parse it and find the subsection to
pull it out and replace the frame.

790
01:10:45.800 --> 01:10:53.239
The feature that flex is adding now
allows you to do that exact same thing,

791
01:10:53.319 --> 01:10:55.920
but all on the server side.
Right, So you send a request

792
01:10:55.960 --> 01:11:00.319
up from turbo frame one and you
say, hey, I want to reframe

793
01:11:00.359 --> 01:11:06.600
one. It's just a regular link
to a regular normal route. Controller receives

794
01:11:06.640 --> 01:11:11.359
it, goes to render it.
It's rendering a flex view and not an

795
01:11:12.159 --> 01:11:18.479
action pack view. And that flex
view is past the content that that or

796
01:11:18.520 --> 01:11:24.199
that context that hey we want turbo
frame one. And so now all of

797
01:11:24.239 --> 01:11:28.720
your flex views it'll start rendering,
and it's just gonna no op all of

798
01:11:28.720 --> 01:11:31.800
those methods. You know, so
your HTVL, your body tag, your

799
01:11:31.960 --> 01:11:34.640
H one tag, your all of
that. Okay, if those are methods,

800
01:11:34.680 --> 01:11:40.920
we're just going to no opt them
until it finds the method that has

801
01:11:41.039 --> 01:11:44.439
id turbo frame one. It's like, oh okay, now it's time to

802
01:11:44.479 --> 01:11:50.920
actually render. And so then flex
will render all of that content, package

803
01:11:50.960 --> 01:11:59.279
it up and send back just that
give or section frame whatever you know.

804
01:11:59.800 --> 01:12:03.479
Uh, So you get two or
I guess three big benefits. So the

805
01:12:03.520 --> 01:12:11.840
one is you get to keep the
same simplicity of your rail application getting to

806
01:12:11.920 --> 01:12:18.039
be structured as if all of the
interactions you're doing are standards stateless HTTP interactions,

807
01:12:18.479 --> 01:12:24.359
full page refreshes. You don't have
to set up a whole sort of

808
01:12:24.399 --> 01:12:30.880
like separate components name space where you
render specific things, but you get the

809
01:12:30.880 --> 01:12:39.479
second benefit of sending the minimally small
payloads over the wire only the content that

810
01:12:39.520 --> 01:12:43.159
you need, with the third benefit
being that you only have to render the

811
01:12:43.159 --> 01:12:46.279
content that you need, so you're
rendering times actually speed up as well.

812
01:12:49.359 --> 01:12:57.760
So this is available now in like
the alpha release of Flex, it will

813
01:12:57.800 --> 01:13:04.760
be generally available when they least version
one ten. And we're doing a lot

814
01:13:04.760 --> 01:13:09.399
of thinking and a lot of work
now to really make the integration with hot

815
01:13:09.439 --> 01:13:16.239
wire and turbo as seamless as possible. But I think that this kind of

816
01:13:16.800 --> 01:13:24.600
general shift in thinking and leveraging these
kinds of tools is going to be really

817
01:13:25.800 --> 01:13:32.600
useful and valuable for rails applications.
So that is my pick. Black selective

818
01:13:32.600 --> 01:13:40.199
rendering awesome, very cool. All
right, one last question. If people

819
01:13:40.239 --> 01:13:42.880
want to find you on the internet, where are you? Yeah? So

820
01:13:42.960 --> 01:13:46.920
I have fractled Mind on Twitter and
get hub. My blog is Fractledmind dot

821
01:13:46.960 --> 01:13:53.680
GitHub dot io. And if you
want to meet up in person or you

822
01:13:53.840 --> 01:13:59.000
just want to get more confident and
comfortable with building rails applications with sqlight,

823
01:14:00.039 --> 01:14:03.560
I am going to be at Rails
comp in Detroit in May and I am

824
01:14:03.840 --> 01:14:11.600
hosting or leading a workshop there on
the second day on building rails applications with

825
01:14:11.680 --> 01:14:17.039
people, and we're going to cover
everything that I know and as much as

826
01:14:17.039 --> 01:14:21.319
that as possible. So the goal
is that coming out of that everyone will

827
01:14:21.359 --> 01:14:30.239
feel comfortable and confident with using this
stack and using these tools. So a

828
01:14:30.279 --> 01:14:35.560
lot of exercises and content. There
will be a fun to our workshop and

829
01:14:36.159 --> 01:14:43.920
otherwise happy to meet up and have
a soda with anyone in Detroit as well

830
01:14:43.960 --> 01:14:48.600
if you're going to be there for
Rails comp awesome. All right, Well

831
01:14:49.039 --> 01:14:53.119
let's go ahead and wrap up.
Thanks for coming Steven, This was awesome,

832
01:14:54.520 --> 01:14:59.079
Thank you, all right, till
next time, folks, max out

833
01:15:00.079 --> 01:15:02.359
in the in