Omakase is a Japanese term that means “I leave the details up to you”.
It's frequently used in the world of gastronomy, especially when referring to a curated culinary experience that positions the diner as an enthusiastic observant that recognizes the chef's ability to create a better experience than the one he/she could have created.
In a sense, omakase shifts the responsibility from the passive novice to the active expert who's actually preparing the food and in contact with the ingredients and the methods that transform them into delicious glory.
In the context of Ruby on Rails, “omakase” refers to the fact that the frameworks isn't supposed to force us to make many decisions to be productive with it and develop great web applications.
The term was coined by David Heinemeir Hansson back in 2012 in the Rails is omakase post published on his personal website.
To better understand it, let's start with the context:
Why is omakase a thing
Before Rails came out in 2005, most web frameworks required an awful lot of configuration, you had to make many decisions before “Hello, World”, and those decisions didn't substantially affect the outcome during the early stages of web applications.
Settling for a database engine, an ORM (or the lack of one), a front-end framework or a templating system isn't a very productive use of time for shipping working software quickly.
Existing web frameworks encouraged thoughtful configuration up front, but that came with a price tag: initial productivity losses and the
And then, Rails came out with a very opinionated way of building web applications that promised to save you plenty of time with the accidental motto of “look at all the things I'm not doing”, that spawned from the famous 15-minute blog video.
To deliver on its promise, Rails has to make many decisions for us and pave a golden road with omakase wisdom and hand-holding to give us the promised productivity gains.
That scenario is ripe for disagreements and criticism, especially in the long-run, when users discover some of the trade-offs that come off from the decisions that the chef made for them.
If we look at it with a pragmatic eye, trusting the chef's taste and experience is usually a good decision, even if we end up becoming an expert and disagreeing with the chef on some aspects of the process.
What kind of decisions are made for me
Whether we're aware of it or not, every time we create a new Rails application we are starting a new Ruby application where many decisions were already made up for us.
Let's explore them
Architecture
Rails embraces the MVC, Model-View-Controller, architecture which focuses on models, views, and controllers to organize code in a consistent and predictable manner.
On top of MVC, Rails also encourages us to build our applications as monoliths which consist of applications that have a unified, well-integrated codebase that exists within a single repository which typically includes the backend and the frontend.
ORM and a database engine
By default, Rails provides us with Active Record, the object-relational mapping system that allows us to query the database without having to directly write SQL.
It also chooses a database engine, SQLite since Rails 8, by default when we run rails new without specifying otherwise.
To improve our life, it includes database features like migrations that allow us to keep track of the way the database changes over time and database seeds that can be used to accelerate the setup process, thus making it easier to work with other developers in parallel.
Directory structure
Rails comes with a default directory structure that hasn't changed substantially since the early days of the framework.
This structure forces every application to start out the same way, and it encourages new developers to think about Rails applications in a certain way.
The default structure also helps us get familiar with Rails applications, even if the structure underwent customization over time.
Without it, apps in the wild would be harder to familiarize and get productive with.
Front end
Through the years, Rails has had many approaches to solving the front end.
Even though it doesn't force us to do anything, it uses ERB templates to render HTML and, since Rails 7, it uses Hotwire— a combination between Stimulus and Turbo— to help developers write interactive applications without requiring us to surrender the whole frontend to JS frameworks like React or Vue.
The framework also helps us with asset management through the Asset Pipeline, which uses Propshaft since the Rails 8 release.
Asset bundling is also provided if we need to; otherwise, we might use import maps to import our required modules directly from the browser.
We're completely free to choose other tools to help us achieve our goals, but the defaults are a pretty solid choice when starting out.
Security
Even if we're not aware, Rails takes care of some aspects of security for us by default.
It protects against Cross-Site-Scripting (XSS) attacks by automatically escaping user input in views, thus preventing malicious scripts running in the browser.
Other security features provided by Rails include protection against SQL injection when using Active Record's query interface, Cross-Site Request Forgery (CSRF) by automatically embedding authenticity tokens in forms, mass-assignment protection by using strong parameters to avoid users modifying attributes they're not allowed to modify.
Extra features like session management and password hashing are available when using features like the Rails 8 Auth Generator.
Testing
Rails provides Minitest as the built-in testing framework with fixtures as a way to generate test data.
With it, we can thoroughly test our application using unit, functional, or integration tests.
Together with other tools to mock dependencies or produce system tests, we can thoroughly test our application to make sure everything works as expected.
Why does omakase still matter
Yes, we're not in 2005 anymore: primitive PHP and configuration-hungry Java frameworks are not the norm anymore.
But the fact that developing web applications nowadays is much more complex than before makes omakase even more relevant.
The number of decisions we avoid by just sticking to conventions can help us be more productive when it matters.
Nowadays with Rails:
The frontend is almost fully left to the Hotwire stack, we can even build mobile applications with it using Hotwire Native.
Other options like ViewComponent, Phlex or Inertia can be used on top of the Hotwire stack without having to resort to one or the other.
Rails 8 promises to be the first step of empowerment for the one developer army with things like the auth generator, the Solid stack that allows us to replace dependencies by relying on the database to achieve things that were previously done with an in-memory database.
The current omakase menu even includes easy deployments using Kamal, a tool to greatly simplify the deployment process using Docker. With it, we can get rid of expensive deployment automation tools and ensure our process is standardized without the need to pay the big bucks.
Summary
In the culinary world, omakase is a word that represents that a whole experience is left to the chef's criteria.
In Rails, omakase means that the framework makes many decisions for us, even if we're not aware of them.
Those decisions include things like the application structure, it's architecture, the way the front end works or the general direction of the framework amidst changing scenarios that might distract us from the main purpose, which is shipping working software.
Even though the term might seem shocking or pedantic at first, omakase is actually a good thing because it liberates us from the burden of making those decisions, especially when we're not yet ready to make them.
As time goes by, and we learn about the tradeoffs, we might challenge omakase and develop a very different way of thinking about web applications, but this doesn't mean that the whole idea is not valuable.
All in all, omakase is itself a tradeoff we should consider whenever we start building applications with Rails.
