Our great sponsors
-
-
Slim
Slim is a template language whose goal is to reduce the syntax to the essential parts without becoming cryptic. (by slim-template)
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
1. You are correct for upload, but not for download. Looks like rails 7 added support for presigned urls: https://blog.saeloun.com/2021/09/14/rails-7-adds-expiring-ur...
2. CDN support is via monkey patch: https://github.com/rails/rails/issues/44136
3. yep
4. yep
I think they mean Server Side Rendering (normal rails controllers/views), and Slim is just the name of the templating engine. It's a little nicer than the default ERB. https://github.com/slim-template/slim
There's also SSR with react and other js frameworks, but I don't think that's what they meant.
My memory is fuzzy, but...
1. all data flow through the rails app (no pre-signed s3 upload or download links for direct uploading).
2. no support for CDNs (I think newer rails versions added support)
3. blobs and attachments were unnecessary abstractions.
3a. Querying was annoying and easy to add n+1 queries.
3b. Images are moderated and it was unclear where to put the moderation metadata (on blobs? attachments? create a new table? why so many tables?). Accessing the data was annoying (you need extra joins).
4. GraphQL gem didn't support it: https://github.com/rmosolgo/graphql-ruby/issues/1777
'asdf' (a version manager) is great for this.
https://asdf-vm.com/
I took a 13,000 line Rails 7.0 app and updated it to 7.1. I had to change 1 line of test configuration code to make everything work.
I would say that's a success for having an easy upgrade path. Now the fun part is going back to refactor some of the code to use the new features in 7.1.
If anyone is curious, I updated my Rails / Docker example app to use 7.1 too https://github.com/nickjj/docker-rails-example. Even though Rails 7.1 comes with a Dockerfile, there's still a lot of opinions you can add such as using Docker Compose to have a fully working out of the box experience that works in development and production -- complete with Postgres, Redis, Action Cable, Sidekiq and more.
> For example having database migrations built in etc.
I actually went the exact opposite route, at least when possible: https://github.com/amacneil/dbmate
Pure SQL migrations, regardless of the back end technology that you use, completely decoupled from how each framework/library views things and therefore not dependent on them (you could even rewrite the back end in another technology later on, if needed; or swap ORMs; or avoid issues when there's a major ORM version update).
It's really nice when you can generate entity mappings based on a live database, like with https://blog.jetbrains.com/dotnet/2022/01/31/entity-framewor...
So in my case, I can have:
* a DB that has migrations applied with dbmate, completely decoupled from any back end(s) that might use it
> On the front-end it’s been a mess for a really long while now though
I don't disagree, but also front-end was a mess for a long time.
Now Rails (with Rails 7.1 + Hotwired + Importmaps) is a pleasure to work with.
But we had to wait for good support in browsers of at least ES6 + Import Maps.
See the date of this article here: https://web.dev/import-maps-in-all-modern-browsers/ -> 28 March 2023 announcing importmaps is available on all modern browsers.
Thus there was no way around Webpack Yarn or any other helping tool for JS until now.
Now we have importmaps and good support in browsers for east least ES6 (https://caniuse.com/?search=es6) thus there is almost no need for extra tooling so you can write modern JS.