Autotuner: How to speed up your Rails app
railsatscale.com
railsatscale.com
It’s incredible how much Shopify is investing in Rails (& Ruby for that matter).
And I assumr the investment is paying off because otherwise they wouldn’t continue like this.
Writing new services in Java might help, but still doesn't solve the main issue if your Rails app is a monolith. Breaking up the monolith might be a bad decision and is also super expensive and might even eat lots of the potential performance gains.
When you stay in the well trod C Ruby path, you benefit from the hordes of others who cleared the landlines before you. With JRuby, not so.
The cost of running the system is almost never bottlenecked by the performance of the language itself, but rather the responsibilities of the system and cleanliness of the code. Plus, in the migration, you start incurring the cost of your Ruby code calling your JVM code (and vise versa; your systems are almost certainly not a DAG), which almost certainly has higher overhead than whatever speedup you'd get from running code in the JVM in the first place. And then you're sharing protobufs/thrift files/whatever between different languages and libraries of varying degrees of quality (good luck with those Ruby protobufs!).
Before you know it, writing a little tool to optimize your Ruby garbage collector sounds like a really great idea.
Why would they bother switching if Shopify isn't having fundamental problems and they're the tog dog in their stack?
Last year I started a new project[1] for a member management platform and really fell in love with the new jsbundling pipeline paired with stimulus, it feels like I've rekindled my passion that led me into programming initially; the ability to hack & prototype with rails is pretty unmatched (though it's worth mentioning Django holds a special place in my heart as well)
Sure shaving the last 10/10ths of having a SPA with simple API based back end gets the ultimate user experience and speed but that cost curve goes up significantly for that last 10th (if you were to compared to an 'old school' Rails app)
I can't even fathom what it would have taken to build our startups' product in say React + Node (as an example..) vs OG Rails SSR. I look at a "sort of" competitor in our industry, and their rate of feature development is ridiculously slow by comparison.
My team inherited a Rails app, which used Turbo and Stimulus and we really struggled to create UIs that matched our design team's vision. We eventually had to move to react + MUI just so that we could build a webapp with a modern look and feel.
None of us come from a rails background, so I'm sure that a big part of our problem came from us trying to bend Rails to our will rather than embracing it - if you have any advice on articles / books that embody the rails approach, I'd be really grateful if you could share them.
Seconded. At my org, Ruby/Rails is our competitive advantage.
Our 5-6 competitors are all Java/.NET shops -- we deliver fixes and new features dramatically faster and deploy them with ease. It gets noticed.
The main downside is rails doesn't scale well re: complexity so regular refactors are necessary (ours is a high-volume big data app).
For performance/cost, it took some doing but by strategically moving business logic to higher performance techs we've even managed to get to a great spot there.
I said "no, can't do that - that's huge".
A weekend later of experimentation (thanks to one very kick-butt gem on that has an amazing way of managing trees) "actually, we may just be able to - it's going to be a long road though - setting expectations..."
A period of time later we've now implemented a full BOM planning/tracking system, tested well upto and beyond the numbers of items these types of companies expect.
To the point they cancelled their renewal with a big/established ERP vendor and went with us instead.
There's definitely some instances where speed to market trumps everything else. We can go optimise queries later on.
What's been fascinating is I left my day job 2 years ago (to the month). We've gone from unheard of to becoming the market leader in our space. There is absolutely no way that could have been done with any other stack (without spending 5x the money - and I argue that co-ordinating a bigger developer team it almost wouldn't matter what money you throw at it, it gets exponentially harder getting everyone on the same page for delivery).
At my old workplace I couldn't convince the .NET team for love nor money to look outside the box.
And that line of thinking is damaging in the tech world. There is no one ring to rule them all. Each tool, language, framework has a place - everything has tradeoffs.
I've worked with enough .NET world to know what the tradeoffs would have been.
For instance the critical library that enabled this piece of functionality, the nearest thing in .NET world looks to have 1 star on github, last updated 4 years ago. The ruby gem has 1.8k stars, tonnes of commits and upto date.
So if you were to implement that in .NET you would be (a) hitting the books (b) re-writing that library or (c) doing a hugely in-effecient/naive implementation that wouldn't scale.
In RoR land - drop in the gem and be prototyping that afternoon.
Sure if I was VC backed, and had money to burn, it might be a bit more interesting to use .NET - if were targetting more enterprise oriented clients and potentially wanted an on prem option, then yeah - .NET. Wanting more access to developers in our country - .NET, that's the predominant market. Etc etc.
In our use case RoR isn't a downgrade.
If there isn't an SDK for something in .NET but is in Ruby, it speaks for the poor quality of an engineering culture in that company (as it is likely they offer Java SDK at the same time). And even in that case, you can just generate a client from OpenAPI manifest. Or a gRPC client from .proto (even better). Or if it's an algorithm, you're much better positioned with all the low-level tools C# offers to write something performant with reasonable amount of effort.
And even if that doesn't work, you can just call C bindings by using one of many existing binding generators or just `[LibraryImport]` the calls directly with little effort, after all, C# is a proper C language with C structs and pointers.
But most importantly, you get robust results and consistently good performing application with no scalability issues, good build system and very little risk of accidentally breaking the codebase.
And you don't need to make a developer productivity tradeoff in order to achieve that. I don't know when the bad reputation has to go away, but surely we're long past that point.
I love both Ruby and C# - I don't think one is better than the other. Ruby also has good interop with C. The performance of Ruby is good enough for most use cases. Scaling a Ruby app via multi-process scaling has worked perfectly fine without major issues for most use cases. The open-source 3rd party libraries in the Rails world have a certain "feel" to them.. as if they were written by devs that care a LOT about the - excuse the trendy term- DevEx that are often missing in the C# world.
Call it bias due to familiarity but Rails continues to remain the most productive option to bootstrap a web app/startup for me. Often I think most of the dissonance is simply due to difference in philosophy. Devs don't like Rails because its not "their way" and not that it is inherently better.
Pick the tools you like to use, most productive with, and most appropriate for the application - thats it. No need to nitpick on language semantics, tooling, or performance if those are not even major considerations for what you are building.
I'm happy to say that I was proven very wrong. New conferences have sprung up, over-the-wire is trending well against SPAs, and there's been a ton of new features and approaches that have kept Rails and Ruby very relevant to modern development.
But recently I interviewed for a staff engineer position and there was a portion that was "API programming." Just writing a basic REST API to CRUD a model object. And I was like, oh my god, I know what I have to do. So I used rails. It was an hour and 15 minute block, and I ran the interviewer out of extensions to the problem after 30-40 mins. So we just chatted for 20 more and then both went to an early dinner.
(Unfortunately I didn't get the job - they were hiring a staff engineer but afaict ended up downgrading the seat to a senior engineer spot (50% the total comp) and rejected me and the other guy who was interviewing for the staff spot.)
But damn did I feel like I properly represented Ruby and rails in that one interview.
It's like they wanted me to overcomplicate things for some reason
I only ever wanted compile-time linting and better autocompletion such as in the case of Elixir LS. Does something like that exist for Ruby now? How is Crystal these days?
ruby-lsp-rails builds on top of that and hands out information on models and routes mostly
In the latest version of IRB for example they can use RBS based static typing for autocompletion[1].
This gives me a lot of hope that we'll have a more widely used static typing solution soon. i.e. some coming together of Sorbet, Steep and RBS.
1. https://github.com/ruby/irb?tab=readme-ov-file#type-based-co...
Any advice? I know the job market is a bit of a rough one right now as well.
That said, if you can display you have knowledge of the more important Rails libraries like ActiveRecord, ActiveJob, how Rails handles the MVC pattern etc., then your chances are much better. It's a bit of a magical framework when you first start working with it, so it's important to know what it does behind the scenes, at least a tiny bit, since otherwise it's easy to get lost.
That will allow you get familiar with the ecosystem so that you can hit the ground running and also allow you to point to experience during the screen and interview phases.
Despite the major investment made by Stripe and Shopify, my experience is similar to that of this commenter: https://news.ycombinator.com/item?id=40161561 - like them, I've found the open source libraries available in the Ruby + Rails ecosystem to be aging and less well supported than that of more popular languages / frameworks like GoLang / Java / Python.
Rails is delightful to work in and very thoughtfully constructed, and the Rails community is helpful and welcoming. However, if your priority is to maximize your chances at getting hired, I would look towards GoLang / Java / Python etc, which are far less enjoyable to work in but far easier to find jobs for.
Best of luck!
I'm not saying it's a bad technology choice for a new company when all you need is to build a CRUD web app fast, but I wouldn't use it for anything that requires you to serve >1MB of JSON API responses or anything that requires concurrency, substantial IO, lots of API interactions with external services, low latencies, lots of memory or compute heavy computations, etc.
We use grape-api for some of our API endpoints. I needed to set some custom cache headers for some GET API responses and was looking into gems that do that for grape. They have a list of 6 libraries in their docs [1] that they recommend.
Their newest commits were 4, 9, 9, 10, 8 and 9 years ago, respectively. This is just one example, but I would bet half of the libraries in our transitive dependency tree haven't seen any maintenance in this decade.
An equivalent example imo is the PHP ecosystem, which itself has been growing rapidly and thriving over the years -- but at the same time if you did deep enough you'll find a graveyard of long since abandoned frameworks, libraries, etc...
The problem that I can see with Ruby in particular is that its niche is getting smaller and smaller as the world evolves around it. Interactions with external services that are on the critical path to serving requests are becoming more common. Interactions with actual contents of pictures and documents are becoming more common. Concurrency is a major missing building block to build modern apps compared to 10 years ago, and the answer of the Rails community has mainly been YAGNI (although there are efforts to incrementally improve things, but no fundamental shift in language or runtime design).
And then talked about Rust as it was a general purpose language that all the potential to become the top language for most programming in the World?
I’m joshin’ but seriously, PHP is HUGE and Ruby was always small even when they were loud on the internet.
Rust is a systems language currently being used as a big hammer for everything and a somewhat obnoxious community just as Ruby, then Node, then Go were when their day in the Sun was.
I’ve seen the exact template of your comment throughout the years, it fine, it belongs to this particular point in time and in your of the woods, there are more.
There’s also a ton of idea placeholder and half-baked proof-of-concept gems. These are easier to spot (usually released once, years ago) but are now nothing but squatters on the namespace.
Even if human effort is too much to ask, a filtered subset of packages that successfully bundle and pass their own tests for specific Ruby version+arch would be helpful. More broadly, perhaps that RubyGems should even be entirely siloed for each annual Ruby release, since this tends to be the boundary of breaking changes to the language (see also: semver) and approximately the cycle on which unmaintained packages become an obstacle to the update of shared dependencies.
None of this is meant as a criticism of Ruby Toolbox, because it never claimed to do all that, nor can we expect it to. All said & done, and to reframe things more constructively, I think there's a missing piece in the community infrastructure puzzle that someone could fill if they had the time, inclination, and build farm to do it.