00:00:11.000
Good morning! I hope everyone who went running today is still out there.
00:00:18.330
Oh good! Well, I’ve never actually done the 5k, but I’ve always wanted to.
00:00:23.400
Then I find out it’s at like 7:00 or something, and that’s when I wake up to go running. So cool!
00:00:33.090
First, I want to say thank you to the organizers. This wouldn't be possible without them putting it all together.
00:00:39.989
So let’s give a round of applause for the organizers and sponsors, and everybody who makes this happen.
00:00:50.420
I'm Eileen Uchitelle. I live in Kingston, New York, which is about two hours north of New York City.
00:00:56.850
It's about a seven and a half hour drive to Pittsburgh. My flight was canceled, so I did the math.
00:01:03.870
Getting in a car was going to be faster than waiting for Newark Airport to get their act together.
00:01:10.830
You can find me online at the handle EileenCodes, and I occasionally blog at EileenCodes.com.
00:01:16.409
I’m a senior systems engineer on GitHub’s App Systems team. We do a lot with open source, Rails, Ruby, and Rack.
00:01:26.009
We focus on how these technologies interact with the GitHub application, keeping GitHub up to date.
00:01:32.009
I’m also a member of the Rails core team. For anyone new to the Rails community, the core team is responsible for defining the future of Rails.
00:01:38.579
We manage releases, fix issues, and handle all the good and bad that comes with releasing new versions of Rails.
00:01:45.750
If you’ve been in the Rails community for any amount of time or just saw Mark’s clickbait title yesterday,
00:01:51.180
you’ve probably heard the phrase 'Rails doesn’t scale.' We’ve heard it on Hacker News, in various NBC meetings,
00:01:58.380
and we even heard it in a misguided Vanity Fair article about Twitter, claiming they couldn't effectively combat harassment.
00:02:04.320
They referred to Rails as 'Fisher-Price software.' It’s funny because they meant it as an insult, saying Rails is for children.
00:02:12.680
But Fisher-Price and Rails are actually alike in that they are robust, well-designed, and unforgettable.
00:02:20.270
The interesting thing about Rails getting a bad rap for not being scalable is that it has taken many companies to a scale they never dreamed of.
00:02:25.730
If Twitter had tried to build their app to handle the scale it is today, they probably would have gone bankrupt before having proof-of-concept.
00:02:31.520
The reality is that Rails does scale; it just doesn’t scale easily. Historically, Rails hasn’t done a great job at making scaling easy.
00:02:40.520
While we pride ourselves on developer happiness, we were missing the mark on scaling and frankly falling short.
00:02:46.490
In this talk, we’re going to look at ways Rails has struggled with scalability and what we plan to do about it.
00:02:54.950
I want scaling Rails to be as enjoyable as running the Rails new command.
00:03:01.580
Scaling means different things depending on who you’re talking to or what your app is supposed to do.
00:03:06.890
For the purpose of this talk, scalable means that over time, an application’s growth in code, data, and traffic doesn’t degrade its performance.
00:03:14.269
While Rails can’t handle every aspect of scaling in your web application, there are two important areas I want to focus on.
00:03:22.010
The first is that when you scale your web application, your test suite shouldn’t block development.
00:03:27.830
As an application grows, new code shouldn’t create a ton of friction. Developers should easily prototype and build features quickly.
00:03:34.519
The time it takes for your test suite to complete shouldn’t hinder development. While we’ve made improvements to test performance in the past,
00:03:41.330
there's really no replacement for concurrent testing.
00:03:46.550
The other area where Rails has struggled with scalability is in handling increased data and traffic over time.
00:03:52.040
The database shouldn’t crash due to increased users or excessive data. It should be easy to distribute the load across your database.
00:03:59.209
Rails has had support for multiple databases, but that support is undocumented, hard to understand, and difficult to implement.
00:04:04.880
While Rails can’t tackle scaling every part of your application, I believe we can improve developer happiness around these two main issues.
00:04:11.720
My goal is to tackle these issues to make Rails 6 scalable by default.
00:04:18.820
Scalable by default means that engineers can scale their Rails application without having to spend hours writing a custom setup or using many external tools.
00:04:24.130
Scaling your application doesn’t have to be hard, and Rails should be able to take on at least some of that work.
00:04:29.440
Some of you may be thinking: 'Hold up, wait, Rails 5 just came out! Why is Eileen talking about Rails 6?'
00:04:34.810
Major versions of Rails allow us to reconsider what’s possible. It’s going to be a while before 6 is out, but I wanted to share my plans with you.
00:04:40.530
In the past few months, I’ve done a lot of work to refactor Rails and add features to make scaling easier.
00:04:47.169
We’ll look at what’s been done to speed up your test suite and improve Rails’ multiple database handling to ensure scaling is simple and intuitive.
00:04:52.360
The first feature I’d like to introduce for Rails 6 is parallel testing.
00:05:01.240
The parallel testing feature will allow you to run your tests concurrently using either forked processes or threads.
00:05:06.150
Parallelizing test suites is crucial for scaling web applications because as you add more code and tests, execution time increases.
00:05:12.610
You can mock a lot of calls or ensure you’re not making external requests, but that won’t speed up the time it takes to run ten thousand tests linearly.
00:05:18.780
Parallelizing large test suites can significantly reduce the wait time for builds to finish.
00:05:25.180
Many other companies like GitHub, Shopify, and others have been writing their own implementations of parallel testing for years.
00:05:31.610
The problem with us each writing our implementations is that we weren't sharing our ideas with the broader community.
00:05:37.320
Rails is popular for taking the complexity out of your app and turning it into reusable generic code.
00:05:44.640
By adding parallel testing to Rails, we set a standard for parallelization and make it simple to scale your test suite.
00:05:52.120
Earlier this year, Aaron Patterson and I worked together to write the parallel testing feature in Rails, based on the parallel testing infrastructure at GitHub.
00:05:58.150
While inspired by the GitHub code, the code in Rails has been rewritten to have a smaller footprint, be more generic, and easier to use.
00:06:05.660
Rails’ parallel testing also supports multiple databases out of the box, which was a requirement for us since we use several databases at GitHub.
00:06:12.430
The concurrent test runner in Rails 6 can parallelize your test suite using either forked processes or threads.
00:06:19.500
First, let’s take a look at the implementation for the forking parallelizer.
00:06:27.070
Forked process parallelization is implemented in Rails 6 using Distributed Ruby, also known as DRB.
00:06:34.150
DRB is a distributed object system in Ruby and can be implemented with zero dependencies.
00:06:41.350
The use of DRB is really cool and one of those features that I don’t think gets a lot of attention, so I encourage you to check it out.
00:06:48.420
Parallelization is invoked in your tests through the test helper with the parallelize method.
00:06:58.110
This method takes a workers argument, determining how many processes to fork.
00:07:04.720
Within Active Support, it’s backed by many tests.
00:07:10.630
When you start your test suite using the forking parallelizer, the Testing Parallelization class initializes with the number of workers you requested.
00:07:19.950
In the initialization method, we set a queue size, a server, and a URL instance variable.
00:07:28.250
The URL starts the DRB server locally and represents the URI for the server.
00:07:34.180
Parallelization in Rails is supported by MiniTest.
00:07:40.600
Once this class is initialized, all other methods within the class are actually called by MiniTest executors.
00:07:46.690
MiniTest will call the start method in the parallelization class, which starts an empty pool array to a block that forks the processes.
00:07:54.960
It then calls the after fork hook, allowing Active Record to hook into the parallelization code to create a database for each process.
00:08:01.600
After forking, a DRB object is created that represents the queue of work to perform.
00:08:08.380
The loop runs a method that executes the assigned tests for each parallel process.
00:08:14.390
At the end of the test suite run, each process will report which tests passed and failed.
00:08:23.649
Finally, the MiniTest call of shutdown will empty the queue and wait for each process to terminate.
00:08:30.240
This is essentially the entire implementation of work process parallel testing in Rails 6.
00:08:36.540
The underlying implementation is really simple and is only about 100 lines of code.
00:08:42.830
Don’t worry if you didn’t follow everything; you don’t need to know how it works to use parallel testing in Rails 6.
00:08:48.380
For newly generated Rails 6 applications, parallelization will be automatically included in your test helper.
00:08:56.040
For upgraded applications, you just need to call parallelize in your test helper.
00:09:02.540
The parallelize method takes a workers argument that accepts an integer. The default number of workers is two.
00:09:09.270
This means that Rails will automatically fork your tests into two processes, creating a separate database for each.
00:09:15.780
Each database is suffixed with the worker number, starting with zero.
00:09:22.480
These databases are generated in the after_fork hook we looked at earlier, then automatically deleted before the processes terminate.
00:09:29.780
Active Record and parallel testing do all this work for you, so no extra effort is required.
00:09:35.900
For those using multiple databases in their Rails application, we also provide hooks to handle additional databases.
00:09:41.780
The parallelize_setup hook is called after the fork and can be used to set up your secondary databases.
00:09:48.220
The parallelize_teardown method is used to clean up your work databases.
00:09:54.779
Using these hooks allows for a more streamlined process without complicated code.
00:10:01.680
If you're using a single database, you won’t need to use these hooks because Rails automatically manages the databases.
00:10:07.820
As you can see, the API for forked parallelization is relatively simple and easy to use.
00:10:14.650
The other type of parallel testing that Rails 6 provides is threaded testing.
00:10:20.460
You'll want to use threads instead of processes in some cases.
00:10:27.300
For example, if you’re using Windows because UNIX sockets that DRB relies on aren't supported.
00:10:33.650
You might also want to use threads if your tests are I/O bound.
00:10:41.500
Most of your tests are not I/O bound, but if they are, they’ll run faster with the threaded parallelizer.
00:10:46.420
The caveat, though, is that your code must be thread-safe to use the threaded parallelizer.
00:10:54.400
The parallelize method can take a second optional argument that defaults to processes.
00:11:02.070
Setting it to two threads is that simple.
00:11:09.240
The parallelize setup and teardown hooks are not supported by the threaded parallelizer as it uses a single database.
00:11:15.640
When running tests in a suite, they must use the same type of parallelization or number of workers.
00:11:23.020
For example, you can’t pass five workers to one set of tests using threads and three workers to another set.
00:11:31.000
If you need different behaviors, split your tests into two separate suites.
00:11:37.300
Threaded parallelization in Rails 6 uses MiniTest’s threaded executor.
00:11:44.030
We didn't have to write any additional code for the threaded parallelizer, since MiniTest already uses threads.
00:11:51.520
When Aaron and I started working on the threaded parallelizer, we experienced some challenges.
00:11:58.820
We were running tests and suddenly experienced random failures, deadlocks, and strange behavior.
00:12:07.020
We first assumed the issue was related to my demo app using multiple databases.
00:12:13.600
After switching to a new app with a single database, we observed the same issues.
00:12:19.680
We discovered that each thread was connecting to the database with the same connection ID.
00:12:27.420
This raised isolation problems. When I reviewed my earlier coding on system tests, I realized it was my fault.
00:12:34.360
When I implemented system tests, I enabled a connection to the database on one thread.
00:12:40.700
Capybara booted a Puma server, opening a second thread and second connection to the database.
00:12:46.700
This created inconsistent data between test runs because the transactions didn’t know about each other.
00:12:52.460
To fix this, each thread needed its own connection.
00:12:59.700
I realized this the moment I recognized that my previous code was creating this issue.
00:13:05.660
With the threaded parallelizer, threads should maintain their own connection to the database.
00:13:14.600
Fortunately, since I wrote the original problematic code, fixing it was relatively straightforward.
00:13:20.320
We added the ability to configure the setting internally, allowing each thread to open a separate connection.
00:13:27.780
However, system testing may not work with the threaded parallelizer.
00:13:34.520
While running your parallelized tests doesn’t require extra work, you can set them up in your test helper.
00:13:41.560
Simply run Rails test like you normally would, and Rails will handle the rest.
00:13:47.580
Sometimes, you may want to adjust the number of workers based on your environment.
00:13:55.920
For example, you might use two workers locally but 14 on CI.
00:14:02.060
Rails provides an environment variable called PARALLEL_WORKERS that takes precedence over workers passed in.
00:14:09.500
If the number of workers is one or fewer, parallelization won’t be applied.
00:14:14.800
If you’re interested in the PR for parallel testing, you can check it out on GitHub.
00:14:23.860
Parallel testing will enhance the speed of your test suite, and I'm excited about this feature.
00:14:31.660
Now that we've got your test suite squared away, let’s examine how Rails handles scaling under increased traffic.
00:14:39.330
I’m not talking about DDoS traffic; for that, you’d want to use an external vendor.
00:14:44.850
Instead, we’re discussing scaling because a high-profile user, like Justin Bieber, starts using your app.
00:14:50.380
You need to scale fast, and you need to scale yesterday.
00:14:57.950
I’ve been in these situations before, and it’s not fun.
00:15:04.920
You wake up to find your primary MySQL database struggling under the load.
00:15:11.190
You know you need to split tables from your primary MySQL cluster, needing read and write databases.
00:15:18.150
Rails has had support for multiple databases for a while; we use this at GitHub.
00:15:25.390
However, implementing this is an arduous task.
00:15:32.280
It took me three hours to incorporate multiple databases into a demo app in Rails 5, and that’s after I’d already done it.
00:15:39.260
For someone who has never worked on this kind of setup before, it would take even longer.
00:15:45.490
The difficulty stems from a lack of Rails standards.
00:15:50.080
Although the underlying plumbing works well, we're not providing straightforward documentation or the tools to utilize it.
00:15:56.730
The second key highlight we’ll discuss are improvements to using multiple databases with Rails.
00:16:03.010
These may not be flashy features like parallel testing, but they are critical for scaling web applications.
00:16:10.110
Multiple databases become necessary when a single instance can’t accommodate all the traffic.
00:16:16.890
If your application is crashing due to database issues, it may require splitting tables or adding read replicas.
00:16:22.580
At GitHub, we operate multiple primary databases with corresponding read replicas.
00:16:29.330
While Rails has supported multiple databases for a long time, thanks to work by Arthur Neves and Matthew Draper,
00:16:36.320
Rails 5 made it significantly easier than Rails 3 or 4 to handle.
00:16:43.919
However, as I set out to build a demo app using multiple databases, I quickly realized there was much missing.
00:16:50.070
Let’s explore what an application with multiple databases looks like, identifying where Rails falls short.
00:16:57.060
Imagine we have an application with two databases: one primary database with a flowers table and one animals database.
00:17:03.200
By default, Active Record is familiar only with the primary database connection.
00:17:10.430
To connect to and interact with the animals database, we face challenges.
00:17:17.060
For any setup involving multiple databases, best practices aren’t laid out in Rails.
00:17:24.780
There’s no documentation on how to structure your database YAML, models, and migrations for the secondary database.
00:17:31.341
Following our setup at GitHub, I initially structured my database YAML like this:
00:17:38.240
I used a two-tier configuration alongside the default production namespace and a second namespace for animals.
00:17:43.180
However, this might not be ideal and is no longer the recommended method with Rails 5.
00:17:50.240
Now, using a three-tier setup is best when you need multiple databases. This leads to clearer organization.
00:17:57.350
The 'primary' database is technically an arbitrary name; I recommend keeping it as 'primary' for clarity.
00:18:02.850
Next, we have the animals entry for managing tables of dogs and cats.
00:18:09.920
In the three-tier configuration, we can distinguish which databases belong to a production environment more easily.
00:18:16.340
If you utilize two-tier configurations, or even a single database per environment, you do not need to alter your settings.
00:18:23.260
Once the databases are set up, we must instruct Active Record where the migrations for the dogs and cats tables reside.
00:18:29.780
I’ve worked with migrations across multiple databases before, and a few options exist.
00:18:36.280
One option is to modify your migrations to set the connection at the beginning, which I don't recommend.
00:18:43.040
Instead, I prefer organizing all migrations for the animals database into a separate directory.
00:18:50.220
It's cleaner and more straightforward to group migrations by connection.
00:18:57.049
To use this method, however, we need to specify migration paths whenever we call migrate.
00:19:05.000
This works with custom rake tasks but is challenging with existing Rails code.
00:19:11.950
Existing tasks assume migrations reside in the DB migrate directory without awareness of additional directories.
00:19:18.200
Thus, the second problem with multiple databases in Rails arises as migrations don’t work seamlessly.
00:19:24.710
We can write rake tasks that will execute the migrations, but if you rely on Rails internals, they may not operate correctly.
00:19:30.900
Next, we establish animals connections for the dog and cat models.
00:19:37.000
We create a new base class, naming it AnimalBase.
00:19:43.240
For it to function correctly, we need to set abstract_class to true.
00:19:50.150
This informs Active Record not to use the implied STI table from the parent class.
00:19:55.960
For example, we don’t want the dog model to look in the animals base for the dogs table.
00:20:03.260
Now, we need to establish a connection to animals for our child classes.
00:20:11.320
Rather than inheriting from ApplicationRecord, these models need to inherit from AnimalBase.
00:20:17.780
This tells Rails to utilize the connection corresponding to the animals database.
00:20:24.250
Though we’ve identified some setup issues, it seems straightforward.
00:20:30.250
Unfortunately, none of the rake tasks will work for non-primary databases.
00:20:36.770
Create, drop, and migrate will strictly operate on the primary database.
00:20:43.850
There’s no Rake task for migrating or managing non-primary databases.
00:20:51.030
We need to devise separate Rake tasks for each secondary database.
00:20:57.150
After writing the necessary tasks, I encountered another problem.
00:21:03.200
When running the create task for the primary database, my app threw an error.
00:21:09.520
I double-checked my Rake tests, ensuring the three-tier config was correct.
00:21:16.000
After debugging, I discovered that the default connections for the three-tier config were not working.
00:21:23.900
When establishing a connection, Rails didn’t know which database to connect to due to multiple entries.
00:21:30.600
At this point, I've identified multiple difficulties with scaling databases in Rails.
00:21:38.020
We've noted no documentation, limited migration support, absent rake tasks, and mismanaged default connections.
00:21:45.880
Setting up multiple databases in a Rails application remains a challenge.
00:21:52.520
My scope for the original project was to extend GitHub’s behavior with multiple databases.
00:21:59.150
However, it evolved into three distinct problems each requiring substantial time.
00:22:05.610
In these moments, I felt overwhelmed and questioned why I’d even chosen to tackle this.
00:22:11.860
I then refocused on addressing migrations as an initial priority.
00:22:18.950
Addressing documentation first wasn’t effective, so I opted to tackle migrations.
00:22:25.320
The parallel testing needed to support how we handle multiple databases.
00:22:32.660
Previously, you had to set migration paths manually before calling migrate.
00:22:38.950
This was manageable for direct calls, but it was inconvenient with Rails internals.
00:22:45.460
Ideally, multiple databases should offer easier interactions with migrations.
00:22:52.350
Aaron and I revamped the migrations handling to store paths on the connection instance.
00:23:01.030
We needed Rails to query the model for migration paths instead of relying on application level settings.
00:23:07.620
This adjustment allows Active Record to operate more seamlessly in databases.
00:23:14.560
With the restructure to accommodate the models, Rails can determine migration directions effortlessly.
00:23:22.380
We discussed needing to create standard rake tasks for managing secondary databases.
00:23:28.620
Existing commands assumed only the primary database was relevant.
00:23:35.520
I wanted commands like rake db:create and rake db:migrate to operate on all databases.
00:23:42.740
However, the challenges with the three-tier config build up.
00:23:48.900
Many Rails frameworks are predicated on the assumption of having a simpler two-tier config.
00:23:55.370
But with each modification or testing, we need to clarify which database applies.
00:24:01.910
By switching to object representations for config hashes, we can more effectively query.
00:24:08.220
Now, with our new DatabaseConfig object, determining namespaces and environments becomes feasible.
00:24:14.710
This allows us flexibility and control over database returns.
00:24:20.630
We can ask specific questions about configurations and use methods to manage tasks.
00:24:27.400
Let’s consider how the migrate tasks work within Rails 5.
00:24:34.050
The existing tasks would load the primary config and invoke migrate.
00:24:40.580
Due to its reliance on existing database connections, it wouldn’t accommodate multiple databases.
00:24:46.370
To rectify this, we will use the 'configs for' method to migrate both primary and animals databases.
00:24:54.430
When employing a block, we gather the configuration hash and instantiate the connection.
00:25:02.460
These updates allow migrations to run more intuitively.
00:25:09.960
We can start connecting and invoking migrations on all databases.
00:25:15.790
The get-configs and other lookup methods sufficiently manage performance.
00:25:22.590
The goal is to effortlessly push forward user-defined tasks for database configurations.
00:25:28.640
We can automatically create intuitive tasks for different databases.
00:25:36.480
I wanted the names of these tasks to be easy to discover, so they read intuitively.
00:25:43.200
Naming conventions will also help users know which commands map to which task.
00:25:50.300
This setup allows for clear control over operations across databases with ease.
00:25:56.570
These adjustments conclude the current steps we've managed.
00:26:03.330
Though the three areas need improvement, I expect these changes will enhance the Rails' experience.
00:26:10.250
Next on our agenda is addressing the default connections issue with three-tiered setups.
00:26:18.390
With a temporary solution in place, I am dedicated to resolving it more effectively.
00:26:26.390
Aaron and I are working to change Active Record’s underlying connection management.
00:26:34.070
This will enable better selection of required configurations.
00:26:40.490
It's undoubtedly an extensive undertaking, as connection management in Rails is complex.
00:26:46.930
I hope that by next RailsConf, I can present all the features that will emerge from this refactoring.
00:26:53.350
There’s much more work to do to make multiple databases truly user-friendly with Rails.
00:27:01.750
I aspire to continuously improve the API for splitting reads and writes and further enhance performance.
00:27:09.320
We also need to develop thorough documentation regarding these features.
00:27:15.610
My hope is that the work done so far inspires further enhancements in scaling the database management in Rails.
00:27:23.260
I’d like to thank my friend and colleague Aaron Patterson for his collaboration on these features.
00:27:31.220
He kicked off the work on parallel testing and supported me in navigating connection management issues.
00:27:39.090
I would not have accomplished any of these features without his help.
00:27:46.420
A couple of weeks ago, someone asked me if I'm concerned that Rails will become bloated with scaling code.
00:27:53.080
This is indeed a valid point. Most apps don't need GitHub's scale.
00:28:00.960
Yet, when I consider how GitHub has necessitated Rails scaling over time, I can't help but wonder.
00:28:08.280
What if we had introduced these features five years ago?
00:28:16.330
How many more applications could be utilizing parallel testing and multiple databases?
00:28:23.320
Would we still hear people say that Rails doesn't scale, instead of inquiring how to make it scale even more?
00:28:31.880
Over the past year at GitHub, I have worked on upgrading our application from Rails 3 to 4.
00:28:37.780
While doing this, I have explored GitHub’s entire stack, from code hosting to wikis.
00:28:44.570
I noticed the different decisions made over the past decade—both beneficial and otherwise.
00:28:52.250
I know that GitHub isn't the only environment that has forced Rails to scale.
00:28:59.080
I have also worked on custom multiple database setups and parallel testing with other companies prior to GitHub.
00:29:06.760
I know Shopify has their own solutions for multiple databases and parallel testing.
00:29:13.380
I began to wonder why we all create similar tools yet don’t share them.
00:29:18.970
This occurs from our belief that our scaling problems are unique.
00:29:26.520
This mindset leads to an inward focus on solutions.
00:29:34.780
When faced with urgent issues or bugs, we often prioritize quick fixes over long-term solutions.
00:29:41.710
These emergencies motivate us to write stopgap measures instead of building comprehensive scaling solutions upstream.
00:29:48.420
As emergencies arise, it becomes tempting to rush to fix the issues at hand without planning for future scalability.
00:29:55.620
Later, those patched solutions can become tangled and difficult to maintain.
00:30:03.180
Applications often evolve into fragile structures where one change can lead to much larger issues.
00:30:10.100
When this happens, skepticism arises regarding whether Rails truly scales.
00:30:17.900
The constraint lies not within Rails but within the custom code we wrote.
00:30:24.680
We often build specialized solutions that restrict flexibility, making future changes challenging.
00:30:31.340
While developing tools without communal input, our code becomes rigid and unmanageable.
00:30:37.350
We find ourselves creating similar tools repeatedly, resulting in duplicate efforts.
00:30:44.800
However, we can approach issues with an upstream-first perspective.
00:30:50.150
First and foremost, we must accept that our applications aren’t extraordinarily unique.
00:30:57.440
If our applications succeed, then most likely, others will require scaling solutions.
00:31:04.370
Therefore, sharing solutions can enable us all to benefit.
00:31:10.660
I’ve witnessed several organizations reinvent parallel testing, forcing scaling solutions without contributing upstream.
00:31:17.760
It's clear that maintaining unique setups can stifle progress.
00:31:25.540
I don’t intend to sound accusatory.
00:31:32.240
Instead, I believe we are building near-identical solutions.
00:31:39.000
When scaling issues arise, we tend to seek fixes within instead of reaching outside.
00:31:46.680
This leads to missed opportunities for collaboration and improvement.
00:31:53.700
I believe it’s time to embrace the notion that sharing solutions enriches our ecosystem.
00:32:00.640
From a community standpoint, we can gather knowledge and reduce redundancy.
00:32:07.460
By pushing our solutions upstream, we can help build a more cohesive Rails framework.
00:32:14.640
This can lead to down-the-road advantages, enabling us to build more flexible and adaptable applications.
00:32:21.640
Upstreaming our code offers numerous benefits for the organization and community.
00:32:28.500
The first step towards success is acknowledging that our applications aren’t special.
00:32:35.470
If our applications succeed, scaling issues are universal.
00:32:42.160
Let’s share our solutions instead of hoarding them.
00:32:49.200
By sharing our knowledge, we uplift the entire community and enhance Rails’ adaptability.
00:32:56.410
I firmly believe my upstream multiple database handling will aid many other companies—and they can improve it for me, too.
00:33:03.240
This collaborative effort diminishes the burden of individual work.
00:33:10.240
Working alone in a vacuum isn't enjoyable; sharing creates an environment of constant learning.
00:33:15.960
During my years at GitHub, we’ve continually refined our application to scale more efficiently.
00:33:22.680
Now is the time to give back, sharing our experiences with the entire community.
00:33:30.000
By reflecting on how we have spurred Rails’ evolution at GitHub, we can enhance Rails' framework.
00:33:38.240
I want everyone who uses Rails to discover that developer happiness is achievable over the years.
00:33:44.640
But this is only possible if Rails continuously equips developers with the needed tools.
00:33:52.320
So, to answer the question: Do I think Rails will become bloated with scaling code? My answer is 'no'.
00:33:58.160
Contrarily, Rails is maturing, not dying.
00:34:05.580
If Rails aims to remain the go-to for web applications, the Rails team must meet those applications' needs.
00:34:12.360
We must build our applications not just for prototypes but for long-term reliability.
00:34:20.180
This maturity path involves talking about the scalability of features upstream.
00:34:28.080
So I ask you: How can your applications and contributions elevate Rails?
00:34:34.950
What have you done to encourage Rails to scale for you?
00:34:43.080
What can you give back to our community? Can you enhance parallel testing?
00:34:50.600
Do you have insights into optimizing multiple database handling?
00:34:56.580
Do you have tools that can be generalized for broader use?
00:35:03.450
Rails is defined and will continue to evolve through you, its community.
00:35:10.270
Let’s collaboratively define the future of Rails, ensuring Rails 6 is scalable by default.