Belajar Ruby on Rails - Arsitektur & Filosofi MVC
Membedah arsitektur Rails: alur request MVC dari Router ke Controller lalu Model dan View, konvensi naming plural/singular, serta peta tujuh module utama — Active Record, Action View, Action Controller, Active Job, Action Cable, Active Storage, dan Action Mailer
#Pendahuluan
Setelah di episode 1 kita memahami filosofi "mengapa" Rails ada, episode 2 membedah arsitektur yang menjadi kerangka semua episode berikutnya: MVC (Model-View-Controller). Jika episode 1 menjawab mengapa, episode ini menjawab bagaimana Rails terstruktur di dalam — dan bagaimana kalian harus berpikir saat menulis kode.
Mengapa arsitektur ini penting dikuasai lebih dulu? Karena hampir semua pekerjaan di Rails — dari menambah route sampai menulis query — adalah menempatkan kode di salah satu dari tiga lapisan MVC. Salah menempatkan logika (misalnya query di view) akan menghasilkan codebase yang sulit dipelihara. Memahami peta module Rails juga menjelaskan tool apa yang dipakai untuk masalah apa.
#Alur Request dalam MVC Rails
Ketika sebuah HTTP request tiba, Rails menjalankan alur yang sangat teratur:
- Router mencocokkan URL dan metode HTTP ke sebuah controller action.
- Controller mengatur logika aplikasi: membaca params, memanggil model, memutuskan apa yang dirender.
- Model berinteraksi dengan database (Active Record) dan membungkus aturan bisnis (validations, associations).
- View merender output — HTML via ERB, atau JSON via jbuilder.
- Response dikembalikan ke client.
Kunci pemahaman: controller tipis, model gemuk, view sedatar mungkin. Logika bisnis tinggal di model, controller hanya mengalirkan, dan view tidak boleh memuat query.
#Tujuh Module Inti Rails
Rails bukan satu monolit, melainkan kumpulan module yang bisa dipakai bersama-sama. Inilah peta lengkapnya:
| Module | Tanggung Jawab | Dipakai Sejak Episode |
|---|---|---|
| Active Record | ORM: model, migrations, validations, associations | 5 |
| Action View | Rendering view & templates | 7 |
| Action Controller | Routing → controller, params, session | 4 |
| Active Job | Background jobs & queue | 11 |
| Action Cable | Realtime WebSocket & channels | 14 |
| Active Storage | File upload & attachment | 13 |
| Action Mailer | Email sending & template | 11 |
Karena semua module ini berjalan dalam satu framework, integrasinya mulus: model memberi tahu view data, controller memberi tahu mailer apa yang dikirim, dan Active Job menangani pengiriman tanpa memblokir response.
#Konvensi Naming: Plural/Singular
Salah satu contoh CoC yang paling berdampak adalah konvensi naming. Rails menyimpulkan hampir semuanya dari nama class:
| Konsep | Konvensi | Contoh |
|---|---|---|
| Model (class) | Singular, CamelCase | Post, BlogUser |
| Tabel database | Plural, snake_case | posts, blog_users |
| Controller | Plural, CamelCase | PostsController |
| File controller | Plural, snake_case | posts_controller.rb |
| Foreign key | _id pada singular model | user_id, blog_user_id |
| File view | action.format.erb | show.html.erb |
Rails punya inflector bawaan yang menangani pluralisasi tak beraturan: Person → people, Analysis → analyses, Category → categories. Kalian juga bisa menambahkan inflector custom via ActiveSupport::Inflector.inflections jika model bernama aneh (misal Buses vs Busses).
Tip
Kalian tidak harus menghafal tabel di atas. Saat generator Rails (rails g model Post) membuat class, migration, dan test sekaligus dengan nama yang konsisten, kalian akan melihat langsung bagaimana konvensi ini diterapkan di episode 3 dan 5.
#Request Lifecycle Lebih Detail
Mari kita lihat alur untuk satu request GET /posts/1:
Perhatikan bahwa controller tidak menulis SQL langsung — ia memanggil Post.find(1) dan Active Record menerjemahkannya menjadi query. Inilah separation of concerns yang membuat model bisa diuji terpisah dari HTTP.
#Common Pitfalls di Awal
- Menaruh query di view — misalnya
@posts.each { |p| p.comments.count }menyebabkan N+1 queries (dibahas di episode 12). Query seharusnya di model atau controller. - Controller terlalu gemuk — logic bisnis yang panjang di action membuatnya sulit diuji dan duplikatif. Pindahkan ke model method atau service object.
- Melawan konvensi tanpa alasan — menamai tabel
article_datauntuk modelPostbutuh konfigurasiself.table_name; boleh, tapi pastikan alasannya nyata. - Mencampur concern module — menyimpan kode yang tidak berkaitan dalam satu model hanya karena "masih soal user".
#Mengapa MVC Membuat Rails Mudah Dijaga
MVC bukan sekadar pola, ia adalah batas yang menegakkan disiplin: karena setiap lapisan punya tanggung jawab tunggal, kode bisa diuji per lapisan (episode 10), dioptimasi per lapisan (episode 12), dan dipahami developer baru hanya dengan membaca struktur folder.
Inilah mengapa Rails bisa memindahkan developer antar proyek dengan cepat: begitu kalian memahami pola di satu app Rails, kalian memahami hampir semua app Rails lainnya.
#Penutup
Episode 2 memetakan arsitektur Rails: alur MVC yang teratur (Router → Controller → Model → View), tujuh module inti dengan tanggung jawab masing-masing, dan konvensi naming yang membuat Rails menebak hampir semuanya dari nama class.
Inti yang harus dibawa pulang:
- Alur MVC Rails: Router → Controller → Model/View → response.
- Controller tipis, model gemuk, view tidak boleh berisi query.
- Tujuh module: Active Record, Action View, Action Controller, Active Job, Action Cable, Active Storage, Action Mailer.
- Konvensi naming: tabel plural, model singular, controller plural.
- Pitfall utama: N+1 queries, controller gemuk, dan melawan konvensi tanpa alasan.
Di episode 3 selanjutnya kita akan menginstall Rails dan membangun project pertama — dari rails new, menjelajahi struktur direktori, menjalankan bin/rails server dan bin/rails console, sampai scaffold CRUD pertama kalian. Bekali diri kalian dengan Ruby yang sudah terinstall di episode 0!