Bài này chia sẻ theo góc nhìn hệ thống lớn: ra quyết định kỹ thuật khi số job tăng nhanh, dữ liệu lớn, nhiều worker, CI/CD liên tục, thậm chí realtime.

1. Nguyên tắc số 1: Scheduler phải “nhẹ” — việc nặng đẩy qua queue

Tư duy: Scheduler là “orchestrator”, không phải “executor”.

Scheduler chỉ làm 2 việc:

• Quyết định “đúng giờ thì trigger cái gì”
• Dispatch nhanh, ghi dấu vết (batch metadata)

Việc nặng (DB scan, gọi API, gửi notify hàng loạt, reconcile, billing…) → chạy trong queued jobs + nhiều worker.

Trade-off:

• ✅ Ưu: Scale bằng worker, retry/backoff chuẩn, tách tải khỏi scheduler
• ⚠️ Nhược: Job có thể chạy trễ → phải thiết kế theo “batch time” (xem phần 4)

Sai lầm thường gặp: Nhét logic nặng vào scheduler (closure/command) rồi “đỡ nghẽn” bằng cách tăng CPU. Đến lúc 100 lịch/ngày thì scheduler thành single-point bottleneck.

Ví dụ:

<?php

// routes/console.php
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Schedule;

// ❌ SAI: Logic nặng trực tiếp trong scheduler
Schedule::call(function () {
    DB::table('recent_users')->chunk(100, function ($users) {
        foreach ($users as $user) {
            // Process payment, send email, update DB...
            // Nếu có 1000 users, scheduler sẽ bị block rất lâu
        }
    });
})->dailyAt('09:00');

// ✅ ĐÚNG: Scheduler chỉ dispatch job
Schedule::job(new ProcessRecentUsersJob)
    ->dailyAt('09:00');

Scheduler chỉ trigger đúng giờ, không bao giờ chạy logic business trực tiếp. Worker sẽ xử lý job trong queue.

2. “Đúng một lần” theo nghĩa business > “đúng một lần” theo nghĩa kỹ thuật

Ở hệ thống lớn, “at least once” là mặc định. Scheduler/queue/worker/retry/deploy đều có thể làm job chạy lại.

Best practice: Thiết kế job theo idempotent:

• Chạy 2 lần vẫn ra kết quả đúng
• Side-effect (charge/send/update) phải có khóa logic hoặc unique key

Dùng lock ở đúng tầng:

• Tầng scheduler: Chống chồng / chạy một server (khi HA)
• Tầng job/business: Lock theo entity/time-window (mới là thứ bảo vệ cuối)

Trade-off:

• Lock nhiều quá → Giảm throughput, dễ nghẽn nếu lock sai granularity
• Lock ít quá → Trùng dữ liệu/side-effect

Sai lầm thường gặp: Tin tuyệt đối vào “chống chồng” của scheduler rồi bỏ qua idempotency. Một ngày deploy “đúng lúc”, bạn sẽ hiểu.

Ví dụ:

Job có idempotency key dựa trên entity_id + batch_time. Concept này áp dụng cho mọi job có side-effect quan trọng. Trong scheduler, bạn chỉ dispatch job với metadata:

<?php

// routes/console.php
use Illuminate\Support\Facades\Schedule;

Schedule::job(new ProcessOrdersJob)
    ->dailyAt('09:00');

Job sẽ tự implement idempotency check trong handle() method để đảm bảo không xử lý trùng.

3. Khi nào dùng runInBackground() và khi nào “bắt buộc” dùng queue?

Tôi coi runInBackground() là giải pháp tactical, không phải chiến lược lâu dài.

Dùng runInBackground() khi:

• Task là command/exec tương đối ngắn
• Không cần scale theo tải
• Bạn chỉ cần tránh scheduler bị giữ process quá lâu

Bắt buộc đưa qua queue khi:

• Task có thể chạy vài chục giây/phút
• Task có thể “nở” theo dữ liệu (data grows)
• Task có side-effect quan trọng (payment/notify hàng loạt)
• Cần retry/backoff, rate-limit, phân ưu tiên

Sai lầm thường gặp: “Task đang lâu → thêm runInBackground()” và coi như xong. Thực tế bạn chỉ chuyển nghẽn từ scheduler sang CPU/DB/connections của cùng máy.

Ví dụ:

<?php

// routes/console.php
use Illuminate\Support\Facades\Schedule;

// ✅ Dùng runInBackground cho command nhẹ, không cần scale
Schedule::command('cache:clear')
    ->hourly()
    ->runInBackground();

Schedule::command('emails:send')
    ->dailyAt('02:00')
    ->runInBackground();

// ✅ Bắt buộc dùng queue cho job có side-effect quan trọng
Schedule::job(new SendOrderConfirmationJob)
    ->dailyAt('09:00'); // Không có runInBackground, vì đã là queued job

Chỉ có 2 loại command dùng runInBackground():

1. Maintenance commands (cleanup, cache) — không ảnh hưởng business
2. Monitoring commands — cần chạy nhanh, không cần retry

Tất cả job business đều qua queue để có retry/backoff/scale.

4. Bài toán lớn nhất của hệ queue: Job chạy trễ → lệch cửa sổ dữ liệu

Đây là điểm phân biệt hệ “chạy được” và hệ “chạy đúng”.

Vấn đề:

• Scheduler trigger 09:00, worker chạy 09:04
• Nếu job query theo now() lúc 09:04, bạn vừa:
  • Miss dữ liệu 09:00–09:04 (tùy window)
  • Hoặc duplicate với batch trước

Giải pháp: Scheduler đóng dấu batch time ngay lúc dispatch (tôi hay gọi scheduledAt/batchAt). Job luôn dùng scheduledAt để:

• Tính window dữ liệu
• Log/audit theo batch
• Tạo idempotency key

Trade-off:

• Tốn thêm metadata, thêm “kỷ luật” trong code
• Đổi lại: Batch chạy trễ vẫn đúng cửa sổ, dễ đối soát, dễ replay theo batch

Ví dụ — Pattern batch timestamp:

Concept: Scheduler đóng dấu batch time ngay lúc dispatch. Job nhận batch time và dùng để tính time window, không dùng now().

Sử dụng trong Laravel 12:

<?php

// routes/console.php
use Illuminate\Support\Facades\Schedule;

Schedule::job(new ProcessOrdersJob)
    ->dailyAt('09:00');

Job sẽ nhận scheduledAt từ scheduler event và dùng để query đúng time window.

Ví dụ với sub-minute scheduling trong Laravel 12:

Theo Laravel 12.x Sub-Minute Scheduled Tasks:

<?php

// routes/console.php
use Illuminate\Support\Facades\Schedule;

// Laravel 12 hỗ trợ sub-minute scheduling
Schedule::call(function () {
    // Process tasks every 30 seconds
})->everyThirtySeconds();

Lợi ích:

• Job chạy trễ 3 phút vẫn query đúng cửa sổ 09:00–09:01
• Dễ đối soát: “Batch 09:00 đã xử lý bao nhiêu records?”
• Dễ replay: “Chạy lại batch 09:00” → chỉ cần tạo job với jobCreatedAt = 09:00

5. Tách “workload shape”: Phân queue theo ưu tiên, tránh job “rác” ăn tài nguyên job “sống còn”

Một hệ thống lớn sẽ có job kiểu:

• Critical: Billing, payment, cancel, inventory, security
• Default: Vận hành
• Low: Marketing, remind, digest

Best practice: Tách queue theo priority, scale worker theo queue. Đặt rule: Job low không bao giờ được làm chậm job critical.

Trade-off:

• Nhiều queue → Config vận hành phức tạp hơn (supervisor/horizon)
• Nhưng nếu không tách, bạn sẽ gặp kiểu “19h campaign bắn notify” làm nghẽn payment

Lưu ý: Trong scheduler, bạn có thể chỉ định queue khi schedule job:

Theo Laravel 12.x Scheduling Queued Jobs, method job() nhận queue name làm tham số thứ 2:

<?php

// routes/console.php
use Illuminate\Support\Facades\Schedule;

Schedule::job(new SendOrderConfirmationJob, 'critical')
    ->dailyAt('09:00');

Hoặc nếu job class đã có property $queue, scheduler sẽ tự động dùng queue đó.

6. “Thundering herd” lúc tròn giờ: Kẻ thù của DB và API

Hệ thống lớn rất hay bị “dồn lịch” vào 00:00, 09:00, 12:00, 19:00…

Best practice:

• Stagger: Dàn đều theo phút/giây
• Nếu bắt buộc tròn giờ: Chia nhỏ thành nhiều job chunk, có rate-limit/backoff
• Không quét toàn bảng: Dùng cursor/chunk theo index, watermark theo batch

Sai lầm thường gặp: Một job “tổng hợp cuối ngày” chạy 00:00 quét cả bảng 50 triệu dòng. Đêm đó DB chết, sáng không ai biết vì không có alert.

Ví dụ — Stagger pattern trong scheduler:

<?php

// routes/console.php
use Illuminate\Support\Facades\Schedule;

// Dàn đều theo phút để tránh thundering herd
$times = ['9:03', '10:03', '11:03', '12:03', '13:03', '14:03', '15:03', '16:03', '17:03', '18:03', '19:03', '20:03', '21:03'];

foreach ($times as $time) {
    Schedule::job(new ProcessHourlyTaskJob)
        ->at($time);
}

7. Observability là bắt buộc: “Không ai biết scheduler fail” = thất bại hệ thống

Scheduler fail nguy hiểm vì nó âm thầm.

Best practice:

• Log theo batch (scheduledAt, job name, duration, result)
• Có alert khi fail (hook/event/ping tùy hệ)
• Có “schedule inventory”: Định kỳ audit lịch chạy (ít nhất kiểm lịch sau deploy)

Trade-off:

• Thêm log/metrics → Tốn công + tốn storage
• Nhưng thiếu nó thì khi sự cố xảy ra, bạn mất nhiều giờ “đào mộ”

Ví dụ — Scheduler hooks trong Laravel 12:

Theo Laravel 12.x Task Hooks:

<?php

// routes/console.php
use Illuminate\Support\Facades\Schedule;

Schedule::command('emails:send')
    ->daily()
    ->before(function () {
        // The task is about to execute...
    })
    ->after(function () {
        // The task has executed...
    })
    ->onSuccess(function () {
        // The task succeeded...
    })
    ->onFailure(function () {
        // The task failed...
    });

Scheduler setup:

# Cron entry
* * * * * cd /path-to-app && php artisan schedule:run >> /dev/null 2>&1

Kiểm tra lịch chạy:

# Laravel 12: Xem tất cả scheduled tasks
php artisan schedule:list

8. CI/CD & Deploy: Đừng để deploy tạo ra double-run / half-run

Ở môi trường deploy liên tục, scheduler/worker cần “graceful”:

Best practice:

• Tránh chạy song song 2 version job logic cho cùng một batch
• Worker restart có kiểm soát; job quan trọng có idempotency key để chịu được retry/duplicate
• Nếu hệ HA nhiều scheduler node: Phải có chiến lược “one server” + shared lock store

Sai lầm thường gặp: Deploy xong “mọi thứ xanh”, nhưng lịch 09:00 bị chạy 2 lần vì 2 scheduler node cùng tick.

Ví dụ — Laravel 12 onOneServer():

Theo Laravel 12.x Running Tasks on One Server:

<?php

// routes/console.php
use Illuminate\Support\Facades\Schedule;

// Nếu có nhiều scheduler server, dùng onOneServer() để chạy chỉ trên 1 server
Schedule::command('emails:send')
    ->daily()
    ->onOneServer(); // Chỉ chạy trên 1 server, dùng cache để lock

Lưu ý: Job vẫn phải idempotent vì:

• Retry khi fail
• Deploy có thể làm job chạy lại
• Worker restart có thể làm job chạy lại

9. Tổ chức code: Khi Kernel.php “phình to”

Khi số lượng lịch tăng, Kernel.php sẽ rất dài (có thể lên 300+ lines).

Best practice — Laravel 12: Tách helper functions theo domain để dễ maintain:

Theo Laravel 12.x Defining Schedules, bạn có thể định nghĩa trong routes/console.php và tách thành helper functions:

<?php

// routes/console.php
use Illuminate\Support\Facades\Schedule;

// Tách theo domain để dễ maintain
schedulePaymentTasks();
scheduleNotificationTasks();
scheduleCleanupTasks();

function schedulePaymentTasks(): void
{
    Schedule::command('payments:process')
        ->dailyAt('09:00');

    Schedule::command('payments:retry')
        ->dailyAt('14:00');
}

function scheduleNotificationTasks(): void
{
    Schedule::command('notifications:send')
        ->hourly();

    Schedule::command('notifications:digest')
        ->dailyAt('20:00');
}

function scheduleCleanupTasks(): void
{
    Schedule::command('cache:clear')
        ->hourly()
        ->runInBackground();
}

Hoặc dùng withSchedule trong bootstrap/app.php và tách thành methods:

<?php

// bootstrap/app.php
use Illuminate\Console\Scheduling\Schedule;

->withSchedule(function (Schedule $schedule) {
    schedulePaymentTasks($schedule);
    scheduleNotificationTasks($schedule);
    scheduleCleanupTasks($schedule);
});

function schedulePaymentTasks(Schedule $schedule): void
{
    $schedule->command('payments:process')->dailyAt('09:00');
    $schedule->command('payments:retry')->dailyAt('14:00');
}

Lợi ích:

• Dễ review: Mỗi function = 1 domain
• Dễ test: Có thể test từng domain riêng
• Dễ ownership: Team có thể own từng domain
• Tránh Kernel.php phình to: Code nằm trong routes/console.php hoặc helper functions

Schedule Groups — Laravel 12:

Theo Laravel 12.x Schedule Groups, bạn có thể nhóm các tasks có cùng cấu hình để tránh lặp lại code:

<?php

// routes/console.php
use Illuminate\Support\Facades\Schedule;

// ❌ SAI: Lặp lại cấu hình cho từng task
Schedule::command('emails:send')
    ->daily()
    ->onOneServer()
    ->timezone('America/New_York');

Schedule::command('emails:prune')
    ->daily()
    ->onOneServer()
    ->timezone('America/New_York');

// ✅ ĐÚNG: Dùng Schedule Groups để nhóm tasks có cùng cấu hình
Schedule::daily()
    ->onOneServer()
    ->timezone('America/New_York')
    ->group(function () {
        Schedule::command('emails:send');
        Schedule::command('emails:prune');
    });

Lợi ích của Schedule Groups:

• Giảm lặp lại code: Không cần lặp lại onOneServer(), timezone(), withoutOverlapping() cho từng task
• Dễ maintain: Thay đổi cấu hình một lần áp dụng cho cả nhóm
• Tăng tính nhất quán: Đảm bảo tất cả tasks trong nhóm có cùng cấu hình

10. Timezone handling: Luôn nhất quán

Best practice: Cố định timezone theo business, không dùng server timezone. Nguyên tắc: Tất cả scheduled tasks phải dùng cùng một business timezone để đảm bảo tính nhất quán.

Ví dụ — Laravel 12 timezone:

Theo Laravel 12.x Scheduling Timezones, có 2 cách set timezone:

Cách 1: Set timezone trong config (khuyến nghị):

Khi tất cả tasks dùng cùng business timezone, thêm schedule_timezone vào config/app.php:

<?php

// config/app.php
return [
    'timezone' => 'UTC', // Application timezone

    'schedule_timezone' => 'Asia/Tokyo', // Business timezone cho scheduled tasks
];

Với cấu hình này, tất cả scheduled tasks sẽ tự động dùng timezone Asia/Tokyo trừ khi được ghi đè bởi method timezone() trong từng task cụ thể.

Cách 2: Set timezone cho từng task riêng:

Chỉ định timezone cho task cụ thể bằng method timezone():

<?php

// routes/console.php
use Illuminate\Support\Facades\Schedule;

// Set timezone cho task cụ thể (ghi đè config)
Schedule::command('report:generate')
    ->timezone('America/New_York')
    ->at('2:00');

Lưu ý quan trọng về DST (Daylight Saving Time):

Theo Laravel 12.x Scheduling Timezones, một số timezone sử dụng DST có thể ảnh hưởng đến thời gian thực thi. Khi DST thay đổi, task có thể chạy 2 lần hoặc không chạy. Nên tránh dùng timezone có DST khi có thể.

Nguyên tắc áp dụng:

• ✅ Nên: Set timezone một lần trong config/app.php với key schedule_timezone nếu tất cả tasks dùng cùng business timezone
• ⚠️ Tránh: Set timezone cho từng task riêng lẻ → dễ quên, dễ sai, khó maintain
• ⚠️ Tránh: Dùng timezone có DST → có thể ảnh hưởng đến thời gian thực thi khi DST thay đổi

Kết luận: Framework cho quyết định kỹ thuật

Khi thêm một scheduled task mới, tôi tự hỏi 6 câu:

1. Task này có side-effect quan trọng không? → Nếu có → Idempotent + audit batch
2. Dữ liệu tăng thì task tăng theo tuyến nào? → Nếu O(N) theo bảng lớn → Phải có watermark/chunk/index
3. Chạy trễ có làm sai cửa sổ dữ liệu không? → Nếu có → Cần scheduledAt/batchAt
4. Có được phép chạy song song không? → Nếu không → Overlap guard + lock theo business key
5. Nó thuộc priority nào? → Nếu không critical → Đừng để nó chạy chung queue với critical
6. Fail thì ai biết, trong bao lâu? → Nếu câu trả lời mơ hồ → Bổ sung observability trước

Checklist áp dụng

•  Scheduler chỉ dispatch queued jobs, không chạy logic nặng
•  Tất cả job có side-effect đều idempotent
•  Job dùng batchTime/scheduledAt để tính time window, không dùng now()
•  Job dùng chunkById hoặc cursor pagination cho data lớn
•  Job có stagger/rate-limit khi gọi external API
•  Job log theo batch time để dễ đối soát
•  Scheduler có helper methods theo domain, không phình to schedule()
•  Timezone nhất quán: Business timezone, không dùng server timezone
•  Queue được phân priority (critical/default/low)
•  Có alert khi scheduler/job fail

Tài liệu tham khảo: Laravel 12.x Task Scheduling

The post Laravel Scheduler: Tư duy thiết kế, trade-off và best practices cho hệ thống lớn appeared first on Tomoshare.

Laravel purity là một thư viện hỗ trợ filter và sort data một cách dễ dàng đơn giản hỗ trợ trực tiếp cho laravel framework. Để biết được sự lợi hại của thư viện này. Hãy cùng mình mò mẫm nó nhé. Let’s gooooooo !!!

Đặt vấn đề

Khi chúng ta viết api để filter nhiều giá trị cùng một lúc thì service của chúng ta sẽ khá dài dòng và rườm rà. Để viết ra một hàm filter dùng chung thì sẽ tốn khá nhiều thời gian và chất xám. Vì vậy thư viện này sinh ra với mục đích tối giản hơn về cách filter và sort dữ liệu.

Lợi ích khi sử dụng

Khi chúng ta viết một cách bình thường:

public function index(Request $request)
{
    $query = Post::query();

    // Lọc theo tiêu đề
    if ($request->has('title')) {
        $query->where('title', 'like', '%' . $request->input('title') . '%');
    }

    // Lọc theo nội dung (content)
    if ($request->has('content')) {
        $query->where('content', 'like', '%' . $request->input('content') . '%');
    }

    // Lọc theo ngày xuất bản (published_at)
    if ($request->has('published_at')) {
        $query->whereDate('published_at', '=', $request->input('published_at'));
    }

    $posts = $query->get();

    return response()->json($posts);
}

Khi dùng thư viện trên

public function index(Request $request)
{
    $query = Post::filter()->get();

    return response()->json($posts);
}

Thật là ngắn gọn và súc tích phải không nào !!!

Cách cài đặt và sử dụng

Mở terminal của project lên và cài bằng composer nhé:

composer require abbasudo/laravel-purity 

php artisan vendor:publish --tag=purity 

Lệnh này để publish thư mục `config/purity` cho phép chúng ta có thể custom được filter mà chúng ta muốn.

Vậy là thư viện đã sẵn sàng để sử dụng. Tiếp theo hãy tìm tới Model mà bạn muốn filter nhé. Ở đây mình đang filter cho Model Post

<?php

namespace App\Models;

use Abbasudo\Purity\Traits\Filterable;
use Abbasudo\Purity\Traits\Sortable;
use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Database\Eloquent\Model;

class Post extends Model
{
    use HasFactory;
    use Filterable;
    use Sortable;

    protected $filterFields = [
        'id',
        'title',
        'content',
        'published_at',
        'category_id',
        'category'
    ];

    public function category()
    {
        return $this->belongsTo(Category::class);
    }
}

Các bạn chỉ cần Use Filterable và Sortable của thư viện để sử dụng. Mảng $filterFields là những giá trị mình muốn filter nhé. Ở đây mình có Category là relation của Post.

Tiếp theo trong function của mình dùng câu lệnh này nữa là oke nhoé :))

return Post::sort()->filter()->with('category')->get();

Đây là một url để chúng ta filters nhé

GET /api/posts?filters[field][operator]=value

Dưới đây là một số operator mà thư viện hỗ trợ

Test kết quả

Dưới đây là video mình test bằng Postman. Các bạn có thể test thử xem nhé!

Tổng kết

Đây là một thư viện khá hay mà mình vô tình đọc được. Ở trên mình tập trung nhiều cho phần filter, còn sort cũng khá hay, các bạn khám phá thử xem nhá.

Hy vọng các bạn cảm thấy nó thú vị và có thể áp dụng vào dự án nếu có những tính năng tương tự. Cảm ơn mọi người đã dành thời gian đọc ạ ☺️☺️☺️

Nguồn:

• Trang chủ của thư viện https://abbasudo.github.io/laravel-purity/
• https://laravel-news.com/filter-api-responses-with-laravel-purity?ref=dailydev

The post Sort và filter dữ liệu dễ dàng hơn với Laravel Purity appeared first on Tomoshare.

Chúng cũng giúp dễ dàng tạo mã có thể đọc và kiểm tra được mà chúng ta có thể cùng nhau làm việc ở mọi nơi và mọi lúc cũng như giúp bạn biết cách viết mã tốt nhất

SOLID là từ viết tắt đại diện cho năm nguyên tắc thiết kế của thiết kế lớp Hướng đối tượng. Những nguyên tắc này là:

• S – Single-responsibility Principle
• O – Open-closed Principle
• L – Liskov Substitution Principle
• I – Interface Segregation Principle
• D – Dependency Inversion Principle

Mỗi nguyên tắc đóng vai trò là kim chỉ nam để thúc đẩy các phương pháp thiết kế tốt và giúp đảm bảo rằng mã có thể mở rộng, bảo trì và dễ hiểu. Trong bài viết này, chúng ta sẽ khám phá sâu từng nguyên tắc SOLID và cách chúng có thể được áp dụng cho Laravel.

Single-responsibility Principle

Nguyên tắc trách nhiệm duy nhất, hay SRP, tuyên bố rằng một lớp chỉ có một lý do để thay đổi. Nói cách khác, một lớp chỉ nên có một trách nhiệm và tập trung làm tốt một việc. Nguyên tắc này giúp giảm độ phức tạp của mã và giúp bảo trì dễ dàng hơn.

Trong Laravel, SRP có thể được áp dụng bằng cách tạo các lớp nhỏ hơn, tập trung hơn để xử lý các tác vụ cụ thể. Ví dụ, thay vì có một lớp duy nhất xử lý đăng ký và đăng nhập của người dùng, sẽ tốt hơn nếu có các lớp riêng biệt để làm từng việc này.

class User
{
	public function register($data) {
    // Register user logic
  }

  public function login($data) {
    // Login logic
  }
}

Thay vào đó, mỗi lớp sẽ có một nhiệm vụ riêng biệt.

class UserRegistration {
  public function register($data) {
    // Register user logic
  }
}

class UserLogin {
  public function login($data) {
    // Login logic
  }
}

Open/Closed Principle (OCP)

Nguyên tắc đóng mở có thể gây nhầm lẫn vì nó là nguyên tắc hai chiều. Theo định nghĩa của Bertrand Meyer trên Wikipedia, nguyên tắc đóng mở (OCP) nói rằng các thực thể phần mềm (lớp, mô-đun, chức năng, v.v.) phải mở để mở rộng nhưng đóng để sửa đổi.

Định nghĩa này có thể gây nhầm lẫn, nhưng một ví dụ và sự làm rõ thêm sẽ giúp bạn hiểu rõ hơn.

Có hai thuộc tính chính trong OCP:

• Nó có thể open – Điều này có nghĩa là bạn có thể mở rộng những gì mô-đun có thể thực hiện.

• Nó closed để sửa đổi — Điều này có nghĩa là bạn không thể thay đổi mã nguồn, mặc dù bạn có thể mở rộng hoạt động của một mô-đun hoặc thực thể.

OCP có nghĩa là một lớp, mô-đun, hàm và các thực thể khác có thể mở rộng hành vi của chúng mà không cần sửa đổi mã nguồn. Nói cách khác, một thực thể có thể được mở rộng mà không cần sửa đổi chính thực thể đó.

Trong Laravel, nguyên tắc này có thể được áp dụng bằng cách sử dụng các interface và các abstract class. Bằng cách xác định interface cho một tác vụ cụ thể, có thể tạo ra nhiều triển khai thực hiện tác vụ đó, mỗi tác vụ có chức năng riêng.

class PaymentMethod {
  public function processPayment($amount) {
    // Payment processing logic
  }
}

Thay vào đó:

interface PaymentMethodInterface {
  public function processPayment($amount);
}

Chúng ta có thể implement để sử dụng và không ảnh hưởng gì đến mã nguồn:

class CreditCardPayment implements PaymentMethodInterface {
  public function processPayment($amount) {
    // Credit card payment processing logic
  }
}

class BankTransferPayment implements PaymentMethodInterface {
  public function processPayment($amount) {
    // Bank transfer payment processing logic
  }
}

Liskov Substitution Principle (LSP)

LSP tuyên bố rằng các đối tượng của siêu lớp có thể được thay thế bằng các đối tượng của lớp con mà không ảnh hưởng đến tính chính xác của chương trình. Nói cách khác, một lớp con phải thay thế cho lớp cha của nó.

Trong Laravel, nguyên tắc này có thể được áp dụng bằng cách sử dụng tính kế thừa và đa hình. Bằng cách tạo một lớp cơ sở xác định chức năng chung cho một tập hợp các lớp, có thể tạo các lớp con kế thừa từ lớp cơ sở và thêm chức năng độc đáo của riêng chúng.

Một ví dụ rất phổ biến là kịch bản hình chữ nhật, hình vuông. Rõ ràng là tất cả các hình vuông đều là hình chữ nhật vì chúng là tứ giác có bốn góc đều là góc vuông. Nhưng không phải hình chữ nhật nào cũng là hình vuông. Để là hình vuông thì các cạnh của nó phải có cùng độ dài.

Hãy ghi nhớ điều này, giả sử bạn có một lớp hình chữ nhật để tính diện tích hình chữ nhật và thực hiện các thao tác khác như set màu sắc cho nó

class Rectangle {
    public function setWidth($width)
		{
        $this->width = $width;
    }

    public function setHeight($height) 
		{
				$this->height = $height;
    }

    public function setColor($color)
		{
				// set color processing logic
    }

    public function getArea() 
		{
        return $this->width * $this->height;
    }
}

Biết rõ rằng tất cả các hình vuông đều là hình chữ nhật, bạn có thể kế thừa các đặc tính của hình chữ nhật. Vì chiều rộng và chiều cao phải giống nhau nên bạn có thể điều chỉnh nó:

class Square extends Rectangle {
    public function setWidth($width)
		{
        $this->width = $width;
        $this->height = $width;
    }
		public function setHeight($height)
		{
        $this->width = $height;
        $this->height = $height;
    }
}

Nhìn vào ví dụ, nó sẽ hoạt động bình thường:

$rectangle = new Rectangle();
$rectangle->setWidth(10);
$rectangle->setHeight(5);
$area = $rectangle->getArea());
echo $area; // 50

Ở phần trên, bạn sẽ nhận thấy rằng một hình chữ nhật được tạo và chiều rộng và chiều cao được đặt. Sau đó, bạn có thể tính toán diện tích chính xác.

Nhưng theo LSP, bạn muốn các đối tượng của lớp con của bạn hoạt động giống như các đối tượng của lớp cha của bạn. Có nghĩa là nếu bạn thay thế Hình chữ nhật bằng Hình vuông, mọi thứ vẫn hoạt động tốt:

$square = new Square();
$square->setWidth(10);
$square->setHeight(5);

Bạn sẽ nhận được 100, vì setWidth(10) được cho là đặt cả chiều rộng và chiều cao thành 10. Nhưng vì setHeight(5), giá trị này sẽ trả về 25.

$square = new Square();
$square->setWidth(10);
$square->setHeight(5);
$area = $square->getArea());
echo $area; // 25

Điều này phá vỡ LSP. Đối tượng hình vuông lớp con không thể thay thế đối tượng hình chữ nhật siêu lớp để tính diện tích. Để khắc phục điều này, cần có một lớp chung cho tất cả các hình dạng sẽ chứa tất cả các phương thức chung mà bạn muốn các đối tượng của lớp con của mình có quyền truy cập. Sau đó, đối với các phương thức riêng lẻ, bạn tạo một lớp riêng cho hình chữ nhật và hình vuông

class Shape {
    public function setColor($color)
		{
        $this->color = $color;
    }
    public function getColor()
		{
        return $this->color;
    }
}

class Rectangle extends Shape {
    public function setWidth($width)
		{
        $this->width = $width;
    }
    public function setHeight($height) {
        $this->height = $height;
    }
    public function getArea() {
        return $this->width * $this->height;
    }
}

class Square extends Shape {
    public function setSide($side) {
        $this->side = $side;
    }
    public function getArea() {
        return $this->side * $this->side;
    }
}

Bằng cách này, bạn có thể đặt màu và lấy màu bằng cách sử dụng siêu lớp hoặc lớp con:

// superclass
$shape = new Shape();
$shape->setColor('red');
$color = $shape->getColor());
echo $color; // red

// subclass
$rectangle = new Rectangle();
$rectangle->setColor('green');
$rectangleColor = $rectangle->getColor());
echo $rectangleColor; // green

// subclass
$square = new Square();
$square->setColor('blue');
$squareColor = $square->getColor());
echo $squareColor; // blue

Interface Segregation Principle (ISP)

ISP tuyên bố rằng các lớp không nên bị buộc phải triển khai các giao diện mà chúng không sử dụng. Nguyên tắc này giúp giảm độ phức tạp của mã và giúp bảo trì dễ dàng hơn.

Trong Laravel, nguyên tắc này có thể được áp dụng bằng cách tạo các giao diện nhỏ hơn, tập trung hơn để xác định các nhiệm vụ cụ thể.

Ví dụ: giả sử bạn có một giao diện xác định các phương thức để vẽ các hình dạng cụ thể.

interface ShapeInterface {
    public function calculateArea();
    public function calculateVolume();
}

Khi bất kỳ lớp nào triển khai giao diện này, tất cả các phương thức phải được xác định ngay cả khi bạn không sử dụng chúng hoặc nếu chúng không áp dụng cho lớp đó.

class Square implements ShapeInterface {
    public function calculateArea()
		{
        //...
    }
    public function calculateVolume()
		{
        //...
    }  
}

class Cuboid implements ShapeInterface {
    public function calculateArea()
		{
        //...
    }
    public function calculateVolume()
		{
        //...
    }    
}

class Rectangle implements ShapeInterface {
    public function calculateArea()
		{
        //...
    }
    public function calculateVolume()
		{
        //...
    }   
}

Nhận thấy rằng chúng ta không thể tính thể tích của hình vuông hoặc hình chữ nhật. Vì lớp này triển khai giao diện nên bạn cần xác định tất cả các phương thức, ngay cả những phương thức bạn không sử dụng hoặc không cần.

Thay vào đó, ta nên tách nhỏ interface ra:

interface ShapeInterface {
    public function calculateArea();
}

interface ThreeDimensionalShapeInterface {
    public function calculateArea();
    public function calculateVolume();
}

Bây giờ bạn có thể triển khai giao diện cụ thể hoạt động với từng lớp.

class Square implements ShapeInterface {
    public function calculateArea()
		{
        //...
    } 
}

class Cuboid implements ThreeDimensionalShapeInterface {
    public function calculateArea()
		{
        //...
    }
    public function calculateVolume()
		{
        //...
    }    
}

class Rectangle implements ShapeInterface {
    public function calculateArea()
		{
        //...
    }  
}

Dependency Inversion Principle (DIP)

DIP nêu rõ rằng các mô-đun cấp cao không nên phụ thuộc vào các mô-đun cấp thấp, mà cả hai đều phải phụ thuộc vào sự trừu tượng hóa. Nguyên tắc này giúp giảm sự ghép nối giữa các mô-đun và giúp việc duy trì và mở rộng mã dễ dàng hơn.

Theo Wikipedia, nguyên tắc này nêu rõ rằng:

• Các mô-đun cấp cao không được nhập bất cứ thứ gì từ các mô-đun cấp thấp. Cả hai nên phụ thuộc vào sự trừu tượng (ví dụ: giao diện).
• Sự trừu tượng phải độc lập với các chi tiết. Chi tiết (triển khai cụ thể) sẽ phụ thuộc vào sự trừu tượng.

Trong Laravel, nguyên tắc này có thể được áp dụng bằng cách sử dụng dependency injection. Bằng cách xác định các phần phụ thuộc dưới dạng trừu tượng thay vì triển khai cụ thể, có thể thay đổi cách triển khai phần phụ thuộc mà không ảnh hưởng đến mã phụ thuộc vào nó.

Thay vì ta triển khai cụ thể:

class UserController {
  public function showProfile(int|string $id) {
    $userRepository = new UserRepository;
    $user = $userRepository->getUser($id);

    return view('user.profile', ['user' => $user]);
  }
}

Thì ta có thể xác định phần phụ thuộc dưới dạng trừu tượng:

class UserController {
  protected $userRepository;

  public function __construct(UserRepositoryInterface $userRepository) {
    $this->userRepository = $userRepository;
  }

  public function showProfile(int|string $id) {
    $user = $this->userRepository->getUser($id);

    return view('user.profile', ['user' => $user]);
  }
}

Advantages of SOLID

Sử dụng các nguyên tắc SOLID trong phát triển phần mềm có một số lợi ích:

• Tăng khả năng bảo trì: Các nguyên tắc SOLID giúp tạo mã dễ bảo trì và sửa đổi hơn theo thời gian. Khi mỗi lớp hoặc mô-đun có một trách nhiệm duy nhất và tuân theo Nguyên tắc Mở/Đóng, các thay đổi có thể được thực hiện mà không ảnh hưởng đến các phần khác của mã.
• Tăng khả năng kiểm tra: Nguyên tắc SOLID cũng giúp kiểm tra mã dễ dàng hơn. Mã tuân theo Nguyên tắc trách nhiệm duy nhất thường dễ kiểm tra hơn vì có ít sự phụ thuộc hơn và ít tác dụng phụ có thể xảy ra hơn.
• Tăng tính linh hoạt: Bằng cách tuân thủ Nguyên tắc Mở/Đóng, bạn có thể tạo mã linh hoạt và có khả năng mở rộng hơn. Khi cần thêm chức năng mới, bạn có thể làm như vậy bằng cách thêm các lớp hoặc giao diện mới thay vì sửa đổi mã hiện có.
• Tổ chức mã tốt hơn: Bằng cách tuân theo các nguyên tắc SOLID, bạn có thể tổ chức mã của mình tốt hơn và làm cho các nhà phát triển khác dễ hiểu hơn. Mã được tổ chức tốt và tuân theo các mẫu thiết kế rõ ràng sẽ dễ bảo trì và mở rộng hơn.

Conclusion

SOLID là một tập hợp các nguyên tắc thiết kế giúp thúc đẩy các phương pháp thiết kế tốt và đảm bảo rằng mã có thể mở rộng, bảo trì và dễ hiểu. Bằng cách áp dụng những nguyên tắc này trong Laravel, các nhà phát triển có thể tạo mã mạnh mẽ, có thể bảo trì và dễ mở rộng quy mô.

Cảm ơn mọi người đã dành thời gian để đọc 🙏

The post SOLID Principles appeared first on Tomoshare.

Việc lưu trữ và quản lý file trên đám mây đã trở thành một phần quan trọng trong quá trình phát triển ứng dụng. Việc upload nhiều files đồng thời không chỉ giúp tiết kiệm thời gian mà còn tối ưu hiệu suất, đặc biệt quan trọng đối với các ứng dụng yêu cầu xử lý lượng lớn dữ liệu.

Giả sử chúng ta có 1000 files cần upload lên S3 Storage.

Thông thường, chúng ta sẽ làm như sau:

foreach ($uploadFiles as $uploadFile) {
    $response = $this->s3StorageClient->putObject([
        'Bucket'       => ****,
        'Key'          => $uploadFile['filename'],
        'SourceFile'   => $uploadFile['content'],
        'ACL'          => 'public-read'
//        ....
   ]);
}

Theo cách trên, nếu chúng ta upload 10 files thì sẽ mất 10 lần để xử lý putObject, nếu upload 1000 files thì sẽ lần lượt xử lý putObject 1000 lần.

Để giải quyết việc này, AWS PHP SDK có cung cấp một class CommandPool, class này có thể thực thi nhiều lệnh AWS cùng lúc.

$commands = [];
foreach ($uploadFiles as $uploadFile) {
    $commands[] = $this->s3StorageClient->getCommand('PutObject', [
        'Bucket'       => ****,
        'Key'          => $uploadFile['filename'],
        'SourceFile'   => $uploadFile['content'],
        'ACL'          => 'public-read'
    ]);
}

Đầu tiên, không thực thi lệnh putObject trong vòng lặp mà hãy sử dụng getCommand để tạo lệnh cho putObject và lưu trữ nó trong một mảng.

Sau đó, bạn có thể dễ dàng thực thi các lệnh đồng thời bằng cách đưa s3 instance và mảng commands được vào phương thức CommandPool::batch.

CommandPool::batch($this->s3StorageClient, $commands);

Ở đây chúng ta có thể lấy files đồng thời sau khi gọi hàm CommandPool::batch

$responses = CommandPool::batch($this->s3StorageClient, $commands);

foreach ($responses as $response) {
  // code here
}

Em cũng đã triển khai cách trên áp dụng vào dự án và cũng khá hiệu quả về performance.

Đối với những bài toán upload số lượng files lên đến hàng trăm nghìn, hàng triệu, chúng ta có thể zip từng nhóm files rồi thực hiện upload đồng thời theo cách trên, nhưng cần sử dụng thêm một service để giải nén file zip sau khi upload (AWS Lambda chẳng hạn).

Tài liệu tham khảo:

• https://docs.aws.amazon.com/sdk-for-php/v3/developer-guide/guide_commands.html#command-pool
• https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.CommandPool.html

The post [AWS SDK for PHP] Xử lý upload multiple files đồng thời lên S3 Storage hiệu quả appeared first on Tomoshare.

Alpine.js là một JavaScript framework nhẹ và dễ sử dụng, giúp bạn tạo ra các tương tác trực tiếp trên giao diện người dùng (UI) một cách dễ dàng và nhanh chóng mà không cần phải chạy npm, biên dịch tập lệnh, định cấu hình webpack. Nó là một giải pháp thay thế đơn giản và hiệu quả cho các frontend framework khác như Vue, React & Angular. Hãy nghĩ về nó giống như Tailwind dành cho JavaScript.

Cách sử dụng

Theo  tài liệu của Alpine.js , cú pháp của nó gần như được mượn hoàn toàn từ  Vue.js  (và phần mở rộng  Angular.js ), vì vậy nếu bạn đã biết một trong hai framework này thì bạn sẽ không phải mất nhiều thời gian để bắt đầu.

Trong blog này, Chúng ta sẽ tìm hiểu cách sử dụng Alpine.js trong Laravel với hai ví dụ.

1. Alpine.js CDN
2. Laravel Mix

Sử dụng qua CDN

Bạn chỉ cần thêm một thẻ script liên kết thư viện (xem ví dụ bên dưới). Rất đơn giản phải không nào! Bạn không cần phải biên dịch javascript hoặc cấu trúc dự án của mình theo bất kỳ cách cụ thể nào.

<html>
<head>
    <script defer src="https://cdn.jsdelivr.net/npm/alpinejs@3.x.x/dist/cdn.min.js"></script>
</head>
<body>
    <h1 x-data="{ message: 'I ❤️ Alpine' }" x-text="message"></h1>
</body>
</html>

Sử dụng qua Laravel mix

Trước tiên, bạn cần cài đặt Alpine js bằng lệnh npm bên dưới:

npm install alpinejs

Tiếp đó, bạn cần import vào resources/js/app.js file

import 'alpinejs';

Cuối cùng chỉ cần chạy lệnh

npm run dev

Bây giờ, bạn có thể sử dụng được alpine (nhớ thêm app.js vào blade view nhé)

<script src="{{ mix('js/app.js') }}"></script>

Cùng xem 1 ví dụ đơn giản nhé:

<div 
    x-data="{ show: false }" 
    x-show="show" 
    x-on:notify.window="() => { show = true; setTimeout(() => { show = false; }, 5000 ) }"
    style="display:none;"
    class="toast active"
>
    <div class="toast-content">
        <i class="ti ti-check toast-icon" x-on:click="show = false"></i>
        <div class="message">
            <span class="message-title">Ví dụ</span>
            <span class="message-content">Ví dụ về alpine js</span>
            <span x-on:click="show = false" class="close">
                <i class="ti ti-x"></i>
            </span>
        </div>
        <div class="progress active"></div>
    </div>
</div>

Ở ví dụ trên, tôi có một component alert được phản ứng khi sự kiện notify được thực hiện thì sẽ hiển thị thông báo.

Kết luận

Với sự đơn giản và gọn nhẹ của Alpine, tôi tin rằng đây sẽ là 1 trong số các giải pháp tốt nhất cho bạn trong một số trường hợp thay vì sử dụng các Js framework khác như Vue hay React để rồi nhận thêm sự cồng kềnh, phức tạp mà chúng mang lại.

Hiện tại, cùng với sự kết hợp với Tailwind, Livewire và Laravel, bộ tứ này đã và đang hình thành nên 1 ngăn xếp công nghệ mới được gọi là ngăn xếp TALL. Nếu tò mò bạn có thể xem tại blog.laravelvietnam.

The post Alpine.js là gì ? Hãy Cùng tìm hiểu về cách sử dụng nào appeared first on Tomoshare.

Mermaid là một thư viện JavaScript cho phép bạn tạo các biểu đồ cực kì dễ dàng, bằng cú pháp đơn giản dựa trên Markdown. Nó hỗ trợ hầu hết các loại biểu đồ: biểu đồ trình tự, biểu đồ lớp, biểu đồ trạng thái, ERD… Các biểu đồ được tạo bằng cách khai báo mã và văn bản, sau đó được xuất thành biểu đồ, có thể dễ dàng tích hợp biểu đồ vào Github.

Sequence diagrams

Giờ chúng ta sẽ vẽ thử 1 sequence diagram với mermaid.

sequenceDiagram
    Alice->>John: Hello John, how are you?
    John-->>Alice: Great!
    Alice-)John: See you later!

Chỉ cần khai báo như trên mermaid sẽ tự generate ra một biểu đồ luồng

Class diagrams

Vẽ thử một class diagram

classDiagram
class BankAccount{
    +String owner
    +BigDecimal balance
    +deposit(amount)
    +withdrawal(amount)
}

Output chúng ta nhận được

Entity Relationship Diagram

Vẽ một biểu đồ ERD đơn giản, chúng ta có thể khai báo được các trường, kiểu dữ liệu, quan hệ giữa các bảng cực kì đơn giản.

erDiagram
    CUSTOMER ||--o{ ORDER : places
    CUSTOMER {
        string name
        string custNumber
        string sector
    }
    ORDER {
        int orderNumber
        string deliveryAddress
    }

Output chúng ta nhận được

State diagram​

Vẽ biểu đồ trạng thái

stateDiagram-v2
    [*] --> Still
    Still --> [*]

    Still --> Moving
    Moving --> Still
    Moving --> Crash
    Crash --> [*]

Output nhận được

Chúng ta đã tìm hiểu xong 4 loại biểu đồ hay dùng nhất với dev. Ngoài ra Mermaid cũng support rất nhiều loại biểu đồ khác mọi người có thể vào mermaid document để tìm hiểu thêm. Document của họ viết rất rõ ràng và có demo cụ thể hết rồi.

Tổng kết

Mermaid sẽ giúp chúng ta định nghĩa các biểu đồ cho dự án cực kì dễ ràng, quản lý và hiển thị được các biểu đồ trên github. Nó là công cụ cực kì hữu ích giúp định nghĩa các thiết kế cho dự án. Thanks for reading…

The post Vẽ biểu đồ với Mermaid appeared first on Tomoshare.

1. Increments và Decrements

Khi muốn update tăng 1 đơn vị cho 1 column thay vì viết như này.

$post = Post::find($postId);
$post->view_count++;
$post->save();

Bạn có thể viết lại như này

$post = Post::find($postId);
$post->increment('view_count');

Hoặc

Post::find($postId)->increment('view_count');
Post::find($postId)->increment('view_count', 10); // +10
Product::find($productId)->decrement('stock'); // -1

2. XorY methods

Laravel Eloquent có khả nhiều function kết hợp 2 methods kiểu như “hãy làm X trước nếu không thì làm Y”

• findOrFail

$user = User::find($id);
if (!$user) {
   abort(404);
}

↓

$user = User::findOrFail($id);

• firstOrCreate

$user = User::where('email', $email)->first();
  if (!$user) {
  User::create([
  'email' => $email
  ]);
}

↓

$user = User::firstOrCreate(['email' => $email]);

3. Model boot() method

Trong Laravel Eloquent có một function boot() cho phép bạn ghi đè lại các giá trị mặc định.

class User extends Model
{
    /**
    * @return void
    */
    public static function boot(): void
    {
        parent::boot();
        static::updating(function($model)
        {
            // do some logging
            // thay thế một số property, ví dụ $model->something = transform($something);
        });
    }
}

Ứng dụng nhiều nhất của function này là set uuid cho đối tượng

/**
* @return void
*/
public static function boot(): void
{
    parent::boot();
    self::creating(function ($model) {
        $model->uuid = (string)Uuid::generate();
    });
}

4. Thêm điều kiện hoặc ordering trong relationship

Dưới đây là một cách mà các bạn thường dùng để định nghĩa một relationship

/**
* @return mixed
*/
public function users()
{
    return $this->hasMany('App\User');    
}

Tuy nhiên bạn hoàn toàn có thể thêm where hoặc orderBy

Ví dụ trong trường hợp cụ thể, bạn cần tạo quan hệ giữa bảng categories và posts nhưng thêm điều kiện là post phải có trạng thái là APPROVED và sắp xếp theo thứ tụ tăng dần.

/**
* @return mixed
*/
public function posts() 
{
    return $this->hasMany('App\Models\Category')->where('status', 'APPROVED')->orderBy('id', 'DESC');
}

5. Model properties: timestamps, appends, …

Có một vài parameters của Eloquent Model, được thể hiện dưới dạng properties của class đó. Một số cái phổ biến nhất có thể là:

class User extends Model {
    protected $table = 'users';
    protected $fillable = ['email', 'password']; // Những fileds có thể được set giá trị bằng cách dùng User::create()
    protected $dates = ['created_at', 'deleted_at']; // Những fields sẽ được set bởi Carbon-ized
    protected $appends = ['field1', 'field2']; // Các giá trị bổ sung được trả về trong JSON 
}

Khoannnnnnnnnnnnnnnnnnn, Còn nữa…

protected $primaryKey = 'uuid'; // Primary key k phải lúc nào cũng bắt buộc phải là id
public $incrementing = false; // và thậm chí k cần phải tự động tăng luông 
protected $perPage = 25; // Bạn có thể override số lượng data trong 1 page khi sủ dụng pagination, giá trị này default là 15
const CREATED_AT = 'created_at';
const UPDATED_AT = 'updated_at'; // Thay đổi được tên column created_at và updated_at luôn nè 
public $timestamps = false; // Hoặc khai báo là k cần sủ dụng chúng
protected $dateFormat = 'U'; //Hoặc bạn có thể thay đổi kiểu dữ liệu của chúng. Ví dụ chuyển created_at và updated_at sang integer thì làm như ví dụ này.

Và tất nhiên là còn nhiều hơn nữa, trên đây mình đã liệt kê những cái thú vị nhất, để biết thêm chi tiết, vui lòng kiểm tra ở abstract Model Class

To be continued…

The post 20 Laravel Eloquent Tips and Tricks (P1) appeared first on Tomoshare.

Mới đây, vào ngày 14 tháng 2 năm 2023, phiên bản Laravel 10 chính thức được phát hành. Chúng ta hãy cùng nhau tìm hiểu xem phiên bản này có những thay đổi và cập nhật gì so với những phiên bản trước nhé.

Native Type Declarations

Trước version 10: sử dụng DocBlocks để làm rõ chức năng của một function và loại parameters hoặc response mong đợi.

    /**
    * Determine whether the user can create models.
    *
    * @param User $user
    * @return IlluminateAuthAccessResponse|bool
    */
    public function create(User $user)
    {
      //
    }

Version 10:

    /**
     * Store a newly created resource in storage.
     */
    public function store(Request $request): View
    {
        return view('');
    }

Để đảm bảo được sự tương thích ngược của framework (breaking changes), các thuộc tính sẽ được áp dụng cho:

• Dữ liệu trả về (return types)
• Tham số của phương thức (method arguments)
• Loại bỏ một số khai báo types không còn cần thiết ở docblock
• Cho phép có thể khai báo ngay trong các tham số của closure

Hỗ trợ sửa cột cho CSDL

Nhằm loại bỏ dần nhu cầu sử dụng package doctrine/dbal, một tính năng mới đã được giới thiệu trong Laravel 10 cho phép các nhà phát triển sử dụng phương thức change() để sửa đổi các cột mà không cần các gói bổ sung.

Sử dụng phương thức change() để chỉnh sửa cột.

Ví dụ: Để sửa kiểu dữ liệu từ integer -> bigInt ta làm như sau

# before
$table->integer('user_balance')->unsigned()->default(0)->comment('balance');

# after
$table->bigInteger('user_balance')->unsigned()->default(0)->comment('balance')->change();

Note:

• Cần thêm tất cả thuộc tính của cột khi thay đổi nếu không chúng sẽ bị loại bỏ.
• Nếu đã cài đặt doctrine/dbal, nên khai báo phương thức Schema::useNativeSchemaOperationsIfPossible() trong App/Providers/AppServiceProvider để sử dụng tính năng này. Laravel sẽ ưu tiên nó trước khi sử dụng đến package và không hỗ trợ cho SQLite.

use IlluminateSupportFacadesSchema;
class AppServiceProvider extends ServiceProvider
{
  public function boot()
  {
    Schema::useNativeSchemaOperationsIfPossible();
  }
}

Process Interaction

Process Interaction giúp việc thử nghiệm và chạy các quy trình CLI trở nên dễ dàng.

use IlluminateSupportFacadesProcess;
$result = Process::run('ls -la');
$result->successful();
$result->failed();
$result->exitCode();
$result->output();
$result->errorOutput();
$result->throw();
$result->throwIf(condition);

Process Interaction giúp chúng ta:

• Xử lý đầu ra của process khi nhận được
• Thiết lập Process không đồng bộ
• Tạo ra nhóm các process
• Các tính năng testing phong phú thông qua fake()
• Ngăn chặn ngoại lệ trong quá trình testing

Process là một tính năng mới rất được đầu tư với nhiều phương thức và option được cung cấp. Bạn có thể tìm hiểu chi tiết ở docs về phần này của Laravel

Cung cấp 1 package mới – Laravel Pennant

Laravel Pennant cung cấp một cách tiếp cận gọn nhẹ, được sắp xếp hợp lý để quản lý các cờ tính năng của ứng dụng của bạn.

Nó cho phép chúng ra tự tin triển khai dần dần các tính năng ứng dụng mới, thử nghiệm các thiết kế giao diện mới.

Bạn có thể tìm hiểu chi tiết nó trong docs của Laravel 10.

The post Những cập nhật trong Laravel 10 appeared first on Tomoshare.