00:00:11.240
so the vision that David presented
00:00:14.599
yesterday for rails was exciting wasn't
00:00:18.119
it
00:00:19.720
yeah this vision of rails as a kind of
00:00:24.720
rocket engine that can launch your idea
00:00:28.960
from Hello World to IPO is bold and
00:00:34.120
beautiful but for those of us who have
00:00:37.239
already embraced this new no pass
00:00:40.480
mindset I expect that you like me have
00:00:43.960
probably felt like you needed to be a
00:00:46.160
kind of rocket scientist to then deploy
00:00:50.559
and run your application in
00:00:53.399
production and that makes sense because
00:00:57.160
much like rocket engines having
00:01:00.519
really grown more complicated and larger
00:01:03.519
with time when you look at what we might
00:01:06.200
call the standard web application
00:01:08.799
architecture that has also only grown
00:01:11.799
more
00:01:13.240
complex if you take a typical Heroku
00:01:16.680
application from 15 years ago sure it
00:01:20.560
was a distributed system but it was
00:01:24.320
understandable and
00:01:26.119
manageable well this is the typical hero
00:01:29.920
U application today where the number of
00:01:33.079
services and servers has
00:01:36.159
tripled and I'm sure that many of you
00:01:39.439
like me when I first saw this think well
00:01:42.240
this must simply be the cost of running
00:01:46.520
production grade
00:01:48.880
systems and it's easy enough to believe
00:01:52.280
that
00:01:53.399
complexity is the price we have to pay
00:01:56.960
for
00:01:58.280
progress but that's not always
00:02:01.640
true sometimes progress is
00:02:05.560
simplification sometimes progress is
00:02:08.200
removing moving Parts shrinking the
00:02:11.000
surface area of the system yet still
00:02:14.200
somehow expanding its functionality and
00:02:19.120
power so my name is Stephen you might
00:02:22.319
know me as fractal mind on Twitter and
00:02:25.840
today I want to show you my vision for
00:02:30.160
how rails 8 and sqlite together
00:02:33.840
supercharge rails as the oneperson
00:02:38.040
framework I want to present the
00:02:42.879
possibility of building
00:02:45.720
applications that have all of this power
00:02:49.760
but are this lean and this
00:02:53.159
simple because believe it or not this is
00:02:57.519
a viable application AR architecture
00:03:01.319
today and one that can serve tens of
00:03:04.959
thousands of
00:03:07.400
users you see to extend the metaphor
00:03:11.760
like liquid methane and liquid oxygen in
00:03:14.239
a rocket engine sqlite and rails when
00:03:18.239
mixed form a potent
00:03:21.920
combination on the one hand you have
00:03:24.040
rails with its two decades of battle
00:03:28.000
tested Solutions extra Ed from real
00:03:30.879
production
00:03:32.400
systems and on the other hand you have
00:03:35.000
sqlite with its three decades of
00:03:38.000
refinement of this vision of having a
00:03:43.360
operationally minimal embedded database
00:03:46.519
with just a single file on disk and an
00:03:48.920
executable that runs in your application
00:03:51.200
process and when you mix this conceptual
00:03:55.120
compression with this operational
00:03:57.599
compression you get powerful and
00:04:01.000
explosive results in what is a
00:04:04.360
remarkably lean and simple
00:04:07.200
application so what I want to do today
00:04:09.840
is show you
00:04:11.799
how and to start I want to retread some
00:04:17.239
of the ground that David went over
00:04:18.639
yesterday to show you how rails 8
00:04:22.360
specifically makes the rails new command
00:04:25.280
production
00:04:27.120
ready rails has always been a full
00:04:31.280
featured framework that came with all of
00:04:34.360
the components that you would need for a
00:04:36.880
full featured web application and many
00:04:40.240
of those components require some form of
00:04:43.919
persistent data we could call these the
00:04:47.360
datab bound components of rails and a
00:04:51.400
full-featured application is going to
00:04:53.919
need a data store to back each of
00:04:57.360
these and of course rails is a modular
00:05:00.400
framework so each component has various
00:05:03.919
adapters to work with different data
00:05:07.080
stores with version seven of rails when
00:05:10.280
you run rails new these are the
00:05:12.600
production defaults that you would
00:05:14.600
see and there's nothing broken or wrong
00:05:18.440
about these defaults but these are not
00:05:21.039
production ready Plug and Play
00:05:25.080
Solutions the async adapter for jobs
00:05:28.240
right is fast and simple locally but if
00:05:30.520
you run that in production you are going
00:05:32.600
to lose jobs on deploys or
00:05:36.479
restarts and the file system for caching
00:05:39.639
works great if you have a persistent
00:05:42.280
file system if you're on Heroku it's not
00:05:45.840
so great when your entire cache is
00:05:47.880
randomly
00:05:50.520
wiped well the red is adaptive for
00:05:52.840
Action cable that's certainly production
00:05:54.960
grade software but it isn't Plug and
00:05:57.319
Play you have to have a redus in
00:05:59.680
instance configured and running and
00:06:01.759
connected to your application in
00:06:03.479
production so sure production ready but
00:06:06.840
not Plug and
00:06:08.919
Play This is the major change with rails
00:06:12.680
8 with rails 8 you get an outof the-box
00:06:15.840
experience that is both production ready
00:06:18.919
and plug
00:06:21.280
andplay with version 8 when you run
00:06:23.680
rails new you're going to see these
00:06:26.599
notably
00:06:28.039
different defaults for the central datab
00:06:31.479
bound components of rails this Suite of
00:06:34.919
solid gems provide production ready
00:06:38.560
flexible and scalable
00:06:41.160
defaults for these
00:06:45.000
components and these database backed but
00:06:49.240
database agnostic of course you can use
00:06:51.199
them with postris you can use them with
00:06:52.680
my
00:06:53.400
SQL I hope by the end of this talk
00:06:56.319
you'll be interested to use them with
00:06:57.879
sqlite
00:07:00.319
offer a solid foundation for active job
00:07:05.680
active support cach and action
00:07:08.240
cable and I hope that you were here in
00:07:12.080
this room yesterday at this time to see
00:07:15.680
and here Rosa Tonk where she detailed
00:07:18.319
what makes solid Q truly production
00:07:21.400
grade software and last year at rails
00:07:24.840
World Donald introduced solid cache
00:07:27.639
detailing its thoughtful and again
00:07:30.560
production oriented
00:07:33.199
design and unfortunately Nick isn't able
00:07:36.919
to be here today but the work he has
00:07:39.520
done on solid cable allows you again to
00:07:43.800
have simple scalable agnostic default
00:07:48.319
experiences for your rails
00:07:51.400
applications but rails 8 being
00:07:53.680
production ready isn't simply about
00:07:55.759
these new defaults for rails components
00:07:57.960
because rails 8 also comes with an
00:08:01.479
improved out-of-the-box solution for
00:08:03.680
production deployments with
00:08:05.599
Kamal right Kamal offers everything you
00:08:09.199
need to deploy and manage your web
00:08:12.240
application in production with Docker
00:08:15.759
and yesterday Donald introduced the new
00:08:18.479
version of Kamal Kamal 2.0 and Kevin
00:08:21.720
introduced the new Kamal proxy so I hope
00:08:24.800
you were here to see what the future of
00:08:27.800
deploying and running rail applications
00:08:30.560
looks like but if you weren't you can
00:08:33.399
catch it on
00:08:35.000
YouTube all in all rails 8 provides the
00:08:38.279
tools that you need to go from Hello
00:08:41.599
World to hello web just with rails
00:08:46.040
new and these are the features and
00:08:49.120
details that make rails the oneperson
00:08:52.839
framework as David outlined in his
00:08:55.279
keynote last year and reiterated with
00:08:58.680
his hi coup this year rails aims to be a
00:09:02.399
bridge over
00:09:04.079
complexity that allows the smallest
00:09:07.120
possible team right you and your laptop
00:09:10.839
to build full Rich valuable web
00:09:15.839
applications and sqlite aligns perfectly
00:09:20.320
with that Vision I like to say that
00:09:23.240
sealite supercharges
00:09:26.240
rails because sqlite is what enables you
00:09:30.680
to go from the moderate complexity of a
00:09:34.120
minimally distributed system to the
00:09:37.240
radical Simplicity of an application and
00:09:41.480
all of its operational dependencies
00:09:43.720
living on a single
00:09:45.839
machine and this is possible because of
00:09:50.120
sqlite's unique
00:09:52.880
architecture most client server
00:09:55.720
databases run in a separate process
00:09:59.519
often on a separate
00:10:02.040
machine but sqlite runs embedded within
00:10:06.720
your Ruby process and the thread that
00:10:08.800
spawns it so it's not a database in the
00:10:13.320
way that you might be used to right it's
00:10:16.000
just a file on disk and an executable
00:10:20.320
that runs within your application
00:10:23.519
process nonetheless it is a full
00:10:27.480
featured SQL engine with CTE window
00:10:31.240
functions aggregations and anything else
00:10:35.000
from the SQL standard and many things
00:10:37.480
that aren't in the SQL
00:10:39.839
standard and this is stable
00:10:43.639
software sqlite's current major version
00:10:46.600
version 3 was released two decades ago
00:10:49.279
in
00:10:50.800
2004 and today there are an estimated 1
00:10:54.839
trillion sqlite databases in active use
00:10:58.880
around the globe making sqlite the
00:11:01.360
single most used database in the
00:11:06.000
world and I would forgive you if you
00:11:10.720
presume that an embedded
00:11:13.920
database could only possibly manage a
00:11:17.839
small fraction of the data that a proper
00:11:22.079
client server database can
00:11:24.760
handle but of course you would be wrong
00:11:28.560
sqlite can handle databases up to 280
00:11:33.639
terabytes or to put it otherwise you
00:11:36.800
won't hit its computational limits right
00:11:40.000
I
00:11:41.200
promise and when you pair the power and
00:11:45.000
simplicity of sqlite with Modern
00:11:47.959
Hardware hopefully you're starting to
00:11:49.920
get a sense of how sqlite enhances the
00:11:53.399
vision of rails as the oneperson
00:11:55.639
framework enabling us to radically
00:11:58.800
simplify ify our application's
00:12:01.000
operational
00:12:03.519
needs but as I say this I know that we
00:12:08.000
have had years and years of people
00:12:10.880
consistently saying that sqlite simply
00:12:14.839
doesn't work for web
00:12:18.399
applications indeed for the last few
00:12:20.519
years if you ran sqlite in production
00:12:22.959
rails would tell you it doesn't work go
00:12:27.040
elsewhere and the last time you read the
00:12:29.560
rails guides it explicitly warned you
00:12:32.519
against using sqlite in
00:12:35.240
production but this is an outdated point
00:12:38.680
of view and the reality is that today
00:12:42.440
this sentiment is a
00:12:45.240
myth and more and more people are
00:12:47.880
starting to realize
00:12:50.079
it the fact of the matter is that this
00:12:54.519
myth though persists for a reason it
00:12:58.320
does have Foundation
00:12:59.880
because sqlite in the context of web
00:13:02.560
applications is easily misunderstood and
00:13:07.079
misused you see unlike much of modern
00:13:10.399
software sqlite cares more about
00:13:14.040
backwards compatibility than it does
00:13:16.800
about enabling newer and more powerful
00:13:19.360
features by
00:13:20.959
default the maintainers care deeply that
00:13:24.760
a sqlite database created two decades
00:13:27.600
ago will be able to be opened by sqlite
00:13:31.480
two decades from now and that is one of
00:13:34.440
the key reasons why sqlite is the
00:13:36.680
archival format for Digital Data by the
00:13:39.720
US Library of
00:13:41.880
Congress but this means that for all
00:13:44.839
intents and purposes if you run sqlite
00:13:47.800
out of the box today it's as if you're
00:13:51.079
running sqlite as it was created 20
00:13:54.360
years ago and it's true 20 years ago
00:13:57.759
sqlite was not not well suited for web
00:14:02.120
applications so sqlite needs
00:14:06.440
fine-tuning and luckily over the last
00:14:09.160
two decades there have been many
00:14:12.160
features added to sqlite that do make it
00:14:15.600
suitable for web
00:14:17.680
applications all that is needed is to
00:14:20.279
fine-tune its configuration and its
00:14:23.240
usage and that is precisely what myself
00:14:27.800
and the rails core team
00:14:29.639
and the rest of the Rails Community have
00:14:32.639
been doing for the last year and a
00:14:36.880
half and that work is finally
00:14:39.720
culminating in rails
00:14:42.680
8 many of these pool requests have been
00:14:45.759
released in various previous versions of
00:14:48.000
rails but there are two in particular
00:14:50.320
coming out with rails 8 that weren't
00:14:53.639
special
00:14:54.800
consideration because these changes make
00:14:57.839
rails 8 the first version of rails and
00:15:00.519
as far as I know the first version of
00:15:02.880
any web application
00:15:05.480
framework that provides a fully
00:15:08.440
production ready sqlite experience out
00:15:12.480
of the
00:15:14.680
box so the two issues that hindered the
00:15:18.199
default experience of sqlite on Rails up
00:15:20.839
till
00:15:21.680
now were firstly that as your
00:15:25.519
application was put under more and more
00:15:27.920
concurrent load a growing percentage of
00:15:31.040
your requests would simply error out you
00:15:35.040
can see here that even at just four
00:15:37.120
concurrent requests nearly half of the
00:15:39.360
responses are errors and of course this
00:15:42.600
is utterly unacceptable for
00:15:45.240
production the second problem related to
00:15:48.800
your application's tail latency under
00:15:51.519
again increasing concurrent load you
00:15:53.800
would see your P99 or even eventually
00:15:56.120
your P95 latency Skyrocket
00:15:59.759
and when some requests are taking five
00:16:01.959
plus seconds to
00:16:03.360
respond it's fair to say this is not
00:16:06.279
production ready
00:16:09.040
software both issues arise from the
00:16:12.160
nuances of using an embedded database in
00:16:16.440
a multi-threaded web
00:16:18.319
application since rail spins up multiple
00:16:21.360
threads to process incoming requests and
00:16:24.199
each thread has its own embedded
00:16:26.160
connection to the sqlite database in
00:16:28.560
fact it its own connection pool rails
00:16:31.199
must ensure firstly that those
00:16:33.720
connections don't
00:16:35.519
conflict but also that they don't
00:16:39.800
block and to ensure that these embedded
00:16:43.240
connections don't conflict with each
00:16:45.040
other we have to make changes to the
00:16:47.040
ways in which rails manages transactions
00:16:49.759
for sqlite
00:16:53.199
databases and to ensure that these
00:16:56.199
connections don't block each other and
00:16:58.199
create these problems we actually had to
00:17:01.040
work on a pair of pull requests one in
00:17:03.000
the lower level sqlite gem which is the
00:17:06.959
engine that drives sqlite through Ruby
00:17:10.039
and then the other in rails to make use
00:17:11.880
of this feature now unfortunately I
00:17:14.600
don't have the time today to dig into
00:17:16.720
the technical details but if you are
00:17:18.880
interested in learning more I have an
00:17:20.959
in-depth post on my blog that walks
00:17:23.319
through every detail of these changes
00:17:25.400
the nature of the problems the reasoning
00:17:27.439
behind the solutions and the details of
00:17:29.360
the
00:17:30.559
implementation but details aside the
00:17:33.080
results speak for themselves not only do
00:17:36.440
we no longer see errored responses but
00:17:39.400
our P99 latency is literally improved
00:17:42.400
1,000 times under heavier concurrent
00:17:45.400
load and in fact we can see that these
00:17:48.240
improvements Hold Steady even for the
00:17:50.880
very slowest requests in our
00:17:54.880
Benchmark these configuration and usage
00:17:57.760
changes require nothing of you in your
00:18:00.720
application code and they unlock the
00:18:03.520
full power and speed of sqlite which now
00:18:07.039
make sqlite a viable production
00:18:11.400
option you can now back four out of the
00:18:14.480
five data bound components of rails with
00:18:17.280
sqlite without
00:18:19.840
compromise and this is precisely what
00:18:23.159
unlocks this architecture as a viable
00:18:26.360
option a full featured rails application
00:18:30.799
with no compromises on features or
00:18:33.679
performance all running on a single
00:18:37.039
machine now again I recognize that this
00:18:40.679
is a somewhat radical suggestion and I
00:18:44.120
expect that many of you are thinking
00:18:45.640
right now that this architecture
00:18:48.039
couldn't possibly serve production level
00:18:53.039
workloads so let's quickly investigate
00:18:56.960
and I want to start with using the
00:18:58.960
campfire app released earlier this year
00:19:01.120
by 37 signals both because it's a full
00:19:05.200
production grade full featured
00:19:07.360
application but also because the team at
00:19:09.720
37 signals that built it provided a load
00:19:12.080
testing tool in the source code itself
00:19:16.200
now campfire does not go all in on
00:19:19.320
sqlite it was built before all of these
00:19:22.240
Solutions were in the framework but
00:19:24.240
rails is a modular framework so I just
00:19:27.039
swapped the adapters out and as a side
00:19:29.880
note this took me literally 45
00:19:33.919
minutes and once I had the solid gems in
00:19:37.559
place rails 8 as the version of rails I
00:19:40.400
ran their load tests and again the
00:19:44.480
results speak for themselves whether
00:19:46.919
you're looking at the number of
00:19:48.360
connections spawned or the number of
00:19:51.240
messages received the campfire on sqlite
00:19:54.200
Fork performs just as well as the
00:19:56.840
standard campfire build and the team at
00:19:59.679
37 signals ran load tests on big beefy
00:20:03.080
servers and they were able to handle
00:20:04.919
50,000 concurrent users no
00:20:07.679
problems but we don't have to only look
00:20:10.400
at this speculative load test there are
00:20:12.440
applications today that are running on
00:20:14.880
this architecture this is the Ruby video
00:20:17.960
app built by my friend Adrien Polly it
00:20:20.440
runs on a single $4 a month hetner box
00:20:23.760
with sqlite backing all of its IO needs
00:20:26.440
and it has served millions of requests
00:20:28.960
with an average response time of less
00:20:30.720
than 100 milliseconds and it has four
00:20:33.360
nines of up
00:20:35.240
time I have also been running
00:20:37.600
applications in production with sqlite
00:20:39.919
unfortunately they're all proprietary
00:20:42.280
and associated with ndas with big
00:20:44.200
corporations but I can tell you that
00:20:47.480
these applications have been running
00:20:49.679
smoothly for three years they have
00:20:53.039
driven millions of dollars in revenue
00:20:55.480
and they have never had a complaint from
00:20:57.640
customers or or from the
00:21:00.679
business of course recently Tech Twitter
00:21:03.440
has been chatting incessantly it seems
00:21:05.320
about Peter levels' setup where he runs
00:21:08.440
multiple successful applications all
00:21:11.159
backed by sqlite on a single beefy
00:21:14.080
VPS and as a reminder single server
00:21:16.679
deployments have been serving rails
00:21:18.240
applications quite well since day
00:21:21.360
one so yes it really is possible to run
00:21:25.360
a full-featured rails application in
00:21:27.880
production with no compromises on a
00:21:30.840
single
00:21:32.159
machine so I hope that you trust me or
00:21:35.600
you're at least beginning to trust me
00:21:37.480
when I say that this idea is a
00:21:40.000
myth and next year I'm hoping to hear
00:21:43.120
stories from some of you about
00:21:45.840
applications that you have created and
00:21:47.760
are now running for months successfully
00:21:50.679
so we can add even more evidence to show
00:21:54.039
that this is simply no longer the
00:21:56.559
case but I don't want to stand here and
00:22:00.360
make it seem like this is some sort of
00:22:02.360
Silver Bullet because it isn't there are
00:22:05.320
use cases where this architecture shines
00:22:07.840
and those where it
00:22:09.360
doesn't and there are areas where you do
00:22:12.120
need to be
00:22:14.600
considerate firstly when running SQL
00:22:17.679
item production you need to have a solid
00:22:20.720
backup mechanism set up and I know this
00:22:24.000
because I have deleted my production
00:22:25.919
database and it was not a fun on
00:22:29.640
weekend I think that the best tool for
00:22:31.720
the job is light stream this is a
00:22:33.520
utility that streams each change to your
00:22:36.919
database to some S3 compatible bucket
00:22:39.880
storage system that you have
00:22:42.279
configured you could even stream it to
00:22:44.240
an FTS server that you've set up if
00:22:46.159
that's your cup of tea so you get point
00:22:48.480
in time backups with incredibly cheap
00:22:51.480
storage costs and since it's only a
00:22:54.000
single go executable I've wrapped it up
00:22:55.880
in a pre-compiled binary gem so
00:22:57.919
installation is a breeze and the gem
00:23:00.760
provides a puma plugin so you could
00:23:02.360
manage the replication process with a
00:23:05.159
simple single line in your config so it
00:23:08.720
truly is a plug- Inplay solution and it
00:23:11.480
even ships with a verification job that
00:23:13.679
you can schedule to run continuously
00:23:16.559
every day at midnight if you want to
00:23:19.200
verify that your backup system is
00:23:22.960
working aside from data resilience
00:23:25.480
probably the most common worry I hear
00:23:27.360
centers on the fact that sqlite only
00:23:29.240
currently supports linear
00:23:31.279
rights and the worry is that only having
00:23:33.760
one operation at a time will prevent
00:23:36.640
your application from scaling whatever
00:23:39.840
that might mean but this worry is
00:23:42.360
overblown firstly most applications are
00:23:45.440
read heavy not write heavy so likely
00:23:47.880
only around 20% of your traffic is wrs
00:23:51.159
plus we easily forget what a difference
00:23:54.080
it makes when you're using an embedded
00:23:56.919
database even if if you are running
00:23:59.200
postgress on the same machine as your
00:24:01.240
application the simple interprocess
00:24:03.840
communication overhead means that you
00:24:05.440
could execute 10 sqlite queries linearly
00:24:08.760
in the same amount of time that it takes
00:24:10.320
to run one postgress queries and as
00:24:13.640
applications are generally moving away
00:24:15.279
from self-hosting and managing the own
00:24:16.840
database server and Cloud databases are
00:24:19.200
more popular than ever when using a
00:24:21.720
cloud database even if it is in a
00:24:24.480
neighboring region you could run 600
00:24:27.399
sqlite queries in the time it takes you
00:24:29.840
to execute that one postgress query so
00:24:32.880
when you go from a client server
00:24:34.640
database architecture with network
00:24:36.159
latency to an embedded database your
00:24:39.080
queries go from being measured in
00:24:40.600
milliseconds to
00:24:42.640
microseconds and that mostly erases the
00:24:46.720
problems that you might think come from
00:24:48.799
only allowing linear
00:24:50.960
rights but if you are ingesting lots of
00:24:54.000
data and by a lot I mean something on
00:24:56.399
the order of magnitude of like 50,000
00:24:58.640
rights per
00:24:59.760
second probably sqlite won't work for
00:25:02.520
you use postgress use my SQL that's fine
00:25:05.520
use the tool that's best for your
00:25:07.559
problem but if you're not at that level
00:25:10.360
sqlite is going to work fine and have no
00:25:12.840
meaningful impact on your application
00:25:15.960
performance but linear rights do mean
00:25:19.080
that you have to be thoughtful about
00:25:20.760
migrations if you have a long running
00:25:23.520
and right intensive migration like
00:25:26.520
adding a new index to a table with a
00:25:28.520
million or 10 million rows that
00:25:30.840
migration will impact your application's
00:25:33.640
performance and there are currently no
00:25:35.840
popular or battle tested solutions to
00:25:37.679
get around this limitation so be aware
00:25:40.159
that such migrations are going to be
00:25:41.760
handled much more simply with just
00:25:45.120
scheduled
00:25:47.039
downtime in general getting familiar and
00:25:50.640
comfortable with scheduled downtime is
00:25:53.000
going to be useful if you want to
00:25:54.600
embrace sqlite because sqlite works best
00:25:57.600
on a single machine and this means that
00:26:00.240
as you need to scale you should simply
00:26:02.880
expand the size of that machine over
00:26:05.200
time now there's a fair chance that many
00:26:07.919
of you imagine that the size of machine
00:26:11.480
that you can rent is relatively limited
00:26:15.120
but you can rent a really big box like a
00:26:19.799
really really big box any person who
00:26:23.520
signs up on hetner can get a 48 core 19
00:26:28.320
2 gig of RAM one terabyte of nvme SSD
00:26:31.679
space for $350 a month that thing is a
00:26:36.279
beast and it's available to all of us so
00:26:39.720
don't put an artificial ceiling on how
00:26:41.760
far vertical scaling can take an
00:26:44.279
application and I know that we've all
00:26:46.480
been told for the last decade that the
00:26:48.240
only correct way to build web apps is
00:26:50.880
with redundancy and high availability
00:26:53.960
and automatic failovers and zero to
00:26:56.279
Infinity Auto scaling and everything
00:26:58.039
else else but the fact is that these are
00:27:00.440
solutions to problems that a minority of
00:27:02.919
web applications do have or will ever
00:27:06.039
have and they come with real tradeoffs
00:27:09.200
around operational complexity we need to
00:27:12.320
remember that the larger the surface
00:27:14.240
area of our systems the more
00:27:16.520
opportunities for
00:27:18.720
failures so ask yourself do you truly
00:27:22.360
need all of that especially on day one
00:27:26.360
or should you start with a stack that is
00:27:28.640
simple enough to keep in your head yet
00:27:30.960
powerful enough to serve all of your
00:27:32.840
customers
00:27:34.080
needs so like any tool sqlite comes with
00:27:37.880
tradeoffs and you need to learn that
00:27:40.799
tool its quirks and idiosyncrasies if
00:27:42.799
you want to make maximal use of it but
00:27:45.480
when you choose High leverage tools
00:27:48.320
tools that are well built and well known
00:27:51.360
tools that might be considered boring
00:27:54.080
you unlock the power of simplicity
00:27:58.559
and you truly can build an application
00:28:00.919
that has the power to take your next
00:28:03.640
idea to IPO but you don't need to be a
00:28:07.880
rocket scientist to run it rails 8 and
00:28:11.399
sqlite strip away all of the incidental
00:28:14.799
complexity leaving you with the leanest
00:28:18.240
simplest but most powerful application
00:28:20.919
stack that I could imagine and few
00:28:24.799
things are as powerful as the tools that
00:28:27.960
have have earned their Simplicity
00:28:29.960
through years of evolution and
00:28:34.320
consideration these are the kinds of
00:28:36.679
engines that Empower individuals to
00:28:39.760
build production grade full-featured
00:28:43.240
valuable applications faster simpler and
00:28:46.880
cheaper than ever before and I really
00:28:49.960
truly believe that we are on the cusp of
00:28:54.200
a new wave of opportunity for rails
00:28:56.760
developers to to make their stand in the
00:29:00.799
greater Marketplace of the internet and
00:29:05.159
pursue their dream of building something
00:29:08.600
that can sustain their livelihoods while
00:29:12.000
pursuing their
00:29:15.120
interests sqlite and rails are a unique
00:29:18.760
pair a powerful pair and I hope that
00:29:21.720
after this exploration you better
00:29:23.840
understand and appreciate how well
00:29:25.880
sqlite pairs with rails as an engine for
00:29:28.480
creativity and building and I hope you
00:29:31.399
feel confident that you could or even
00:29:33.399
that you might want to build and run
00:29:36.240
your next rails application going all in
00:29:38.919
on
00:29:39.919
sqlite so thank you