รีวิว Laravel Framework (ข้อดี vs. ข้อเสีย) แบบละเอียดโดยฉบับผู้ใช้งานจริงจัง

March 13, 2021 · 17 min read

Author

Intro

laravel

สวัสดีครับ บทความนี้จะเป็นการรีวิว Laravel Framework โดยจะพาเข้าสู่จักรวาลของ Laravel ซึ่งเป็น Web Framework แบบ MVC ของภาษา PHP โดยได้รับความนิยมอย่างมาก (สูงสุดของ Framework ภาษา PHP) โดยบทความนี้ก็จะมาเล่าถึงข้อดี และ ข้อเสีย ฉบับผู้ใช้งานจริงจัง (หมายถึงใช้งานระดับ Production มาหลาย Projects แล้ว) ที่ไม่ใช่แค่ลองเล่น หรือทำแค่ CRUD 😅 โดยก็จะเป็นการรีวิวแบบตรงไป ตรงมา ดีก็ว่าดี แย่ก็ว่าแย่นะครับ 😊

หากคำพูดส่วนใดไม่ถูกต้อง หรือใครมีข้อเสนอแนะอยากเพิ่มเติม สามารถเขียนลงที่ช่องแสดงความคิดเห็นได้เลยนะครับ ผมเองยินดีรับฟังทุกความคิดเห็นเพื่อเอามาปรับปรุงเนื้อหาในบทความนี้ครับ 🙏

เกี่ยวกับ Laravel เบื้องต้น

Laravel คือ PHP Framework* แบบโอเพ่นซอร์สฟรี ที่ถูกออกแบบมาเพื่อพัฒนาเว็บแอปพลิเคชั่นด้วยภาษา PHP (server-side) โดยใช้รูปแบบสถาปัตยกรรม Model-View-Controller (MVC) (บน github มียอดดาว 76.2k เมื่อ 02/2024)

note

Framework* คือกรอบหรือข้อตกลงสำหรับการใช้งาน (Conventional) ที่กำหนดโดยผู้พัฒนา Framework ซึ่งได้กำหนดกฎเกณฑ์สำหรับการพัฒนาไว้แล้ว ดังนั้น Framework จึงเหมาะสำหรับการพัฒนาระบบเป็นทีม ที่ต้องการความยืดหยุ่น กรอบแบบแผนที่ชัดเจน เพื่อใช้สื่อสารกันในทีมได้ง่าย อีกทั้งยังบำรุงรักษา Code ได้ง่ายเป็นระบบ

Reviews

บทความนี้จะสรุปและรีวิวจากประสบการณ์ที่ได้ใช้งานอย่างจริงจังมาเกือบ 2 ปี โดยอ้างอิง Laravel 8.x เป็นหลักนะครับ (รุ่นล่าสุดขณะที่เขียนบทความ) และก่อนอื่นผมต้องขอนิยาม Laravel ไว้ว่า "Framework ที่ดี ที่ต้องแลกมาด้วยประสิทธิภาพ 😅" โดยส่วนตัวได้ใช้งานมาแล้วก็มีความคิดเห็นว่าเป็น Framework ที่ดีมากตัวนึง ดังนั้นแนวการรีวิวของบทความนี้ก็จะพูดถึงรูปแบบ Web Framework ที่ดีที่ควรจะเป็นนะครับ โดย Web Framework ที่ดีที่ควรจะเป็นซึ่งตรงนี้ไม่ได้อ้างอิงจากที่ไหน เพราะผมได้สรุปตามประสบการณ์ของผมโดยตรงเลย 😊

1. การติดตั้ง (Development)

(★★★★ 4/5)

การติดตั้งสำหรับสภาพแวดล้อม Development นั้นเรียกได้ว่าติดตั้งง่ายสามารถติดตั้งผ่าน Composer (อารมณ์เหมือน NPM ของ JS) Docs ของ Laravel ก็มีรายละเอียดการติดตั้งบนหลาย OS ที่เขียนไว้ดี (รายละเอียด) อยากได้ Packages อะไรเพิ่มก็ลงผ่าน Composer มี Auto-discovery ไม่ต้องไป Configs เปิดใช้งานให้ยุ่งยาก

ข้อดี

Docs มีรายละเอียดการติดตั้งบนหลาย OS
มี Sail Services (รายละเอียด) ที่นิยามไว้ว่า "Laravel Sail is a light-weight command-line interface for interacting with Laravel's default Docker development environment" เบื้องหลังการทำงานคือ Docker ทำให้การ Setup Environment สำหรับการ Development นั้นง่ายขึ้นโดยไม่ต้องสนใจเรื่อง OS Platforms
มีคำสั่ง php artisan serve ที่รันแล้วได้ URL http://localhost:8000 สำหรับ Development Mode สำหรับใครที่ต้องการทดลองอะไรง่าย ๆ และรวดเร็ว

ข้อเสีย

ก็ไม่เชิงว่าเป็นข้อเสียอะไร เนื่องจาก Docs มีรายละเอียดการติดตั้งไว้หลายวิธี แต่ถ้า Docs แนะนำว่าวิธีไหนที่เป็น Best Practices สำหรับมือใหม่คงดีไม่น้อย เพราะการใช้งานจริง ๆ เราอาจจะต้อง Dev หลายโปรเจคพร้อม ๆ กันดังนั้นต้องวางระบบ Environments อย่างไร
ที่จริงข้อนี้ก็เหมือนข้อแนะนำมากกว่า เพราะ Docs เขาไม่ได้แนะนำไว้ คือการแนะนำ IDE แนะนำ Plugin ของ IDE หรือการติดตั้งเครื่องมือสำหรับ Debugger โดยมีประโยชน์มาก ๆ เพราะจะช่วยเรื่องความรวดเร็วในการพัฒนาแถมยังช่วยลดข้อผิดพลาดได้ด้วย

2. ระบบ Environment Configuration

(★★★★★ 5/5)

ระบบ Environment Configuration เรียกสั้น ๆ ว่า ENV โดยเป็นการกำหนดค่า Configs ต่าง ๆ ที่ไฟล์ .env (เป็นมาตรฐานส่วนใหญ่อยู่แล้ว) ถ้าคนที่เคยใช้มาก่อนก็จะคุ้นแน่นอน ประโยชน์หลักของ .env ก็คือการกำหนด Configs ต่าง ๆ ไม่ว่าจะเป็น Keys ต่าง ๆ ที่เราไม่อยากเก็บลง Code (ที่จริงก็ไม่ควรเก็บค่า Keys ต่าง ๆ ลงบน Code) โดยสิ่งที่ผมชอบมากกับ .env ของ Laravel คือมันใช้ร่วมกับ Laravel-Mix ที่เป็น Frontend ได้ด้วยถือว่าดีเลยทีเดียว 👍

note

ไม่ควรเก็บค่า Secret Keys ต่าง ๆ ไว้บน Code โดยตรงแต่ให้ใช้ ENV แทนเพราะจะมีปัญหาเรื่องความปลอดภัย โดยถ้าเก็บ Code ไว้ที่ Git ค่า Keys เหล่านั้นก็ตามไปด้วย แถมถึงแม้จะลบ Keys ใน Code ส่วนนั้นออกแต่ History ที่อยู่บน Git ก็ไม่หายนะครับ ถือเป็นบาปที่หนามาก ...ล้างไม่ได้ง่าย ๆ 🤣

ข้อดี

มีการกำหนดค่า Configs ต่าง ๆ ที่ไฟล์ .env (เป็นมาตรฐานส่วนใหญ่)
ใช้ .env ของ Laravel ผสมร่วมกับ Laravel Mix ที่เป็น Frontend ได้ด้วย
มีการมาตรฐานการเก็บ Secret keys และการเรียกใช้งานที่ดี เช่น เมื่อเราเก็บค่า Secret Keys ไว้ที่ .env แต่ระบบจะไม่แนะนำให้ดึงค่าจาก .env โดยตรงแต่จะมีการทำ Constant Configs ไฟล์สำหรับเรียกใช้งานต่ออีกทีนึง
มีระบบ Configuration Caching .env ประโยชน์หลัก ๆ คือช่วยเรื่องความเร็วในการโหลด Core Framework (ตรงนี้ไม่ได้เป็น Default นะครับ ถ้าอยากใช้งานต้องสั่ง php artisan config:cache และเมื่อมีการเปลี่ยนแปลงค่าใน .env ก็ต้องสั่งรันคำสั่งนี้ใหม่ทุกครั้ง ทั้งนี้การใช้คำสั่งนี้จะทำให้เรียกใช้งาน .env โดยตรงไม่ได้ ต้องเรียกผ่าน Configs ไฟล์เท่านั้น ตรงนี้ต้องทำความเข้าใจดี ๆ ก่อนใช้งานครับ)
สามารถ เปิด - ปิด Debug Mode ผ่าน .env จาก APP_DEBUG=true หรือ APP_DEBUG=false
สามารถ เปิด - ปิด Maintenance Mode ด้วยคำสั่ง php artisan down หรือ php artisan up (มีประโยชน์เมื่อหากเราต้องการปิดปรับปรุงระบบจากนั้นระบบก็จะแสดงหน้า Maintenance Mode) ที่จริงมีรายละเอียดที่น่าสนใจ เช่น การสั่ง Redirect หน้า หรือ การเลือกหน้าสำหรับ Render views (รายละเอียด)

ข้อเสีย

ยังนึกไม่ออก

3. ระบบ Directory Structure

(★★★ 3/5)

Laravel ประกอบไปด้วย Directory Structure เยอะมาก คนที่เพิ่งมาเรียนรู้แรก ๆ ก็คงจะ งง อยู่ว่าแต่ละตัวคืออะไร ทำไมแยกย่อยเยอะเกิน พอใช้ไปสักพักพอเข้าใจ และก็คงจะเข้าใจเจตนาผู้พัฒนาว่าคงต้องการกำหนด Structure มาแบบนี้เพราะต้องการให้นักพัฒนาที่ใช้ Directory Structure ที่เป็นมาตรฐานเดียวกัน

ข้อดี

กำหนด Directory Structure มาให้ (แต่ก็เปลี่ยนได้ถ้าต้องการ)
มี Directory เยอะก็จริง (มาพร้อมกับการติดตั้ง) แต่ก็เป็น Directory ที่จำเป็นสำหรับการใช้งาน (ไม่ได้มีไว้แบบเปล่าประโยชน์)
แยก Directory เยอะเป็นสัดส่วน อาจจะไม่ค่อยมีประโยชน์ถ้า Dev คนเดียว แต่จะมีประโยชน์มากถ้า Dev เป็นทีมเนื่องจากมีระเบียบเรียบร้อย

ข้อเสีย

Framework ไม่ได้รองรับระบบ Modular Applications (Modules) หมายถึงการแยกส่วนพัฒนาแบบ Modules (ก่อนอื่นคุณต้องทำความเข้าใจเรื่อง Modular Software Architecture ก่อน) ตรงนี้เป็นข้อเสียอย่างมาก ที่จริงสามารถ Customs ได้ (ทั้งทำเองบ้าง ทั้งหา Packages เกี่ยวกับการทำ Modules ...ผมเคยพยายามมาแล้ว) แต่สรุปแล้วก็ไม่ดีไปซะทีเดียว เนื่องจากมันไม่จะไม่ถูกตามมาตรฐานของ Laravel (บาง Packages ที่ช่วยทำ Module ก็สร้างระบบ Directory เกินความจำเป็น บางทีอาจจะทำให้ระบบทำงานช้าด้วยซ้ำ) จะมีปัญหาตามมาหลายอย่าง เช่น การ Upgrade Versioning ระบบก็จะยุ่งยากขึ้น เนื่องจากเรา Customs Project ไว้ไม่เป็นไปตามมาตรฐานของ Laravel
เนื่องไม่มีความเป็น Modular Applications ทำให้การพัฒนา Project ร่วมกับทีม Dev นั้นทุกคนต้องมีไฟล์ระบบ Project ที่เหมือน ๆ กันยิ่ง Project ขนาดใหญ่ก็ยิ่งเยอะ ไม่สามารถแยกส่วนการพัฒนา Module ที่ชัดเจนได้ทำให้อาจจะมีปัญหาแก้ไขไฟล์เดียวกัน (Conflicted files) ไม่สามารถ เปิด - ปิด เฉพาะ Module ที่ต้องพัฒนา หรือใช้งานได้
แนวทางการแก้ปัญหา Modular Applications ก็พอมีอยู่บ้างก็คือการทำ Private packages ด้วย Composer อ่านดูวิธีการแล้ว... ดูแล้วมันก็ไม่ได้สะดวกไปซะทีเดียวใช่ไหมครับ 😅
ก็ไม่เชิงว่าเป็นข้อเสียของ Framework โดยตรง เพราะเนื่องจาก Laravel เป็น MVC Framework ดังนั้นการวางโครงสร้าง Files สำหรับ Models-Views-Controllers มีความสำคัญมาก ซึ่งตรงนี้เราสามารถวางโครงสร้างได้อย่างอิสระ แต่ถ้าวางโครงสร้างไว้ไม่ดีตั้งแต่ทีแรก เมื่อ Project มีขนาดใหญ่ขึ้นระบบจะไม่มีความมีระเบียบเรียบร้อย ดังนั้นตรงนี้ ควรหาอ่านพวก Best Practices เช่น การตั้งชื่อไฟล์ การตั้งชื่อ Directory ต่าง ๆ

4. ระบบ Routing

(★★★★★ 5/5)

ระบบ Routing ของ Framework แบ่งระบบ Routing ออกเป็น Web และ API ชัดเจน โดยระบบ Routes ของ Laravel ได้แยกออกมาเป็นไฟล์ (routes/web.php, routes/api.php) ข้อนี้ผมให้ 5 ดาวไปเลย ส่วนตัวชอบมาก เพราะระบบออกแบบไว้ดี ที่จริงความสามารถของ Routing มีเยอะมาก ๆ แต่ขอยกอันที่ผมชอบมาพูดให้ฟังนะครับ

ข้อดี

ก่อนอื่นเราต้องเข้าใจก่อนว่า ระบบ Routing ที่แยกออกมาเป็นไฟล์ จะแตกต่างกับ ระบบ Routing ที่ผูกติดไว้กับ Method ของ Controllers (บาง Framework) นะครับ ซึ่งระบบ Routing แบบแยกไฟล์จะมีความอิสระหลายอย่างที่มีความสามารถเหนือกว่าโดยจะอธิบายในข้อต่อ ๆ ไป
กำหนด Routing ได้อิสระมาก ๆ แม้กระทั้งการทำ Routing มากกว่า 2 URLs ไปที่ Method เดียวของ Controller ก็สามารถทำได้
ทำ Routing ให้แสดงผลบางอย่างโดยแบบไม่ต้องใช้ Controller ก็ทำได้
ทำ Routing โดยแบบไม่ต้องใช้ Controller แต่สั่งให้ Render View ที่ต้องการก็ทำได้
ทำ Friendly URL ง่าย
ทำ Route Groups ได้ เช่น admin/users/1 หรือ admin/users/2 โดยที่ผมชอบมากก็คือ ภายใน Group เราสามารถใส่ Middleware เพื่อทำ Permissions ก่อนจะเข้าถึง Routes นั้น ๆ ได้ด้วย ตัวอย่าง
route/web.php
```
Route::group(['prefix' => 'admin', 'middleware' => 'auth'], function() {
    Route::get('/users', function () {
        // Matches The "/admin/users" URL
    });
});
```
info
Group Routing นั้นมีประโยชน์ในการทำ Group Permissions หรือ Group Resources ช่วยให้การพัฒนา และ Maintenance ระบบง่าย

ระบบ Routing มี Methods ดังนี้

สำหรับ HTTP request methods
Route::get($uri, $callback);
Route::post($uri, $callback);
Route::put($uri, $callback);
Route::patch($uri, $callback);
Route::delete($uri, $callback);
Route::options($uri, $callback);

สามารถทำเงื่อนไขการ Matching และ Any Methods ได้ ตัวอย่าง
ตัวอย่าง Matching และ Any Methods
```
Route::match(['get', 'post'], '/', function () {
    //
});

Route::any('/', function () {
    //
});
```
ทำ Rate Limiting ได้ หมายถึงการกำหนดจำนวนจำกัดสำหรับการเข้าถึง Route ต่อนาทีได้
มี Method Spoofing สำหรับ CSRF (การโจมตีแบบ Cross-site Request Forgery)
มี CORS ให้ตั้งค่าสำหรับการงานแบบ API เมื่อมีความจำเป็นที่ต้อง Share resource ข้าม Origin

ข้อเสีย

เนื่องจากระบบ Routing ของ Laravel นั้นมีความอิสระในการวาง Routes และถ้าวางโครงสร้างไว้ไม่ดีตั้งแต่แรกจะมีปัญหาเรื่องความซ้ำซ้อนเมื่อ Projects มีขนาดใหญ่ขึ้น
มือใหม่ควรศึกษา Best Practices การวาง Route Resource ไม่งั้นถ้าวางมั่วหรือตามใจ Routes จะมีความเข้าใจยากเมื่อทำงานเป็นทีม

ไม่ควรเขียนทุก Routes ไว้ในไฟล์เดียว (web.php หรือ api.php) กรณี Project มีหลายระบบก็ควรแยกไฟล์ Routes ระบบต่าง ๆ ออกจากไฟล์หลักก่อน จากนั้นค่อยนำมารวมกัน ตัวอย่าง

route/wep.php
Route::group(['middleware' => 'auth'], function() {
   // Home
   Route::group(['prefix' => 'home'], __DIR__.'/app/home.php');
   
   // System manage
   Route::group(['prefix' => 'system/manage', 'middleware' => 'is.admin'], __DIR__.'/app/systems.php');
   
   // User profile
   Route::group(['prefix' => 'user', 'middleware' => 'is.owner'], __DIR__.'/app/userProfile.php');
});

5. ระบบ Middleware

(★★★★ 4.5/5)

Laravel นั้นมีระบบ Middleware สำหรับใช้เพื่อตรวจสอบตามเงื่อนไขก่อนที่จะอนุญาตหรือไม่อนุญาตให้ดำเนินการต่อ เมื่อมี Request ไปที่ Route (บาง Framework เรียก Interceptors) อธิบายง่าย ๆ โดยยกตัวอย่างกระบวนการดังนี้

แบบไม่มี Middleware

Process
Request -> Route -> Controller -> View

แบบมี Middleware

Process
Request -> Route -> Middleware -> Route -> Controller -> View

จะเห็นว่าแบบที่มี Middleware มาคั่นนั้นสามารถทำเงื่อนไขอะไรบางอย่างเพื่อตรวจสอบก่อนจะไปที่ Route เป้าหมายและไปที่ Controller ซึ่งประโยชน์ของ Middleware นั้นสามารถประยุกต์ทำได้หลากหลาย เช่น การทำ Permissions Authentication Authorize ก่อนเข้าถึง Controller

ข้อดี

แบ่งเป็น Global Middleware หมายความว่า ทุก Route ต้องผ่าน Global Middleware ทุกครั้งที่มี Request
Middleware Groups สามารถจัดกลุ่มได้โดยสามารถกำหนด Group โดยให้ Group นั้นประกอบด้วย Middleware อะไรบ้าง
Sorting Middleware เป็นการจัด Priority Orders ของ Middleware ว่าให้ Middleware ไหนทำงานก่อนหลัง
มี Terminable Middleware คือการกำหนดกระบวนการทำงานบางอย่างที่ต้องการหลังจาก HTTP response ส่งไปที่ Web browser แล้ว

ข้อเสีย

น่าจะทำงานช้า เนื่องจากต้องผ่านหลาย Middleware ไหนจะ Global Middleware และพวก Middleware rules กว่าจะตรวจสอบผ่านทั้งหมดแล้วไปที่ Controller
อื่น ๆ ยังนึกไม่ออก

6. ระบบ Controllers

(★★★★ 4.5/5)

ระบบ Controllers ของ Laravel นั้นเป็นส่วนหนึ่งตามหลักสถาปัตยกรรม MVC สำหรับใครที่คุ้นเคย MVC คงเข้าใจหลักการทำงาน แต่สำหรับมือใหม่ผมขออธิบายสั้น ๆ ว่า Controllers นั้นประกอบด้วย Functions/Methods สำหรับควบคุมเป็นส่วนกำหนดเงื่อนไขต่าง ๆ และการทำงานร่วมกับ View และ Model

ข้อดี

ทุก Methods ที่ประกาศไว้ใน Controllers จะไม่สามารถเข้าถึงจาก Request ได้โดยตรง (เหมือนบาง Framework) ถ้าไม่ได้ผูก Method ของ Controller ไว้กับ Route ก่อน
มีความ Simple ของ Class โดยไม่มี Methods แปลก ๆ ที่กำหนดโดย Framework จากการ Inheritance ของ Controller หรือ Options แปลก ๆ และที่จริงต้องบอกว่ามีความเป็น Standard เลยละ
ชื่อของ Methods กำหนดได้อิสระ (ไม่เหมือนบาง Framework ที่ต้องกำหนดตามที่ Framework บังคับไว้ ไม่งั้นจะทำงานไม่ได้)
Return Array datasets จะได้ JSON ทันที และ ถ้าทำ Relation ของข้อมูลไว้ ก็จะได้ Data Relation ของข้อมูลออกมาด้วย
กรณีสั่ง Return Array datasets แล้วกำหนด Pagination ไว้ ก็จะได้ข้อมูล Metadata Page ของ Datasets นั้นด้วย

ข้อเสีย

กำลังนึก

7. ระบบ Models (ORM) และ Database

(★★★★ 4.5/5)

ที่จริงส่วนการเขียนเพื่อติดต่อกับฐานข้อมูลนั้นแบ่งออกเป็น 2 ส่วนคือ

ส่วนที่เป็น Query Builder นั้นจะประกอบด้วย Methods สำหรับช่วยเขียน Query เป็น Object โดยที่ไม่จำเป็นต้องเขียนเป็นแบบ Raw Query ที่ไม่ได้อ้างอิงกับกับ Database table ตัวใดตัวนึง
ส่วนที่เป็น Model Eloquent นั้นจะเป็น Class Model ที่จะทำงานเจาะจงกับ Database Table โดยตรงดังนั้นจึงต้องมีการกำหนดชื่อ Database Table ไว้โดยที่ Class นั้น Extends ความสามารถของ Eloquent ทำให้ได้รับความสามารถของ Query Builder พ่วงมาด้วยซึ่งภายใน Class หลัก ๆ จะประกอบไปด้วยชื่อ Table ของฐานข้อมูล และ Fill-able ของ Attribute Fields ที่อนุญาตให้ Insert ข้อมูลได้

note

ถ้าหากใช้ Class Model Eloquent แทน Query Builder จะเพิ่มความสะดวกที่ไม่ต้องกำหนดชื่อ Table ทุกครั้งเมื่อเรียกใช้งาน และเนื่องจาก Class Model นั้น Extends ความสามารถของ Eloquent ที่มีความสามารถของ Query Builder อยู่ด้วยทำให้สามารถใช้ Query Builder ได้ด้วยเช่นกัน นอกจากนั้นยังมีความสามารถอื่น ๆ ที่จำเป็นต้องใช้เช่น การทำ Relational Models ทั้ง Mutators และ Casting เป็นต้น

ข้อดี

รองรับ Database หลากหลายยี่ห้อ (MySQL/MariaDB, SQL Server, PostgresDB เป็นต้น)
มีระบบ Database Migrations (เพื่อควบคุม Versioning ของ Database Tables มีประโยชน์อย่างยิ่งเมื่อทำงานเป็นทีม)
มีการทำ Factories และ Seeders สำหรับการเตรียมข้อมูล (หากต้องการให้ครั้งแรกระบบสามารถ Install ได้)
มี ORM ของตัวเอง (Eloquent ORM) ที่พัฒนาเองทีม Laravel
มี Query Builder ที่มี Methods พร้อมใช้ที่ครบครันมาก ๆ ตัวนึงเลย
ระบบ Class Models สามารถกำหนด Database Connections แยกกันได้อิสระ หรือแม้กระทั่งต่างยี่ห้อ แถมยังทำ Relationships ร่วมกันได้อีก บาง Framework ไม่สามารถทำได้ขนาดนี้ 👍
มี Soft Deleting (เป็น Optional) เพื่อกำหนดไม่ต้องลบข้อมูลจริง ๆ ออกจาก Database แต่จะทำ Timestamp Record นั้นแทนการลบข้อมูล
มี Accessors & Mutators ที่ Model Class มีประโยชน์หากต้องการเปลี่ยนแปงข้อมูลก่อนแสดงผล หรือ Re-format ข้อมูลบางอย่างก่อน Save ข้อมูลไปที่ Database
ทำ API Resources ได้ โดยที่ API Resources คือ Concept การกำหนด Resources ที่หุ้ม Models ไว้อีกที โดยสามารถกำหนดรูปแบบ Array สำหรับการ Response ทำ Data wrapping และ ทำ Pagination ให้ข้อมูล
ข้อมูลประเภท Datetime ถ้า Return ออกเป็น JSON จะได้ Format มาตรฐาน ISO-8601 ทันที
ระบบ Relationships ของ Models สนับสนุนการทำความสัมพันธ์เยอะมาก (ตัวช่วย) เช่น
Relationship methods
```
One To One
One To Many
Many To Many
Has One Through
Has Many Through
One To One (Polymorphic)
One To Many (Polymorphic)
Many To Many (Polymorphic) 
```

ระบบ Relational ของ Models นั้นมีความสำคัญมาก เนื่องจากกระบวนการตรงนี้ช่วยให้เรียกข้อมูลตามสัมพันธ์ได้ง่าย โดยไม่ต้องเขียน SQL Query ตรง ๆ

เมื่อใช้ Relationships ของ Laravel เต็มรูปแบบ ทำให้เกิดการเขียนโปรแกรมที่ไม่มีการ JOIN Tables ตรงนี้ไม่ใช่มุกตลกนะครับ 😅 แต่การทำ Relation ใน Laravel นั้นเบื้องหลังการทำงานจะไม่มีการ JOIN Tables ของ Database ตรงนี้ก็มีทั้งข้อดีและข้อเสีย แต่จากผมที่ใช้งานมาผมคิดว่ามันดีมากกว่าจะเป็นข้อเสียครับ กลายเป็นว่าผมไม่ได้ JOIN Tables เหมือนแต่ก่อนเลย จะมีการ JOIN ก็ต่อเมื่ออยากทำจริง ๆ เช่นการทำ Report หรือ เมื่อคิดว่าการ JOIN นั้นให้ประสิทธิภาพดีกว่าสำหรับบางงาน
รองรับการทำ Eager Loading และ Lazy Eager Loading และมี Methods พิเศษ เช่น Aggregating Related Models สำหรับช่วยทำการคำนวณ

ข้อเสีย

กำลังนึก

8. ระบบ Views

(★★★★ 4.5/5)

ระบบ Views ของ Laravel นั้นก็จะคล้าย ๆ กับ Views ของ Framework ตัวอื่น ๆ ตามสถาปัตยกรรม MVC ที่มีการส่งข้อมูลไปที่ Views เพื่อการแสดงผล แต่สิ่งที่เพิ่มเติมใน Laravel Framework นั้นคือ Blade Templates Engines โดยเป็นตัวช่วยในการทำ Templating ด้วย (.blade.php) Directives แทนที่จะเขียน Raw PHP ไปตรง ๆ แต่เป็นการใช้ Blade Directives แทนโดยจะมีรูปแบบการจัดการแสดงผลด้วย Syntax ด้วย Blade Directives (ตัวอย่าง) จากนั้น Blade templates จะถูก Compiled Code เพื่อแปลงเป็น Plain PHP อีกทีสำหรับการ Cache จนกว่าจะจะมีการแก้ไขถึงจะมีการ Compile ใหม่ เพื่อประสิทธิภาพและความเร็ว

ข้อดี

สร้าง Views Templates ง่าย มีแม้กระทั้ง Extends Views สำหรับการทำ Layouts Inherit 😅
มี Blade Directives ใช้ง่าย และดู Clean
มี Blade Directives ที่เป็น Push Stacks อันนี้ผมชอบเป็นการส่วนตัว เพราะเราสามารถทำ Push Stacks ของพวก CSS, JS แบบแยกหน้าเป็นอิสระจากกันได้ 😊
เขียน Raw PHP ใน Blade Templates ได้
มี Blade Directives ให้ใช้มากมาย (รายละเอียด) แม้กระทั้งทำ Views Components ก็ได้
การทำ View Composers (ถ้ายังไม่เข้าใจ Concepts มี งง แน่นอน 😅) เป็นคุณสมบัติที่น่าสนใจ และน้อยคนที่จะรู้ว่ามันมีประโยชน์และใช้อย่างไร คุณสมบัตินี้พัฒนามาเพื่อใช้แก้ปัญหาการส่งข้อมูลไปที่ Views ที่กำหนด หากมีการ Render views ช่วยให้เราโฟกัสการส่งข้อมูลที่จุดเดียว จากที่เมื่อก่อนเราจำเป็นต้องส่งข้อมูลแบบเดียวกันทุกครั้งที่มีการเรียก Views ซึ่งเป็นอะไรที่ลำบาก และซ้ำซ้อนมาก ๆ
มี Laravel Mix โดยหลักการคือ เป็น Webpack สำหรับ Build CSS, JS สำหรับการใช้ผสมร่วมกับ Views ตัวอย่าง การใช้ Frontend Framework เช่น VueJS หรือ React อีกคุณสมบัติที่ ผมชอบคือสามารถทำ Versioning ได้ แก้ปัญหาการ Cached ของพวก JS, CSS

ข้อเสีย

กำลังนึก

9. ระบบ Requests และ Validation

(★★★★ 4.5/5)

ระบบ Requests ของ Laravel นั้นมีความสามารถมาก โดยเราสามารถดึงข้อมูลจาก Request ได้หลากหลายประเภท เช่น ข้อมูลแบบ GET, POST และ Input ประเภทไฟล์ ที่มาจาก Submission Form ข้อมูลที่มากับ Query String หรือ Query Path โดยมี Methods ช่วยให้เราจัดการกับข้อมูลได้ง่ายขึ้น ตัวอย่างเช่น

ตัวอย่างการจัดการข้อมูลที่มาจาก Request
// สามารถกำหนด default value หากไม่ได้มีการส่งค่ามา
$name = $request->get('name', 'John');

// สำหรับการตรวจสอบว่าข้อมูลนี้ถูกส่งมาหรือไม่
if ($request->has('name')) {
   // ...
}

// ถ้าไม่อยากเขียน if ใช้แบบนี้แทนก็ได้
$request->whenHas('name', function ($input) {
    //
});

// มีอย่างใด อย่างหนึ่ง
if ($request->hasAny(['name', 'email'])) {
   // ...
}

// สำหรับกำหนดเพื่อเอาเฉพาะข้อมูลที่ต้องการเท่านั้น
$input = $request->only(['name', 'email', 'phone']);

ระบบ Validation ทำงานร่วมกับ Requests ได้ดี เล่นได้หลากหลายท่ามาก การทำ Validate นั้นก็ทำได้อิสระ แถมมี Methods พิเศษที่ใช้ช่วยทำ Validate ได้หลากหลาย ตัวอย่าง

app/Http/Controllers/BlogController.php
/**
* การบันทึกข้อมูล Blog post
*
* @param  \Illuminate\Http\Request  $request
*/
public function store(Request $request)
{
   $validated = $request->validate([
      'title' => 'required|unique:posts|max:255', // ต้องการ Title
      'body' => 'required', // ต้องการ Body
   ]);

// จุดนี้ได้ผ่านการ Validated แล้วสามารถเขียน Statement อื่น ๆ ได้ที่นี่ ...
}

อยากให้ดู Validation Rules มีให้ใช้เยอะมาก ๆ ตัวอย่าง

ตัวอย่าง Validation Rules
// ตรวจสอบว่าข้อความมีความยาว 12 อักขระ
'title' => 'size:12',

// ตรวจสอบว่าจำนวนเต็มที่ระบุเท่ากับ 10
'seats' => 'integer|size:10',

// ตรวจสอบว่าอาร์เรย์มี 5 องค์ประกอบ
'tags' => 'array|size:5',

// ตรวจสอบว่าไฟล์ที่อัปโหลดมีขนาด 512 กิโลไบต์
'image' => 'file|size:512',

ทีนี้ลองมาดู Rules ประเภท Require ดูนะครับ อะไรจะยิบย่อยขนาดนี้ ลองคิดดูว่าถ้าไม่มี Options Rules พวกนี้ถ้าจะต้องเขียน Validate Methods เองจะวุ่นแค่ไหน 😅

ตัวอย่าง Validation Rules ประเภท Required
// 1. ท่าปกติของ required
required

// 2. required เมื่อมี Field ที่กำหนดเท่ากับ
required_if:field,value,...

// 3. required ยกเว้นเมื่อ Field ที่กำหนดเท่ากับ
required_unless:field,value,...

// 4. required เมื่อ Field ที่กำหนดระบุค่า (ตัวใดตัวนึง)
required_with:field1,field2,...

// 5. required เมื่อ Field ที่กำหนดระบุค่า (ทุกตัว)
required_with_all:field1,field2,...

// 6. required เมื่อ Field ที่กำหนดไม่ระบุค่า (ตัวใดตัวนึง)
required_without:field1,field2,...

// 7. required เมื่อ Field ที่กำหนดไม่ระบุค่า (ทุกตัว)
required_without_all:field1,field2,...

ข้อดี

ระบบ Requests มีความสามารถเยอะมาก อ่าน Docs ดูก็ได้ (เยอะเกิน อธิบายไม่หมด 😅)
Customizing Requests และ Error Messages ง่าย ได้อิสระ ทำ Authorizing Requests ได้
สามารถแยกระบบ Requests และ Validation เป็นไฟล์ใหม่ออกมาจาก Controllers ได้เพื่อให้ Code ดู Clean มากขึ้น หรือถ้าขี้เกียจแยกก็สามารถเขียนผสมกับ Methods ใน Controllers ก็ได้
Validation Rules มีหลายท่าให้เลือกใช้ใน Framework ทันทีไม่ต้องลงเพิ่ม
Validation Response รองรับทั้งแบบปกติที่เป็น MVC และถ้าใช้ผ่าน API เลือก Accept Request แบบ JSON ได้ทันที

ข้อเสีย

นึกอยู่

10. ระบบ Console Commands ระบบ Queues และ Task Scheduling

(★★★★ 4.5/5)

ระบบ Console Commands ต้องบอกก่อนว่า Framework ไหนไม่มีคุณสมบัตินี้ผมไม่อยากดูต่อเลย 😅 (ชอบส่วนตัวจริง ๆ) หลักการของระบบนี้คือ การสั่งให้ระบบทำงานผ่าน CLI แบ่งออกเป็น 2 ประเภท
- Artisan Commands คือ Commands ที่ Framework เตรียมมาให้ใช้ (ตั้งชื่อว่า Artisan)
- Custom Commands คือ Commands ที่เราสามารถเขียนขึ้นเองได้
Custom Commands เป็นส่วนที่ผมชอบที่สุด เนื่องจากการทำงานจะเป็นแบบ Background services ด้วย ตัวอย่างที่ผมเคยประยุกต์ใช้งานจริง เช่น
CLI
```
// Generate Income Report
php artisan report:income --start=2020-01-01 --end=2020-12-31

// บางทีก็เอาไว้ใช้สำหรับเขียนคำสั่งรันเพื่อซ่อมแซมฐานข้อมูล หรือการ Fix bugs
php artisan fix:refactor-user-systems

// บางทีก็เอาไว้ทำ Jobs สำหรับเอาไว้ใช้กับ Crontab ที่เป็น Task Scheduling
php artisan pull-crypto:btc --t=m5
```
ระบบ Queues ของ Laravel คือทำ Service ที่ทำงานแบบ Background services ลักษณะกระบวนการแบบ FIFO (First In First Out) มีประโยชน์ในการประยุกต์กับงานหลายประเภทที่ต้องรอ หรือทำครั้งละเยอะ ๆ ตัวอย่างที่ผมเคยประยุกต์ใช้งานจริง เช่น
- ระบบ Queues ที่ใช้ส่งข้อความ Broadcast ที่มีชื่อพนักงานในข้อความ (ประมาณ 900 คน) โดยต้อง Generate ชื่อพนักงาน ไว้ในข้อความก่อนส่ง (เป็นระบบที่จำเป็นต้องส่งทุกวัน) ผมจึงประยุกต์การทำ Crontab => Customize Commands => Queue มาช่วยในการทำระบบนี้
- ระบบ Queues ที่ใช้ส่งอีเมล สำหรับบางระบบที่จำเป็นต้องส่งอีเมลสำหรับการแจ้งข่าวสารเมื่อตรงตามเงื่อนไขที่กำหนดไว้
- ระบบ Queues ที่ใช้ส่ง SMS มีทั้ง SMS ที่ต้องส่งทุกวัน และแจ้งเตือนตามเงื่อนไขที่กำหนด
ข้อดีสำหรับการใช้ระบบ Queues นั้นหลัก ๆ จะเป็นการส่งงานที่ต้องทำเยอะ ๆ หรือนาน ๆ ไปเป็นการทำงานแบบ Background services สามารถกำหนด Options แยกกลุ่มของ Queue สามารถกำหนดจำนวนครั้งให้พยายามทำงานเมื่องานทำไม่สำเร็จ หรือหากงานมีความล้มเหลวก็ให้ลองทำงานใหม่ได้ ช่วยให้เราจัดการระบบงานต่าง ๆ ที่เป็นลำดับได้ง่ายขึ้น
ระบบ Task Scheduling ของ Laravel หลักการคือการสั่งรันคำสั่ง php artisan schedule:run ใน Crontab ทุก 1 นาที ทำให้ Task Scheduling จะถูก Execute ทุก 1 นาที มีประโยชน์คือสามารถหนดเวลาทำงานของ Schedule ตามต้องการได้ ภายในก็จะประกอบด้วย ระบบ Queues หรือ Commands Console หรือแม้กระทั้งกำหนด Methods ก็ได้โดยขึ้นอยู่กับที่เราจะประยุกต์ใช้งาน

ข้อดี

ระบบ Queues มีลักษณะแบบ FIFO ประยุกต์ใช้กับงานได้หลากหลาย และช่วยสร้างความมั่นใจว่าเราจะได้เห็นผลลัพธ์จากการทำงาน โดยงานจะทำสำเร็จ หรือไม่สำเร็จก็ตาม
ระบบ Queues รองรับการทำงานแบบ Multi servers มีการทำ Atomic locking tasks เพื่อป้องกันการทำงานซ้ำกัน
ระบบ Queues จะทำงานเป็นแบบ Async (Default) แต่สามารถสั่งให้ทำงานแบบ Sync ได้หากต้องการ
ระบบ Queues รองรับ Queue driver ที่เป็น Database (Default connection) และสามารถเปลี่ยนเป็น Redis เพื่อประสิทธิภาพสูง
ระบบ Task Scheduling ของ Laravel มี Methods ช่วยจัดการการป้องกัน Task Overlaps เพราะถ้าใช้ Crontab แบบปกติจะมีปัญหาเรื่องนี้ ดังนั้นวิธีการนี้ก็ช่วยให้เราจัดการพวก Orders งานของ Tasks ก่อนหลังได้ (แต่ Option นี้ไม่ใช่ Default นะครับ)
ระบบ Task Scheduling มี Methods สำหรับกำหนด Frequency Options ง่าย ๆ ให้เรียกใช้โดยไม่ต้องกำหนดเองตรง ๆ
ระบบ Task Scheduling รองรับการทำงานแบบ Multi servers มีการทำ Atomic locking tasks เพื่อป้องกันการทำงานซ้ำกัน

ข้อเสีย

นึกอยู่

11. ระบบ Files storage ระบบ Cache และระบบ Logs

(★★★★ 4.5/5)

ระบบ Files storage เป็นความสามารถในการ Storing และ Retrieving Files ของ Laravel โดย Default จะเป็น Local driver ที่อยู่บน Laravel Project ที่ติดตั้งอยู่ นอกจากนี้ยังสามารถเลือกที่จะเก็บไฟล์ไว้ที่อื่นได้เช่น Amazon S3 และ FTP รองรับการกำหนดสิทธิ์เข้าถึงไฟล์ ตัวอย่างการทำ Local Files & Visibility
ตัวอย่างการกำหนดค่าใน Array Configs ของ filesystem
```
'local' => [
    'driver' => 'local',
    'root' => storage_path('app'),
    'permissions' => [
        'file' => [
            'public' => 0664,
            'private' => 0600,
        ],
        'dir' => [
            'public' => 0775,
            'private' => 0700,
        ],
    ],
],
```
ระบบ Cache โดยหลักการคือการ Cached ค่าบางอย่างไว้เพื่อให้สามารถดึงออกมาเรียกใช้ได้เลย ไม่ต้องเสียเวลาคำนวณหรือเตรียมข้อมูลใหม่ โดยส่วนตัวก็ถือว่าใช้บ่อยมากพอสมควร ตัวอย่างเช่น Cache ผลจาก Query จาก Database หรือ Cache Permissions ที่นาน ๆ จะเปลี่ยนที
ตัวอย่าง Cache ข้อมูล 30 วินาที
```
$users = Cache::remember('users', 30, function () {
    return DB::table('users')->get();
});

// display values
dd($users);
```
ระบบ Logs นั้นมีตัวเลือกการใช้งานที่ดีมากพอสมควร สามารถกำหนด Log Levels เช่น debug emergency info error และ critical ส่วนความสามารถก็ เช่น กำหนดให้ส่ง Logs ผ่าน Webhook หรือ จะเก็บเป็นไฟล์ แบบไฟล์เดียว หรือแบบแยกตามวันที่
ตัวอย่างประเภท Logs
```
use Illuminate\Support\Facades\Log;

Log::emergency($message);
Log::alert($message);
Log::critical($message);
Log::error($message);
Log::warning($message);
Log::notice($message);
Log::info($message);
Log::debug($message);
```

ข้อดี

สามารถทำ Visibility ของ Files Directory ได้ง่ายกำหนด Directory ใดเข้าถึงแบบ Public หรือ Private ได้
รองรับการใช้งานแบบ Cloud storage services เช่น Amazon S3 และ FTP
สามารถ Custom Filesystems ได้เอง เช่น ของ spatie/flysystem-dropbox
มี Methods รองรับการ Storing Retrieving Deleting Files และมี Method สำหรับ Generate ชื่อไฟล์แบบ Unique ID ตัวอย่าง
ตัวอย่างการเรียกใช้ Methods สำหรับบันทึกไฟล์ข้อมูล
```
use Illuminate\Http\File;
use Illuminate\Support\Facades\Storage;

// Automatically generate a unique ID for filename...
$path = Storage::putFile('photos', new File('/path/to/photo'));

// Manually specify a filename...
$path = Storage::putFileAs('photos', new File('/path/to/photo'), 'photo.jpg'); 
```
ระบบ Cache สามารถกำหนดเวลาจดจำได้ระดับวินาที หรือสามารถกำหนดเป็นตลอดไป (แต่ต้องใช้อย่างระวังเมื่อมีการแก้ไขข้อมูลต้องสั่ง Clear Cache ทุกครั้ง)
ระบบ Logs ส่วนตัวชอบที่สามารถกำหนด Logs ออกมาเป็นวันได้ โดยช่วยเป็นเครื่องมือในการดูแลระบบในตอนงานขึ้น Production แล้ว

ข้อเสีย

นึกอยู่

12. การเขียน Testing

(★★★★ 4.5/5)

ที่จริง Laravel ใช้ PHPUnit ในการทำ Testing จะเน้นการทำ Unit Testing มากกว่าการทำ Integrate Testing ซึ่ง Laravel จะแบ่งเป็น Unit และ Feature Testing โดย Unit จะเป็นการ Testing ในส่วนเล็ก ๆ เช่น การเขียน Testing เพื่อทดสอบการทำงานบางอย่างใน 1 Method แต่จะไม่ทำงานเมื่อ Boot ระบบ Application ทำให้ไม่สามารถ Access database ได้ ดังนั้นจึงจำเป็นต้องใช้ Feature Testing แทนซึ่งสามารถใช้ความสามารถทั้งหมดของการ Testing ใน Laravel ได้

ข้อดี

Framework รองรับการเขียน Testing ในตัว รองรับการกำหนด ENV ไฟล์ .env.testing สำหรับสภาพแวดล้อมการ Testing
รองรับการรัน Testing แบบ Parallel (Async) (โดยปกติจะเป็นแบบ Sequential) อีกทั้งสามารถกำหนด Processes จำนวน CPU Core สำหรับ Parallel Process ได้
มี HTTP Tests สำหรับการ Testing HTTP requests มีส่วนจำลอง Cookies และ Sessions มี Assertions เช่น Files upload JSON Views รายละเอียดของ Assertions เยอะมาก ๆ
Console Tests สำหรับการสร้าง Commands console มี Confirmation Expectations และ Table Expectations
Browser Tests (Laravel Dusk) ที่จริงก็คือการจำลอง Web Browser สำหรับการ Testing เป็นเครื่องมือที่ติดตั้งง่ายผ่าน Composer สามารถเลือก Driver (ChromeDriver Version) ได้ สามารถเลือกติดตั้งทุก Versions ก็ได้ ความสามารถจะเป็นการจำลอง Web Browser และทำ Automation Testing หรือ Browser Macros
Database Testing สามารถสร้าง Model Factory Testing หรือใช้ Static method factory() จาก Class Model ที่มีอยู่ก็ได้ ครอบคุมการทำ Relationships Testing
Mocking Testing หลักการคือการสร้างพวก Fake Mocking ต่าง ๆ สำหรับการ Testing มีหลายละเอียดของ Fake Mocking ตามรายละเอียดของ Packages ต่าง ๆ ที่ใช้งานบน Laravel เช่น Mail Fake, Notification Fake, Queue Fake

ข้อเสีย

นึกอยู่

13. Helpers และ Ecosystems

(★★★★ 4.5/5)

ในส่วนที่เป็น Helpers ของ Laravel นั้นมีอยู่หลายอย่าง แต่มีอย่างนึงที่ช่วยชีวิตผมไว้หลายรอบแล้ว เพราะสามารถใช้ปัญหางานยาก ๆ ได้รวดเร็วนั่นคือ Collection Methods ต้องขอบคุณจริง ๆ 😅
ระบบ Mail ต้องบอกว่าเป็นตัวช่วยที่มีความพร้อมใช้งานมากจากประสบการณ์ใช้ร่วมกับ Email services ของ Mailgun โดยผมเพิ่มคุณบัติเพิ่มเติมเข้าไปให้ส่งผ่านระบบ Queues จากที่ใช้งานมาทำงานได้ดีมาก ๆ ระบบ Logs รายงานการส่งของ Mailgun ได้ผล 100% เลย
ระบบ Notifications ถือเป็นระบบที่ดี อีกระบบนึง โดยสามารถประยุกต์การส่งอีเมล การส่ง Line หรือการส่งการแจ้งเตือนใด ๆ ประโยชน์คือเมื่อทำ Notifications ระบบจะมีการบันทึกข้อมูลเก็บไว้ใน Database เพื่อเป็นการ Tracking การแจ้งเตือนช่วยให้เราจัดการการแจ้งเตือนต่าง ๆ ง่ายขึ้น และป้องกันการแจ้งเตือนซ้ำ
มี Authentication และการทำ Authorization
มี Packages อื่น ๆ ที่มีสามารถเยอะมาก (ขอยกตัวอย่างเฉพาะที่ผมเคยลองใช้แล้วกัน)
- Laravel Cashier (Stripe) ระบบตัดเงินทำงานร่วมกับ Service ของ Stripe
- Laravel Horizon ระบบ Dashboard monitor
- Laravel Passport ระบบสำหรับทำ OAuth2 server
- Laravel Sanctum ระบบทำ API Authentication เบา ๆ ด้วย API Tokens
- Laravel Telescope ระบบ Systems monitoring ที่ละเอียดมากโดยเอาไว้ส่องการทำงานภายใน และการ Tracking Events ที่จะเกิดขึ้นใน Framework
Laravel News ติดตามการอัพเดทข่าวสาร
Laracasts แหล่งเรียนรู้ฟรีดี ๆ สอนโดยทีมงานของ Laravel

14. การติดตั้ง (Production)

ที่จริงการติดตั้งก็ได้ไม่ง่ายไปซะทีเดียว เพราะถ้า Server สามารถใช้ Commands (CLI) ได้ก็จะง่ายหน่อย ดังนั้นต้องแบ่งการติดตั้งเป็น 2 ประเภท

การติดตั้งบน Shared Host Server หาก CLI ไม่ได้ ก็จะมีวิธีการติดตั้งอีกแบบแทบจะต้อง Manual Install เองทั้งหมด
การติดตั้งบน Cloud Server ก็แบ่งออกเป็น 2 แบบ
- ใช้ Docker ก็ต้องมีความรู้ ความเข้าใจในการแยก Containers การ Link Containers การ Build Dockerfile
- ติดตั้งแบบปกติคือลงทีละอย่างตั้งแต่เช่น PHP + NGINX + MySQL ก็จะนานและยุ่งยากหน่อย

(★★★★ 4/5)

ข้อดี

ใช้กับ Shared Host Server ได้ (ราคาต่อปี ถูกดี)

ข้อเสีย

ถ้าติดตั้งเองบน Cloud Server ถ้าไม่ใช้ Docker ก็มีความยุ่งยาก และทำนานหน่อย และ MA ยาก
การจะ Optimize Cloud Server ที่ติดตั้ง Laravel นั้นไม่ง่าย เพราะต้อง Tuning หลายอย่างที่ทำงานร่วมกันทั้ง PHP ทั้ง MySQL ทั้ง NGINX
ที่จริงทั้ง 2 ข้อที่กล่าวมาก็ไม่ใช่ข้อเสียของ Laravel Framework โดยตรงซะทีเดียว

15. Documents และ Community

ในส่วนของ Documents ของ Framework นั้นทีมงานตั้งใจทำมาก ๆ แยกส่วน Docs ของแต่ละ Version โดยส่วนตัวชอบตรง Release Notes และส่วน Upgrade Guide โดย Release Notes จะเป็นส่วนที่พูดถึงการเปลี่ยนแปลงและการปรับปรุงแต่ละส่วนของ Framework ของแต่ละรุ่น และ Upgrade Guide ก็เป็นส่วนที่เป็นเนื้อหาไกด์แนะนำวิธีการอัพเกรด โดยจะบอกรายละเอียดอะไรเป็น High Impact Changes และ Medium Impact Changes สุดท้ายในส่วนของ Community ของเพื่อนชาว Dev นั้นค่อยข้างใหญ่มากทั้งในไทยและต่างประเทศ ส่วนค่าจ้างหรือค่าตอบแทนของ Jobs ในไทยก็มีตั้งแต่ 15k - 150k (ต่อเดือน) เลยทีเดียว

(★★★★ 4.5/5)

ข้อดี

Community แข็งแกร่ง มีกลุ่มไทยของ Laravel บน Facebook ที่มีสมาชิกช่วยเหลือกัน ถาม-ตอบ ช่วยเหลือกันดีมาก ๆ
Community ต่างประเทศ เมื่อค้นหาปัญหาจะพบข้อมูล ถาม-ตอบ บน Stackoverflow ช่วยเหลือเยอะ
มีงาน Laracon ด้วย เป็นงานที่จัด Conference ของ Laravel โดยเฉพาะ 😅

ข้อเสีย

Laravel ออก Version ใหม่บ่อยเกิน ทั้ง ๆ ที่บางทีก็ไม่ใช่ Major Changed เท่าไหร่ แอบหงุดหงิดอยู่เหมือนกัน 😅

สรุป

สรุปจากความคิดเห็นส่วนตัว Laravel ก็เป็น Framework ที่ดี มีทุกอย่างที่ Framework ดี ๆ ควรจะมีอีกทั้งทำงานได้ดี และใช้งานได้จริง (บาง Framework ยังไม่มีครบครันขนาดนี้) และทีมหลักพัฒนามีความขยันและแข็งแกร่ง Community ใหญ่ หาข้อมูลง่าย มีอนาคต โดยรวม ๆ ก็มีแต่ข้อดีทั้งนั้น

และก็คงต้องขอพูดถึงเรื่องประสิทธิภาพการทำงานของ Framework สักหน่อย และต้องพูดตรง ๆ ว่าแย่ 😅 ด้วยความที่ Core Framework มีอะไรมาให้เยอะมาก มีความ Magic ในตัว และด้วยความที่ PHP เป็นภาษาที่เป็น Interpreter อยู่แล้ว (แปลทีละบรรทัด) ทำให้ Laravel Framework เป็น PHP Framework ที่ทำงานช้ามาก ถ้าลองหาผล Web Framework Benchmarks (ลองค้นหา Laravel จะเห็นว่าอยู่ลำดับที่เท่าไหร่) จะเห็นว่าประสิทธิภาพเมื่อเปรียบเทียบกับ Framework อื่น ๆ จะพบว่าประสิทธิภาพนั้นจะอยู่ท้าย ๆ เลย

แม้ว่าประสิทธิภาพการทำงานจะแย่ แต่ข้อดีเมื่อใช้ Laravel พัฒนา Projects นั้นสำหรับงานบางอย่างที่เคยเสียเวลาทำนาน หรือยาก ๆ ก็อาจจะเสร็จได้รวดเร็ว เพราะตัว Framework ได้เตรียมเครื่องไม้ เครื่องมือไว้พร้อมใช้มากกว่า Framework อื่นมาก มันก็เป็นเหตุผลที่ว่าทำไมทุกวันนี้ผมก็ยังพัฒนาโปรเจค ด้วย Laravel อยู่บ้างซึ่งก็เลือกตามงานที่เหมาะสม เพราะผมมองว่ามันก็เป็น Framework ที่ดีแต่ต้องเลือกใช้ให้เหมาะสมกับงาน (แต่หลัง ๆ ผมไม่ขึ้นโปรเจคใหม่ด้วย Laravel ละ 😄)

แต่ถ้ามีโอกาสได้สอนใคร หรือแนะนำใครที่เริ่มต้นใหม่ ผมเองก็คงไม่แนะนำ Laravel แล้วนะครับ ที่จริงต้องบอกว่าไม่แนะนำภาษา PHP เลยมากกว่า 😅

มุมมองเกี่ยวกับธุรกิจ

ข้อนี้สำคัญมาก เพราะถึงแม้ว่า Laravel ใช้ได้กับ Shared Host Server ได้ก็จริง (ทำให้ต้นทุนของ Deploy ระบบถูก) แต่สมมุติอนาคตอยากสเกลระบบให้ใหญ่ขึ้น เช่น ให้รองรับข้อมูลที่มากขึ้น หรือรองรับผู้ใช้งานที่มากขึ้น Laravel อาจจะไม่ใช่ตัวเลือกที่ดีมากนัก เพราะประสิทธิภาพของ Framework นั้นไม่ได้ดีเลย ซึ่งเมื่อ Shared Host เริ่มรับไม่ไหวก็ต้องย้ายไปใช้ Cloud Server แทน โดยค่าใช้จ่ายต่อเดือนจะสูงมาก ๆ เมื่อเทียบกับภาษาอื่นในระดับสเกลเดียวกันโดยขอยกตัวอย่างดังนี้

สมมุติอยากได้ Traffic Concurrent ประมาณ 10,000 Request/s ดังนั้น

Laravel (PHP) = ต้องใช้ CPU 48 Core Ram 43.2 GB ($1,104.86/เดือน ~ 37,195.11 บาท) อ้างอิง
ExpressJS (JS) = ต้องใช้ CPU 4 Core Ram 8 GB ($134.07/เดือน ~ 4,513.47 บาท) อ้างอิง

(อ้างอิง) Web Frameworks Benchmark (เทียบบัญญัติไตรยางค์)
- CPU: 8 Cores (AMD FX-8320E Eight-Core Processor)
- RAM: 16 GB
- OS: Linux

จะเห็นว่าค่าใช้จ่ายห่างกันประมาณ 8 เท่า! ฟังไม่ผิดหรอกครับ 😅 และถ้าอยากได้ Concurrent มากกว่านี้ก็ลอง เทียบบัญญัติไตรยางค์ ดูนะครับ...

ดังนั้นส่วนตัวมองว่า Laravel ไม่เหมาะกับธุรกิจขนาดใหญ่ที่ซีเรียสเรื่องค่าใช้จ่ายครับ

info

ทั้งหมดเป็นแค่การเทียบบัญญัติไตรยางค์ ในทางปฏิบัติจริงตัวเลขค่าใช้จ่ายอาจจะแตกต่างจากนี้ตามเงื่อนไขอย่างอื่นด้วย
ถึงแม้จะพยายามทำ Performance tuning ให้ PHP แล้วแต่ก็อาจจะยังไม่เพียงพออาจจะต้อง Tuning อย่างอื่นร่วมด้วย เช่น Database และ NGINX หรือการทำ Load balancing ช่วย (แม้จะทำทั้งหมดก็แค่ช่วยให้ดีขึ้น แต่ก็ยังสู้ Node.JS ไม่ได้อยู่ดี)
สาเหตุที่จะทำให้ Laravel ช้านั้นมีหลายเหตุผลมาก เช่น
1. วิธีการ Coding ที่ไม่ดี
2. หลักการ Eager loading และ Lazy loading ที่ใช้ผิดวิธี และการใช้ One To One และ One To Many ผิดวิธี
3. ควรใช้ Cache สำหรับค่าที่นาน ๆ เปลี่ยนที เช่น ค่า Permission Roles
4. กระบวนการ Deploy ของ Laravel ที่มีการทำ Optimize cache ค่าต่าง ๆ เช่น ระบบ Route ระบบ Config ระบบ Services ระบบ Views
5. เข้าใจ Lifecycle ของ Laravel มีอะไรถูก Autoload ขึ้นมาบ้าง มีอะไรถูกเรียกใช้บ้าง จะลดได้อย่างไร

แถม

Reviews Laravel ดีขนาดนี้ สุดท้ายถ้าถามว่าคุ้มมั้ยที่จะเลือกเขียน Framework เดียว หรือภาษาเดียวไปตลอดชีวิต ผมขออธิบายแบบนี้ละกัน มันก็แบ่งออกเป็น 2 ประเด็น

ถ้า Mindsets บอกว่า "ก็ดีอยู่แล้ว... ใช้ไปไม่มีปัญหาอะไร ใช้ทำงานได้เงินดีด้วย" ถ้าเป็นแบบนี้ก็คงจะเปลี่ยนแนวคิดอะไรยากครับ เพราะมันก็คุ้มในมุมมองแบบนี้ แต่อยากให้ไปอ่านประเด็นที่ 2 ต่อ 😅
ถ้า Mindsets บอกว่า "เราคือนักพัฒนา เราคือ Developer ไม่หยุดอยู่กับที่แค่นี้แน่ ๆ" ก็ต้องถามตัวเองก่อนว่าเป้าหมายสูงสุดอยากเป็น Developer ไปอีกกี่ปี "อืม... เขียนมานานก็พอรู้อยู่ว่ามันก็มีปัญหา" การไปลองเปิดโลก หรือไปเขียนรู้อะไรใหม่ ๆ หรือภาษาใหม่ ๆ มันก็คุ้มนะครับ 😊

อ่อสุดท้าย ฝากบทความนี้ด้วยนะครับ Laravel Best practices (แนวทางปฎิบัติที่ดีที่สุดสำหรับ Laravel) เป็นเวอร์ชันแปลภาษาไทยครับ 🚀

Hey 👋.
You can now buy me a coffee!
ช่วยบริจาคสำหรับค่า `กาแฟ` คลิก! ☕️

Table of contents

Intro​

เกี่ยวกับ Laravel เบื้องต้น​

Reviews​

1. การติดตั้ง (Development)​

2. ระบบ Environment Configuration​

3. ระบบ Directory Structure​

4. ระบบ Routing​

5. ระบบ Middleware​

6. ระบบ Controllers​

7. ระบบ Models (ORM) และ Database​

8. ระบบ Views​

9. ระบบ Requests และ Validation​

10. ระบบ Console Commands ระบบ Queues และ Task Scheduling​

11. ระบบ Files storage ระบบ Cache และระบบ Logs​

12. การเขียน Testing​

13. Helpers และ Ecosystems​

14. การติดตั้ง (Production)​

15. Documents และ Community​

สรุป​

มุมมองเกี่ยวกับธุรกิจ​

แถม​

Intro

เกี่ยวกับ Laravel เบื้องต้น

Reviews

1. การติดตั้ง (Development)

2. ระบบ Environment Configuration

3. ระบบ Directory Structure

4. ระบบ Routing

5. ระบบ Middleware

6. ระบบ Controllers

7. ระบบ Models (ORM) และ Database

8. ระบบ Views

9. ระบบ Requests และ Validation

10. ระบบ Console Commands ระบบ Queues และ Task Scheduling

11. ระบบ Files storage ระบบ Cache และระบบ Logs

12. การเขียน Testing

13. Helpers และ Ecosystems

14. การติดตั้ง (Production)

15. Documents และ Community

สรุป

มุมมองเกี่ยวกับธุรกิจ

แถม