Hey
Rails 6.0.0 beta1 has just been released π π.
TL;DR
Webpacker
Webpack is now the official JS bundler, Sprockets remains the recommended asset pipeline for static assets (images) and CSS.
New Frameworks
It includes 2 new frameworks:
- Action Text : to easily add rich content support to your app
- Action MailBox : to easily route incoming emails
Even more scalable
2 major features for scaling:
- Parallel testing: speeds up your testing suite in multicores environment
- Multiple database: Simple API to support multiple database with Active Records
and lots of other improvements
Top comments (4)
The feature I'm more excited about is the multi DB support, you can finally easily setup a replica DB for reads and keep the writes in your main DB, with something like:
(taken from github.com/rails/rails/pull/34052)
Parallel testing support is interesting and useful, it's a great way to see if your testing suite has issues (some suites have codependencies that are unknown until you run them in parallel :D). Aside from the possible speed improvements.
I was reading just yesterday about the new autoloader which would hopefully eliminate those weird cases when you still need a require statement here and there.
Glad they also upgraded minimum Ruby to 2.5.
I'll go through the various changelogs when I have a bit more time and report back π€£
Fully agree on the parallel testing. It forces you to make independent tests.
I agree these are the most exciting.
I can't say I was dying for Action Text but I think we'd probably make use of it. Nice to have a "standard" of sorts for internal tools.
Action MailBox also a nice to have just in case.
No, and you don't want that. You don't want a web framework to sync your DBs :D
Some RDBMSs have the concept of a read replica, which is a twin instance which is asynchronously kept up to date. With PostgreSQL basically you configure the database server telling it which is the main instance and which is the replica, the main instance ships its changes to the other database (which is read only to the user) and the DB applies such changes.
This has a few benefits:
Depending on the type of app, by writing to a DB and reading from the other allows you to "balance the load" among them. In the case of a read heavy app you can scale with multiple replicas to read from and the main DB to write to.
So if you hit the ceiling of a single DB instance or if you just want to balance the reads among more than one failover, you can consider using read replicas.
If the main DB goes down you can still direct traffic to the replicas and keep the app running.
A by-product of a read replica that's not used directly by the production app (a stand by) is that you can use it to do batch reporting and heavy calculations on your data without affecting the app writing and reading on the main DB.