Mengapa Saya Tidak Menggunakan Laravel?

Untuk pengembangan aplikasi skala kecil, Laravel berada di urutan teratas daftar rekomendasi saya. Tapi untuk pengembangan aplikasi kompleks dengan skala besar, Selamat Tinggal Laravel!

Mengapa Saya Tidak Menggunakan Laravel?
Image by Dorothy Munter from Flickr
Mengapa Saya Tidak Menggunakan Laravel?
Mengapa Saya Tidak Menggunakan Laravel?
Mengapa Saya Tidak Menggunakan Laravel?
Mengapa Saya Tidak Menggunakan Laravel?
Mengapa Saya Tidak Menggunakan Laravel?

Penafian

Saya tidak berniat menghakimi Framework Laravel secara sepihak. Hanya sekedar membagikan pemikiran dan pengalaman saya selama menggunakan Laravel dengan harapan Anda memiliki gambaran kapan harus menggunakan Laravel dan kapan harus menghindarinya ketika mengembangkan sebuah aplikasi.

Intro

Artikel ini subjekif. Pendapat Anda terhadap Laravel mungkin berbeda dengan saya, jadi keep in mind bahwa tulisan ini murni hanya merupakan opini. Dan, mungkin saja, akan mengubah cara pandang Anda terhadap framework Laravel.

Tulisan ini bukan merupakan ajakan untuk berhenti menggunakan Laravel. Tapi saya berharap, ketika Anda menggunakan Laravel, Anda mengerti apa yang Anda gunakan, dan mengapa Anda menggunakannya.

Saya sudah sering menggunakan Laravel dalam pengerjaan proyek pengembangan perangkat lunak aplikasi. Saya menyadari bahwa Laravel menyediakan banyak sekali tools yang berguna seperti perintah console yang membantu saat coding, scaffolding untuk autentikasi dan lain sebagainya. Banyak banget pokoknya.

Tapi...

Semakin dalam saya masuk dan semakin besar skala project yang dikerjakan, saya mulai merasa bahwa Laravel adalah pilihan yang buruk. Sebenarnya, bukan hanya kesalahan di Laravel; tapi juga bahasanya, yaitu PHP, yang (menurut saya) tidak dikembangkan dengan sangat baik.

Baiklah, mari kita mulai,

Eloquent ORM

Kalau Anda sudah pernah menggunakan Laravel, Anda pasti sudah tahu apa itu Eloquent. Eloquent adalah ORM bawaan dan sudah tersedia ketika kita menginstall Laravel. Fiturnya banyak, dan rapih. Tapi desainnya membuat aplikasi malah menjadi rumit dan membuat IDE kacau-balau ketika melakukan analisis pada kode kita.

Hal ini disebabkan oleh penggunaan Active Record ORM. Penyebab lainnya adalah, fakta bahwa Eloquent sebenarnya dibuat dengan tujuan yang baik, yaitu agar programmer atau pengembang tidak perlu lagi banyak-banyak coding. Tapi untuk melakukan itu, Laravel menempatkan banyak hal yang harusnya disentuh oleh developer tapi malah dimasukkan ke dalam model.

"Tapi bukannya malah bagus ya? Developer kan jadi lebih ringan kerjanya."

Ya, sekilas memang tampak keren. Tapi ini adalah salah satu hal yang membuat saya tidak menyukai Laravel. Mari kita lihat salah satu contoh.

Perhatikan model user berikut ini.

Contoh Model User Laravel

Tidak ada properties. Yep, tidak ada properties di dalam model!

Buat saya, ini kurang relevan. Kenapa? Karena semuanya diinject secara "ajaib" ke dalam class dengan membaca tabel metadata yang mengakibatkan IDE menjadi galau ketika menganalisa kode kita. Dan Anda, sebagai seorang developer, tidak diberikan kesempatan untuk memberi nama property yang berbeda pada setiap kolom.

Sekarang, mari kita lihat method scope nya.

Untuk pengguna Laravel, sudah jelas apa fungsinya. Ketika method tersebut kita panggil, maka akan membuat query SQL dengan menambahkan klausa WHERE.

Seperti yang kita lihat, itu bukan static. Artinya, operasi method ini dilakukan pada suatu object dari class. Tapi dalam kasus ini, bukan itu yang dilakukan. Sebuah scope dipanggil pada Query Builder dan hal itu tidak ada sama sekali hubungannya dengan object model itu sendiri.

Itu akan saya jelaskan nanti. Sebelumnya, mari kita lihat dulu bagaimana kita biasanya memanggil scope tersebut.

Contoh contoller Laravel

Pada kode di atas, kita memanggil static method popular() yang tidak pernah di define oleh siapapun. Tapi karena Laravel men define method __call() dan __callStatic(), akhirnya method tersebut ditangani di situ. Ketika dipanggil method tersebut meneruskannya ke Query Builder.

Pertama, IDE tidak akan bisa membaca dan memahami kode seperti ini. Kedua, hal ini akan membuat code refactoring menjadi rumit, developer baru kebingungan, Static Analysis pun akan menjadi lebih sulit.

Selain itu, saat membuat method seperti itu di model, kita telah melanggar poin S pada prinsip SOLID. 

Bagi yang belum pernah dengar, SOLID merupakan akronim dari:

  • Single Responsibility Principle.
  • Open/Closed Principle.
  • Liskov Subsitution Principle.
  • Interface Segregation Principle.
  • Dependency Inversion Principle.

Saat menggunakan Eloquent, maka model memiliki fungsi ganda, yaitu merekam semua data dari database yang merupakan fungsi umumnya, tapi juga melakukan logika filter, sorting dan lain sebagainya. Bagi saya, itu tidak normal.

Global Helpers 

Laravel hadir dengan beberapa function Global Helper.

Keren sih, tapi tahukah Anda bahwa Anda telah mengorbankan kebebasan Anda sebagai seorang developer untuk kekerenan itu?

Mari kita lihat beberapa contoh tidak penting dari Global Helpers Laravel ini.

  • app_path() - Buat apa? Kalau butuh app path tinggal panggil app object kan?
  • app() - Kita nggak butuh ini. Kita bisa inject app instance.
  • collect() - bertujuan untuk membuat instance baru dari collection class. Lah, kalo mau bikin instance baru tinggal bikin New salah satu object aja apa susahnya? Sama saja.

Atau, mari kita lihat satu contoh lagi yang lebih konkrit.

Kita menggunakan Global nya Laravel yaitu request() helper untuk menampilkan POST data dan memasukkannya ke dalam model sebagai attributes.

Tanpa menggunakan global helper pun, kita bisa membuat hint request object sebagai parameter di method controller. Operator di dalam Laravel akan memberikan objek yang kita butuhkan, memanggil method kita tanpa harus panggil method ke helper.

Facades 

Sekilas, Facades ini terlihat seperti tool yang sangat membantu untuk mempercepat access beberapa method yang tidak benar-benar statis. Tapi,lagi-lagi ini justru mengikat. Kita menggunakannya secara manual untuk membereskan dependency dan bukannya memberikan instuksi ke environtment untuk membuatnya.

Daripada menggunakan facades, kita bisa menggunakan dependency injection seperti pada contoh sebelumnya. Kita punya object real dan bisa memanggil method yang real di dalamnya. Lebih bagus malah.

Contoh

 

Sekarang mari kita bersihkan kode ini. Yaitu dengan memberitahu Laravel untuk inject ResponseFactory dan passing current request nya.

Dan, kita sudah berhasil mengeliminasi facades dari controller.

Fun Fact: Ada sebuah design pattern bernama "facade pattern", yang ditulis dalam buku Gang of Four. Tapi memiliki definisi yang sangat berbeda. Facades-nya Laravel pada dasarnya adalah static service locators. Jadi nama "Facade" ini sebenarnya tidak mencerminkan hal itu. Penamaan yang sama pada facades ini kadang membuat rancu komunikasi sesama pengembang. Sama-sama membahas facades, tapi yang satu Laravel, satunya lagi Gang of Four.

Kesimpulan

Di artikel berikutnya saya mungkin akan membahas teknologi apa yang lebih saya pilih. Tapi saat ini, mari kita rangkum dulu hal-hal yang bisa kita pelajari dari hal-hal di atas.

Usaha Laravel untuk membuat semuanya sesederhana mungkin sudah sangat bagus.Tapi rasanya terlalu statis dan mengikat ketika kita akan mengerjakan aplikasi dengan skala yang lebih besar. Sedangkan untuk aplikasi skala kecil, Laravel tetap menjadi framework rekomendasi saya.

Beberapa poin yang saya paparkan di atas sebenarnya tidak murni merupakan kekurangan dari framework Laravel. Sebagian juga dikarenakan desain PHP yang buruk. Kalau Anda sering mengikuti komunitas pemrograman, Anda pasti sering mendengar keluhan tentang buruknya desain PHP ini. Untungnya, PHP 7 hadir untuk menjawab berbagai keluhan itu, atau setidaknya ada banyak perbaikan jika dibandingkan dengan PHP 5.

Terima kasih telah membaca.