Service classes are one of the most representative anti-patterns in Rails.
That is because they deviate from Rails' MVC principles.
You have probably heard of the Single Responsibility Principle.
In MVC, each component has its own role:
- Model: storing, managing, processing, and relating data
- View: display, templates, and user interface
- Controller: handling HTTP requests
So, if we introduce a service class, what is its responsibility?
I do not know.
The name "service" creates the illusion that you can write some impressive-sounding business logic there.
However, the name "service" has no meaning or definition.
Why are so many people strict about meaningless variable names like tmp or x, yet willing to accept a meaningless class called a "service class"?
In my more than five years of experience with Ruby on Rails, service classes had unfortunately already been created in several projects.
In many of those cases, complex data-processing logic had been written in controllers, and service classes were used simply to clean up fat controllers.
That premise is wrong.
If you write business logic in models—especially logic related to retrieving and processing data—and keep controllers focused solely on calling that logic, controllers will never become complex.
"Do you accept fat models?"
Yes, of course.
In real companies, "business logic" is, in other words, a discussion about "how to handle data," which is precisely the role of the model.
When business requirements are large, it is inevitable that models become complex and grow in size.
Implementing readable code within models is where we engineers show our skill.
There is never any place for service classes.
"What should you do if a model grows so large that a single file exceeds 1,000 lines?"
Please refer to the OSS code published by DHH and 37signals.
Even when we talk about fat models, that does not mean you should cram all logic into a single class.
Campfire
Campfire is a web-based chat application. It supports many of the features you'd expect, including:
- Multiple rooms, with access controls
- Direct messages
- File attachments with previews
- Search
- Notifications (via Web Push)
- @mentions
- API, with support for bot integrations
Deploying with Docker
Campfire's Docker image contains everything needed for a fully-functional single-machine deployment. This includes the web app, background jobs, caching, file serving, and SSL.
To persist storage of the database and file attachments, map a volume to /rails/storage.
To configure additional features, you can set the following environment variables:
-
SSL_DOMAIN- enable automatic SSL via Let's Encrypt for the given domain name -
DISABLE_SSL- alternatively, setDISABLE_SSLto serve over plain HTTP -
VAPID_PUBLIC_KEY/VAPID_PRIVATE_KEY- set these to a valid keypair to allow sending Web Push notifications. You can generate a new keypair by running/script/admin/create-vapid-key -
SENTRY_DSN- to enable error reporting to sentry in production, supply…
For example, once-campfire defines the following files related to the User model:
models/user.rbmodels/user/avatar.rbmodels/user/bannable.rbmodels/user/bot.rbmodels/user/mentionalbe.rbmodels/user/role.rbmodels/user/transferable.rb
The first file, models/user.rb, is the one you are familiar with—the file created by rails g model User.
The others are modules that include ActionText::Attachable. In other words, they are concerns.
Even if something is not shared with other models, it should be extracted into a concern and split out.
That way, the main models/user.rb can remain simple.
By the way, who was it that started advocating for service classes in the first place?
DHH was loudly criticizing service classes, wasn't he?
When I ask AI for advice on Rails refactoring, it forcibly suggests services even though I never asked for them.
It is extremely irritating.
It makes me realize that the expectation that AI will replace real engineers is nothing more than nonsense.