Tối ưu Slow Query PostgreSQL: Khi một dòng code cứu cả hệ thống

Bối cảnh

Trong một dự án e-commerce gần đây, tôi gặp một bài toán rất quen thuộc:
trên trang chi tiết đơn hàng, cần có nút:

• “Đơn tiếp theo” (Next)
• “Đơn trước đó” (Previous)

Yêu cầu tưởng đơn giản, nhưng có một constraint quan trọng:
không được load toàn bộ danh sách lên RAM.

Giải pháp hiển nhiên là dùng Keyset Pagination (cursor-based), thay vì offset pagination.

Cách triển khai ban đầu

Dữ liệu được sort theo:

• paid_at (thời điểm thanh toán)
• id (để break tie)

Code Laravel Eloquent ban đầu của tôi cho “Next Order” trông như sau:

->where(function (Builder $q) use ($order) {
    $q->where('paid_at', '>', $order->paid_at)
        ->orWhere(function (Builder $q1) use ($order) {
            $q1->where('paid_at', $order->paid_at)
                ->where('id', '>', $order->id);
        });
})
->orderBy('paid_at')
->orderBy('id')

Nếu đọc bằng “tiếng người”, logic này hoàn toàn đúng:

Lấy các đơn có paid_at lớn hơn,
hoặc nếu cùng thời điểm thì id phải lớn hơn.

Vấn đề thực tế xảy ra

Khi dữ liệu tăng lên vài triệu bản ghi, hệ thống bắt đầu:

• xuất hiện slow query
• query plan chuyển sang:
  • Bitmap Heap Scan
  • hoặc tệ hơn là Seq Scan

Trong khi đó, database đã có composite index:

(paid_at, id)

=> Về lý thuyết phải chạy rất nhanh.

Nguyên nhân cốt lõi

Thủ phạm nằm ở mệnh đề OR.

PostgreSQL Query Planner khi gặp OR thường:

• tách điều kiện thành nhiều nhánh
• không tận dụng được composite index một cách hiệu quả
• dẫn tới scan nhiều hơn cần thiết

Nói đơn giản:
Index có, nhưng không được dùng đúng cách.

Cách giải quyết (và là điểm “aha moment”)

Thay vì viết điều kiện dạng boolean phức tạp,
ta sử dụng Tuple Comparison (Row Value Syntax) của PostgreSQL.

Thay đổi duy nhất:

->whereRaw('(paid_at, id) > (?, ?)', [$order->paid_at, $order->id])

Với “Previous”:

->whereRaw('(paid_at, id) < (?, ?)', [$order->paid_at, $order->id])

Vì sao cách này hiệu quả?

Composite index (paid_at, id) trong PostgreSQL được sắp xếp theo kiểu:

từ điển (lexicographical order)

Tức là:

1. So sánh paid_at
2. Nếu bằng nhau → so sánh id

Khi bạn viết:

(paid_at, id) > (x, y)

PostgreSQL có thể:

• map trực tiếp vào B-Tree index
• nhảy đúng vị trí (x, y)
• thực hiện Index Scan tuyến tính

=> Không cần phân nhánh logic như OR nữa.

Kết quả

Sau khi thay đổi:

• Query Plan chuyển thành Index Scan
• Slow query biến mất
• Thời gian response ổn định lại

Ngoài ra còn một lợi ích “không ngờ”:

Code gọn hơn rất nhiều

Từ:

• nhiều closure lồng nhau
• logic khó đọc

=> còn:

->whereRaw('(paid_at, id) > (?, ?)', [...])

Bài học rút ra

1. Tránh OR khi làm keyset pagination

Đặc biệt khi:

• sort theo nhiều cột
• đã có composite index

2. Hiểu cách database tổ chức index quan trọng hơn ORM

ORM giúp code “đẹp”, nhưng:

không đảm bảo query tối ưu

Đôi khi, quay về RAW SQL đúng chỗ lại là lựa chọn tốt hơn.

3. Tận dụng Tuple Comparison trong PostgreSQL

Đây là một feature rất mạnh nhưng ít được dùng:

(col1, col2) > (val1, val2)

Rất phù hợp cho:

• keyset pagination
• multi-column sorting

Kết luận

Một thay đổi nhỏ:

• bỏ OR
• dùng tuple comparison

=> có thể:

• giảm load database
• tránh slow query
• đơn giản hoá code

Đây là một ví dụ điển hình cho việc:

tối ưu performance không phải lúc nào cũng cần rewrite lớn — đôi khi chỉ cần hiểu đúng cách database hoạt động.

The post Tối ưu Slow Query PostgreSQL: Khi một dòng code cứu cả hệ thống appeared first on Tomoshare.

Một hướng dẫn thực tế dành cho các dự án Laravel + Inertia.js + Vue 3 chạy trong Docker với Nginx, tập trung vào SEO kỹ thuật (technical SEO) và hiệu năng.

1. Tổng quan kiến trúc

Một stack phổ biến hiện nay:

• Backend: Laravel
• Frontend: Vue 3 thông qua Inertia.js (SPA-like)
• Web server: Nginx
• Môi trường: Docker / Docker Compose

Vấn đề lớn nhất với SEO trong mô hình này:

• Nội dung render phía client (CSR)
• Bot Google có thể crawl được JS nhưng chậm và không ổn định
• Thiếu metadata động
• TTFB cao nếu cấu hình Docker/Nginx chưa tối ưu

Mục tiêu:

Làm cho website crawl được – index đúng – load nhanh – metadata đầy đủ.

2. Hiểu đúng về SEO với Inertia.js

Inertia.js không phải SPA thuần, mà là:

• Server vẫn trả HTML gốc
• Vue render phía client

Tuy nhiên:

• Nội dung chính vẫn xuất hiện sau khi JS chạy
• SEO chấp nhận được, nhưng chưa tối ưu nếu không cấu hình thêm

3. Thiết lập metadata động (cực kỳ quan trọng)

3.1 Dùng Head API của Inertia

import { Head } from '@inertiajs/vue3';

<template>
  <Head>
    <title>{{ title }}</title>
    <meta name="description" :content="description" />
    <meta property="og:title" :content="title" />
    <meta property="og:description" :content="description" />
  </Head>
</template>

3.2 Truyền dữ liệu từ Laravel Controller

return Inertia::render('Post/Show', [
    'title' => $post->title,
    'description' => Str::limit($post->content, 160),
]);

4. Render HTML ban đầu đầy đủ hơn (Preload data)

Kích hoạt SSR (Server Side Rendering) cho Inertia

Đây là bước giúp SEO nhảy vọt.

Cài SSR (tham khảo chi tiết ở phần 1)

npm install @inertiajs/server

php artisan inertia:start-ssr

Laravel sẽ:

• Render HTML phía server
• Bot Google thấy ngay nội dung

Lợi ích

5. Cấu hình Nginx chuẩn SEO + hiệu năng

5.1 Bật gzip / brotli

gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

5.2 Cache static files

location ~* \.(js|css|png|jpg|jpeg|gif|svg|webp)$ {
    expires 30d;
    access_log off;
}

5.3 HTTP Headers SEO

add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options SAMEORIGIN;
add_header X-XSS-Protection "1; mode=block";

6. Docker tối ưu cho SEO (TTFB thấp)

6.1 Sử dụng PHP-FPM production

FROM php:8.2-fpm-alpine

6.2 OPcache

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000

6.3 Docker Compose network nội bộ

Tránh expose không cần thiết, giảm latency.

7. Sitemap & robots.txt tự động trong Laravel

7.1 Cài package

composer require spatie/laravel-sitemap

7.2 Tạo sitemap

SitemapGenerator::create(config('app.url'))
    ->writeToFile(public_path('sitemap.xml'));

7.3 robots.txt

User-agent: *
Allow: /
Sitemap: https://domain.com/sitemap.xml

8. Schema.org (Rich snippets)

Thêm JSON-LD trong Inertia Head:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "{{ title }}"
}
</script>

9. Kiểm tra SEO

Công cụ nên dùng

• Google Search Console
• PageSpeed Insights
• Lighthouse
• Screaming Frog

KPI nên theo dõi

• LCP < 2.5s
• CLS < 0.1
• TTFB < 500ms
• Index coverage

10. Checklist nhanh

✅ Inertia Head metadata

✅ SSR enabled

✅ Gzip + cache static

✅ Sitemap.xml

✅ robots.txt

✅ JSON-LD

✅ Docker optimized

✅ OPcache

11. Kết luận

Laravel + Inertia.js + Vue 3 hoàn toàn SEO tốt nếu:

• Có SSR
• Metadata đúng
• Server nhanh
• Cấu hình Nginx & Docker chuẩn

SEO không chỉ là content – mà là kiến trúc hệ thống.

Nếu bạn đang chạy dự án Laravel Inertia trên Docker và muốn audit SEO chuyên sâu (TTFB, crawlability, SSR setup), bạn có thể mở rộng thêm:

• Redis cache
• Full page cache cho bot
• Edge caching (Cloudflare)
• Prerender.io cho bot

Chúc bạn tối ưu SEO thành công

The post Tối ưu SEO cho Laravel Inertia.js với Vue 3 + Docker + Nginx (Phần 2) appeared first on Tomoshare.

Trong thế giới thực, điều này thật nực cười. Nhưng trong thế giới lập trình Web và API, tình huống này xảy ra thường xuyên đến mức nó trở thành “cơn đau đầu” kinh niên của giới bảo mật. Nó được gọi là IDOR (Insecure Direct Object Reference) hay BOLA (Broken Object Level Authorization).

Nếu bạn là một Backend Developer, và bạn tin rằng chỉ cần có Authentication (Đăng nhập) là hệ thống đã an toàn, thì bài viết này sẽ thay đổi tư duy lập trình của bạn. Chúng ta sẽ không chỉ nói về bề nổi, mà sẽ đi sâu vào bản chất kiến trúc của lỗi này.

1. Bản chất kỹ thuật của IDOR

IDOR (Insecure Direct Object Reference) không chỉ là một lỗi code, nó là một lỗi về thiết kế Logic (Business Logic Flaw).

Trong danh sách OWASP API Security Top 10, IDOR chính là bản chất của lỗ hổng số 1: API1: 2023 Broken Object Level Authorization (BOLA).

Hiểu sâu hơn, IDOR xảy ra khi 3 điều kiện sau hội tụ:

1. Direct Reference: Ứng dụng để lộ mã định danh nội bộ (Internal Identifier) của đối tượng (như Database Primary Key, Filename) trực tiếp ra ngoài URL hoặc Body request.
2. User Input: Ứng dụng tin tưởng và sử dụng trực tiếp đầu vào này để truy vấn dữ liệu.
3. Missing Authorization: Ứng dụng bỏ qua bước kiểm tra quyền truy cập tại thời điểm truy xuất đối tượng.

Sai lầm phổ biến: Nhiều Dev nhầm lẫn giữa Authentication (Bạn là ai?) và Authorization (Bạn được làm gì?). IDOR xảy ra khi bạn đã qua cửa Authentication, nhưng hệ thống quên kiểm tra Authorization ở mức độ đối tượng (Object-level).

2. Giải phẫu cơ chế tấn công

Hãy mổ xẻ một HTTP Request để thấy IDOR có thể lẩn trốn ở đâu. Không chỉ ở URL Parameter, nó có thể nằm ở Header hoặc Body.

Kịch bản: Ứng dụng Chat cho phép người dùng tải lại lịch sử chat.

Request bình thường:

GET /api/v1/messages/history HTTP/1.1
Host: example.com
Cookie: session_id=abc123xyz...
X-User-ID: 1005  <-- IDOR tiềm ẩn ở Header

1. Hacker quan sát: Thấy Header X-User-ID: 1005 được gửi kèm mỗi request.
2. Thử nghiệm: Hacker dùng Postman hoặc Burp Suite để chặn request, sửa X-User-ID thành 1006.
3. Kết quả: Server, thay vì lấy ID từ session an toàn (Server-side), lại tin tưởng lấy ID từ Header (Client-side) để query database SELECT * FROM messages WHERE user_id = 1006.
4. Hậu quả: Hacker đọc được toàn bộ tin nhắn của người dùng 1006.

IDOR có thể xuất hiện ở:

• URL Path: /users/100/profile
• Query Params: /invoices?id=100
• Body (JSON/XML): POST /api/change-password với body {"user_id": 100, "new_pass": "..."}

3. Tại sao IDOR lại là “Sát thủ thầm lặng”?

IDOR nguy hiểm vì tính “hợp lệ” về mặt cú pháp của nó.

• Vượt mặt WAF (Web Application Firewall): Các tường lửa thường chặn các ký tự lạ như ' OR 1=1 -- (SQL Injection) hay <script> (XSS). Nhưng với IDOR, payload chỉ là một con số: id=1006. Đối với WAF, đây là một con số hoàn toàn sạch và hợp lệ.
• Khó phát hiện bằng Automation Tool: Các máy quét (Scanner) không hiểu ngữ cảnh nghiệp vụ. Nếu máy quét gửi id=1006 và nhận về 200 OK, nó đánh dấu là “Thành công”. Nó không biết rằng dữ liệu trả về đó không thuộc về người đang gửi request. Chỉ có con người (Pentesters) hoặc Unit Test được viết kỹ lưỡng mới phát hiện ra.
• Hệ quả dây chuyền: IDOR thường là bước đệm để leo thang đặc quyền (Privilege Escalation), dẫn đến việc chiếm đoạt toàn bộ hệ thống (Account Takeover).

Sự nguy hiểm của IDOR nằm ở chỗ nó là một lỗ hổng logic, không phải lỗ hổng cú pháp. Các công cụ quét bảo mật tĩnh (SAST) truyền thống thường thất bại trong việc phát hiện IDOR vì chúng không thể hiểu ngữ cảnh “ai sở hữu cái gì” trong một ứng dụng cụ thể. Điều này dẫn đến một nghịch lý: trong khi các lỗ hổng kỹ thuật như SQL Injection đang giảm dần nhờ các framework hiện đại, IDOR vẫn tồn tại dai dẳng và chiếm tỷ lệ cao trong các chương trình săn lỗi nhận thưởng (Bug Bounty), đặc biệt là trong các lĩnh vực y tế, chính phủ và dịch vụ chuyên nghiệp.

4. Phân loại IDOR chuyên sâu.

4.1. Leo thang đặc quyền ngang (Horizontal Escalation)

Đây là dạng phổ biến nhất. Người dùng A truy cập dữ liệu của Người dùng B có cùng vai trò.

• Ví dụ: Xem đơn hàng, tải hóa đơn, xem ảnh riêng tư.
• Rủi ro: Rò rỉ thông tin cá nhân (PII Breach), vi phạm GDPR/CCPA.

4.2. Leo thang đặc quyền dọc (Vertical Escalation)

Người dùng thường (User) tìm cách gọi các API dành riêng cho Quản trị viên (Admin/Manager).

• Ví dụ:
  • Hacker tìm thấy API: POST /api/users/1001/roles.
  • Hacker gửi request với body: {"role": "ADMIN"}.
  • Nếu Backend không check xem “người gọi API này có phải là Super Admin không”, Hacker lập tức trở thành Admin.

4.3. IDOR trên File tĩnh (Static File IDOR)

Tên file thường dễ đoán.

• Ví dụ: https://example.com/uploads/receipts/receipt_001.pdf.
• Hacker viết script lặp từ 001 đến 9999 để tải toàn bộ hóa đơn của hệ thống.

5. Dẫn chứng thực tế: Khi “Ông lớn” cũng mắc sai lầm

5.1. McDonald’s & sự cố McHire (7/2025)

Link: https://research.cgu.edu/icdc/2025/07/01/mcdonalds-july-2025-breach/

Bối cảnh: Hệ thống bị ảnh hưởng là McHire, nền tảng tuyển dụng toàn cầu của McDonald’s, được vận hành bởi đối tác công nghệ bên thứ ba là Paradox.ai. Paradox.ai cung cấp giải pháp chatbot AI tên là “Olivia” để tự động hóa quy trình phỏng vấn, thu thập thông tin ứng viên và lên lịch làm việc. Sự phụ thuộc vào bên thứ ba này đã mở rộng bề mặt tấn công của McDonald’s ra ngoài hạ tầng kiểm soát trực tiếp của họ.   

Nguyên nhân chính
Sự cố xảy ra do kết hợp 2 lỗi nghiêm trọng:

1. Xác thực yếu (Weak Authentication)
   • Một tài khoản admin thử nghiệm của Paradox.ai dùng mật khẩu “123456”, không có MFA.
   • Tài khoản này tồn tại từ 2019, không bị vô hiệu hóa dù có quyền truy cập production.
2. Lỗ hổng IDOR (Missing Object Level Authorization)
   • API backend cho phép truy xuất hồ sơ ứng viên bằng applicant_id.
   • Không kiểm tra quyền truy cập → chỉ cần đổi ID là đọc được dữ liệu của bất kỳ ứng viên nào.
   • Từ 1 tài khoản → mở rộng ra 64 triệu hồ sơ toàn cầu.

Tác động

• Rò rỉ PII: tên, email, số điện thoại, địa chỉ nhà.
• Lộ dữ liệu nhạy cảm: log chat với AI (tính cách, sở thích, thông tin cá nhân).
• Lộ token phiên → có thể giả danh ứng viên.
• Nguy cơ cao cho social engineering, lừa đảo, chiếm tài khoản.

Sự kết hợp giữa quản lý tài khoản kém (tài khoản ma, không MFA) và thiếu kiểm soát quyền API (IDOR) tạo ra “cơn bão hoàn hảo” cho rò rỉ dữ liệu quy mô toàn cầu – một xu hướng cực kỳ đáng báo động trong năm 2025

5.2. Mozilla Firefox Accounts – Lỗ hổng xóa tài khoản (5/2025)

Link: https://hackerone.com/reports/3154983

Bản chất sự cố

• Lỗ hổng IDOR nghiêm trọng trong API xóa tài khoản (/v1/account/destroy).
• Cho phép xóa vĩnh viễn tài khoản người khác mà không cần tương tác từ nạn nhân (zero-click).
• Ảnh hưởng trực tiếp đến Integrity (toàn vẹn) và Availability (sẵn sàng) của dữ liệu.

Nguyên nhân kỹ thuật

• Lỗi Session Misbinding: backend không kiểm tra phiên làm việc có khớp với tài khoản bị xóa hay không.
• API tin vào payload JSON (email, authPW) thay vì session của người gửi request.
• Đây là dạng IDOR ghi/xóa, nguy hiểm hơn IDOR đọc dữ liệu.

Kịch bản khai thác

1. Kẻ tấn công tạo tài khoản Firefox, đăng nhập bằng SSO (Google).
2. Chặn request xóa tài khoản của chính mình.
3. Đổi email trong payload thành email nạn nhân (cũng dùng SSO, chưa set mật khẩu).
4. Gửi request → hệ thống xóa tài khoản nạn nhân.

Tác động

• Mất vĩnh viễn dữ liệu: mật khẩu đã lưu, lịch sử duyệt web, tab, sync data.
• Không thể khôi phục, không cần nạn nhân click hay xác nhận.
• Được đánh giá Critical trên HackerOne.

Bài học cốt lõi: IDOR không chỉ gây rò rỉ dữ liệu (read) mà còn có thể phá hủy dữ liệu (write/delete) nếu backend không ràng buộc chặt chẽ giữa session và đối tượng tài nguyên.

5.3. GitLab – Lỗ hổng Machine Learning Model Registry (2024–2025)

Link: https://hackerone.com/reports/2528293

Bối cảnh

• GitLab triển khai Machine Learning Model Registry để quản lý phiên bản mô hình AI.
• Lỗ hổng được báo cáo từ 5/2024, vá và công bố kéo dài sang 2025, cho thấy độ phức tạp của bảo mật trên nền tảng lớn.
• Sự cố ảnh hưởng trực tiếp đến tài sản trí tuệ AI (model weights, biases).

Nguyên nhân kỹ thuật

• GitLab dùng ID tịnh tiến (1,2,3,…) cho model_id thay vì UUID ngẫu nhiên.
• API tải/xem mô hình không kiểm tra quyền truy cập dự án (Missing Object Level Authorization).
• Đây là IDOR điển hình + thiết kế API kém an toàn.

Cách khai thác

• Kẻ tấn công chỉ cần tài khoản GitLab miễn phí.
• Lặp ID từ 1 → hàng triệu để liệt kê và tải mô hình của dự án khác.
• Không cần brute-force, không cần quyền dự án.

Tác động

• Rò rỉ mô hình ML độc quyền của doanh nghiệp.
• Nguy cơ mất bí mật thương mại, thiệt hại kinh tế lớn trong bối cảnh AI là tài sản cốt lõi.
• Lỗ hổng có thể bị khai thác tự động, quy mô lớn (enumeration).

Bài học cốt lõi: Không dùng ID tịnh tiến cho API công khai. Nó biến IDOR từ lỗ hổng tiềm ẩn thành thảm họa có thể khai thác hàng loạt, đặc biệt nguy hiểm với tài sản AI.

6. Ngăn chặn IDOR hiệu quả (Best Practices)

Khi một tài khoản test có thể mở khóa 64 triệu hồ sơ, một email có thể xóa tài khoản người khác, và một con số tăng dần có thể làm bay cả mô hình AI, thì rõ ràng vấn đề không nằm ở “hacker quá giỏi” — mà ở chỗ chúng ta cần chặn IDOR cho đúng cách.

“Đừng bao giờ tin tưởng Client”. Dưới đây là chiến lược phòng thủ đa lớp (Defense in Depth).

Lớp 1: Kiểm soát truy cập tại tầng Data (Data-Layer Authorization)

Đây là chốt chặn cuối cùng và quan trọng nhất. Mọi câu lệnh truy vấn liên quan đến dữ liệu người dùng phải kèm theo điều kiện về chủ sở hữu.

❌ Code rủi ro (Spring Data JPA):

// Controller
public Order getOrder(@PathVariable Long id) {
    return orderRepo.findById(id); // Chỉ tìm theo ID đơn hàng
}

✅ Code an toàn (Repository Pattern):

// Repository
// Luôn gắn kèm userId vào câu query
@Query("SELECT o FROM Order o WHERE o.id = :id AND o.owner.id = :currentUserId")
Optional<Order> findByIdAndOwner(@Param("id") Long id, @Param("currentUserId") Long userId);

// Service Layer
public Order getOrder(Long id, User currentUser) {
    return orderRepo.findByIdAndOwner(id, currentUser.getId())
        .orElseThrow(() -> new ResourceNotFoundException("Order not found or access denied"));
}

Lớp 2: Kiểm soát truy cập tại tầng Controller (Method-Level Security)

Sử dụng các Annotation bảo mật của Framework (như Spring Security) để chặn ngay từ cửa vào.

✅ Ví dụ với Spring Security (@PreAuthorize):

@GetMapping("/invoices/{id}")
// SpEL: Chỉ cho phép nếu user hiện tại là chủ sở hữu của invoice có id này
@PreAuthorize("@securityService.isOwner(authentication, #id)") 
public Invoice getInvoice(@PathVariable Long id) {
    return invoiceRepo.findById(id);
}

Cách này giúp code business logic sạch hơn, tách biệt logic bảo mật ra khỏi logic nghiệp vụ.

Lớp 3: Làm khó Hacker bằng UUID (Obfuscation)

Thay vì dùng Auto-Increment Integer (1, 2, 3), hãy dùng UUID (Random String: a0eebc99-9c0b...) hoặc các thuật toán băm ID (như Hashids).

• Lợi ích: Chặn đứng tấn công kiểu liệt kê (Enumeration Attack). Hacker không thể viết vòng lặp for (i=0; i<1000; i++) để quét dữ liệu.
• Cảnh báo: UUID KHÔNG THỂ THAY THẾ được Lớp 1 và Lớp 2. Nếu hacker bằng cách nào đó biết được UUID của nạn nhân, IDOR vẫn xảy ra nếu thiếu Authorization check. UUID chỉ là “lớp sương mù”, không phải “bức tường thép”.

Lớp 4: Kiểm thử tự động (Automated Security Testing)

Đừng đợi Pentester tìm lỗi. Hãy viết Test Case cho IDOR.

• Unit Test: Tạo 2 user (Alice, Bob). Đăng nhập bằng Alice, cố gắng request dữ liệu ID của Bob. Assert rằng kết quả trả về phải là 403 Forbidden hoặc 404 Not Found.

7. Kết luận

IDOR không phải là một lỗi kỹ thuật phức tạp, nhưng nó phản ánh sự thiếu sót trong tư duy thiết kế hệ thống.

Hãy nhớ nguyên tắc vàng: Mọi request truy cập dữ liệu đều phải trả lời được hai câu hỏi:

1. Người dùng này là ai? (Authentication)
2. Dữ liệu này có phải của họ không? (Authorization)

Nếu thiếu câu hỏi số 2, chúng ta đang mở toang cánh cửa “phòng 102” cho bất kỳ ai cầm chìa khóa “phòng 101”.

The post IDOR – Lỗ hổng “ngây thơ” nhưng chí mạng trong kiến trúc phần mềm? appeared first on Tomoshare.

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.

MongoDB là một database hướng tài liệu (document), một dạng NoSQL database. Vì thế, MongoDB sẽ tránh cấu trúc table-based của relational database để thích ứng với các tài liệu như JSON có một schema rất linh hoạt gọi là BSON. Sử dụng lưu trữ dữ liệu dưới dạng Document JSON nên mỗi một collection sẽ các các kích cỡ và các document khác nhau. Các dữ liệu được lưu trữ trong document kiểu JSON nên truy vấn sẽ rất nhanh.

2. Khi nào sử dụng MongoDB

Quản lý và truyền tải content – Quản lý đa dạng nhiều product của content chỉ trong một kho lưu trữ data cho phép thay đổi và phản hồi nhanh chóng mà không chịu thêm phức tạp thêm từ hệ thống content.

Cấu trúc Mobile và Social – MongoDB cung cấp một platform có sẵn, phản xạ nhanh, và dễ mở rộng cho phép rất nhiều khả năng đột phá, phân tích real-time, và hỗ trợ toàn cầu.

Quản lý data khách hàng – Tận dụng khả năng query nhanh chóng cho phân tích real-time trên cơ sở dữ liệu người dùng cực lớn vớ các mô hình data phức tạp bằng các schema linh hoạt và tự động sharding cho mở rộng chiều ngang.

3. Ưu điểm và nhược điểm

Ưu điểm

Dữ liệu lưu trữ phi cấu trúc, không có tính ràng buộc, toàn vẹn nên tính sẵn sàng cao, hiệu suất lớn và dễ dàng mở rộng lưu trữ.

Dữ liệu được caching (ghi đệm) lên RAM, hạn chế truy cập vào ổ cứng nên tốc độ đọc và ghi cao.

Nhược điểm

Không ứng dụng được cho các mô hình giao dịch nào có yêu cầu độ chính xác cao do không có ràng buộc.

Không có cơ chế transaction (giao dịch) để phục vụ các ứng dụng ngân hàng.

Dữ liệu lấy RAM làm trọng tâm hoạt động vì vậy khi hoạt động yêu cầu một bộ nhớ RAM lớn.

Mọi thay đổi về dữ liệu mặc định đều chưa được ghi xuống ổ cứng ngay lập tức vì vậy khả năng bị mất dữ liệu từ nguyên nhân mất điện đột xuất là rất cao.

4. Kết nối Laravel + MongoDB

Tạo dự án laravel

composer create-project laravel/laravel Demo

Thêm package mongoDB vào dự án

composer require mongodb/laravel-mongodb:4.0.0

Thêm cấu hình mongoDB

Thêm vào file config/database.php

'connections' => [
        'mongodb' => [
            'driver' => 'mongodb',
            'dsn' => env('MONGODB_URI'),
            'database' => 'YOUR_DATABASE_NAME',
        ],

Để lấy các thông tin cấu hình mongoDB truy cập connection mongoDB

Tạo Database

Chọn connect->Drivers

Khi đó bạn sẽ lấy được chuỗi kết nối có dạng như thế này

mongodb+srv://<username>:<password>@test.hlpfzgm.mongodb.net/?retryWrites=true&w=majority

Cập nhật vào file .env

MONGODB_URI=mongodb+srv://<username>:<password>@test.hlpfzgm.mongodb.net/?retryWrites=true&w=majority

Lưu ý: <username> và <password> là username và password đã được nhập ở bước tạo database

Cập nhật vào file config/database.php

'default' => env('DB_CONNECTION', 'mongodb'),

Kiểm tra kết nối

Route::get('/ping', function (Request  $request) {    
    $connection = DB::connection('mongodb');
    $msg = 'Thành công!';
    try {  
        $connection->command(['ping' => 1]);  
    } catch (\Exception  $e) {  
        $msg = 'Thất bại: ' . $e->getMessage();
    }
    return ['msg' => $msg];
});

Tạo migration và model

public function up(): void
    {
        Schema::create('customers', function (Blueprint $table) {
            $table->id();
            $table->string('name');
            $table->string('email');
            $table->string('age');
            $table->timestamps();
        });
    }

Chạy lệnh:
php artisan migration
php artisan make:model Customer

//use Illuminate\Database\Eloquent\Model;
 use MongoDB\Laravel\Eloquent\Model;

class  Customer  extends  Model
{
    use  HasFactory;

    protected  $connection = 'mongodb';

    protected  $collection = 'customers';

    protected  $fillable = ['name','email','age'];
}

CRUD

//Thêm mới
CustomerSQL::create([
        'name'=> 'customer_1',
        'email'=> 'customer1@gmail.com',
        'age' => '18',
]);

//Lấy thông tin customers
Customer::where('name', 'customer_1')->get();

Hết rồi, hy vọng bài viết có thể giúp ích được cho bạn
Cảm ơn và hẹn gặp lại =)) !!!

The post Hướng dẫn kết nối Laravel + MongoDB appeared first on Tomoshare.

ORM là gì ?

ORM là 1 kỹ thuật lập trình giúp ánh xạ các record dữ liệu trong hệ quản trị cơ sở dữ liệu sang dạng đối tượng đang định nghĩa trong các class – một khái niệm phổ biến được sử dụng trong tất cả các ngôn ngữ hiện đại ngày nay như: Java, PHP, Ruby. Bạn có thể áp dụng kĩ thật này với bất cứ dự án nào bạn thích

Có hai patterns được áp dụng cho các cách thiết kế ORM khác nhau.

• Active Record: Một số ORM nổi tiếng sử dụng như: Eloquent, CachePHP, JOOQ, TOPLINK
• Data Mapper: Một số ORM nổi tiếng sử dụng như: Doctrine, Hibernate, SqlAlchemy

ORM hoạt động như thế nào ?

Cơ bản thì ORM gói gọn CSDL trong 1 object, 1 phần sẽ chứa data phần còn lại sẽ xử lý để biến nó thành CSDL quan hệ.

ORM biểu thị các đối tượng ở đó dữ liệu được hiển thị dưới dạng Object

Ưu nhược điểm của ORM

Ví dụ về lấy danh sách người dùng cùng với bài đăng mới nhất của mỗi người dùng:

$usersWithLatestPosts = DB::select('
    SELECT u.*, p.*
    FROM users u
    LEFT JOIN (
        SELECT user_id, MAX(created_at) AS latest_post_date
        FROM posts
        GROUP BY user_id
    ) latest_posts ON u.id = latest_posts.user_id
    LEFT JOIN posts p ON u.id = p.user_id AND latest_posts.latest_post_date = p.created_at
');

Đây là cách sử dụng ORM trong laravel

$usersWithLatestPosts = User::with(['posts' => function ($query) {
    $query->latest()->limit(1);
}])->get();

Như ví dụ ở trên chúng ta sẽ thấy rõ được 1 số ưu điểm khi sử dụng ORM đó là đoạn code sẽ ngắn gọn hơn, đọc vào dễ hiểu và thân thiện với coder hơn. Đó cũng là một ưu điểm nổi bật của ORM khi được áp dụng vào các dự án.

Ưu điểm:

• Dễ sử dụng và đọc
• Tính di động và linh hoạt
• Bảo mật dữ liệu
• Tương thích với quan hệ đối tượng
• Tiết kiệm thời gian phát triển

Nhược điểm:

• Hiệu suất không cao nhất
• Tùy chỉnh phức tạp
• Phụ thuộc vào ORM
• Tối ưu hóa không linh hoạt

Conclusion

Nên mix giữa ORM và Raw SQL sao cho hiệu quả. Với các truy vấn thông thường thì ORM là lựa chọn của mình. Với các tình huống phải thao tác với nhiều bản ghi, raw SQL có vẻ hợp lí hơn. Nhưng khi dùng raw sql bạn phải thực sự cẩn thận về vấn đề Sql Injection.

Cảm ơn các bạn đã theo dõi bài viết trên, trong bài viết có tham khảo từ một số nguồn khác. 🙏🙏🙏

The post Tản mạn về Object Relational Mapping appeared first on Tomoshare.

Candidate::query()
        ->where('name', 'like', "%{$key}%")
        ->orWhere('address', 'like', "%{$key}%")
        ->get();

Và mỗi lần thêm trường tìm kiếm, bạn sẽ phải viết thêm vài dòng where như thế này nữa, và còn nhiều nơi khác trong source code đang làm điều tương tự, quá nhiều where “like” đúng không nào.

Sử dụng Laravel Eloquent Builder Macro

Bạn chỉ cần vào App\Providers\AppServiceProvider và khai báo đoạn code sau vào phương thức boot().

public function boot()
{
  Builder::macro('whereLike', function ($column, $value = null, $boolean = 'and') {
      return $this->where($column, 'like', $value, $boolean);
  });
}

Hoặc bạn cũng có thể đăng ký một Service Providers như sau:

1. Sử dụng Artisan Command:

php artisan make:provider MarcoServiceProvider

Lệnh này sẽ tạo ra một file mới tên là MarcoServiceProvider.php trong thư mục app/Providers.

2. Khởi tạo chức năng với phương thức boot():

public function boot()
{
  Builder::macro('whereLike', function ($column, $value = null, $boolean = 'and') {
      return $this->where($column, 'like', $value, $boolean);
  });
}

3. Đăng ký Service Provider:
Mở file config/app.php và thêm Service Provider vào mảng providers.

'providers' => [
    // ...
    App\Providers\MarcoServiceProvider::class,
],

Bây giờ bạn đã có thể dùng câu truy vấn whereLike rồi (happy).

Đoạn code ví dụ sẽ được viết lại như thế này:

Candidate::query()
        ->whereLike('name', "%{$key}%")
        ->whereLike('address', "%{$key}%", 'or')
        ->get();

Làm một cái gì đó gọn hơn nhé.

// App\Providers\MacroServiceProvider
Builder::macro('whereLike', function ($columns = [], $value = null, $boolean = 'and') {
    return array_map(function ($column) use ($value, $boolean) {
        $this->where($column, 'like', $value, $boolean);
    }, $columns);
});

Và khi sử dụng thì bạn chỉ cần truyền một array vào whereLike là đã ok rồi.

Candidate::query()
        ->whereLike(['name', 'address'], "%{$key}%", 'or')
        ->get();

Nhưng nếu một lúc nào đó, bạn chỉ muốn tìm kiếm những ứng viên có đang hoạt động (status = 1) thôi thì whereLike này có thể sẽ không còn đúng nữa. Ví dụ:

Candidate::query()
        ->whereLike(['name', 'address'], "%{$key}%", 'or')
        ->where('status', 1)
        ->get();

Đoạn code được viết lại:

Candidate::query()
        ->where('name', 'like', "%{$key}%")
        ->orWhere('address', 'like', "%{$key}%")
        ->where('status', 1)
        ->get();

Vậy bây giờ, việc cần làm là định nghĩa thêm một truy vấn mới và tái sử dụng whereLike.

Builder::macro('subWhereLike', function ($columns = [], $value = null, $boolean = 'or') {
    return $this->where(function ($q) use ($columns, $value, $boolean) {
        $q->whereLike($columns, $value, $boolean);
    });
});

Đã ổn hơn rồi, câu truy vấn đã được viết lại.

Candidate::query()
        ->where(function ($q) use ($key) {
            $q->where('name', 'like', "%{$key}%")
            $q->orWhere('address', 'like', "%{$key}%")
        })
        ->where('status', 1)
        ->get();

Trong một vài trường hợp, bạn mong muốn thêm một câu truy vấn khác nữa thì việc truyền thêm một Closure là điều cần thiết.

Builder::macro('subWhereLike', function ($columns = [], $value = null, $boolean = 'or', Closure $closure = null) {
    $query = $this->where(function ($q) use ($columns, $value, $boolean, $closure) {
        $q->whereLike($columns, $value, $boolean);
        
        if ($closure !== null) {
            $closure($q);
        }
    });

    return $query;
});

Sử dụng thôi nào!

Candidate::query()
        ->subWhereLike(['email', 'lastname'], "%{$key}%", 'or', 
            function ($query) use ($key) {
                $query->orWhere('phone', $key);
        })
        ->where('status', 1)
        ->get();

Hết rồi, bạn hãy thực hành và cảm nhận nhé!!!

The post Xây dựng phương thức truy vấn tuỳ chỉnh với Laravel Eloquent Builder Macro appeared first on Tomoshare.

Hãy cùng tìm hiểu PHP có những tính năng nào mới và sự thay đổi nào ở bản phát hành mới nhất này.

1. Typed Class Constants

PHP 8.3 trở lên hỗ trợ khai báo kiểu dữ liệu cho các hằng số (constant) class PHP. Điều này đảm bảo tính tương thích về kiểu của các constant khi các class con và các class implement interface ghi đè lên chúng.

// Khai báo kiểu dữ liệu sau từ khoá "const"
interface I {
    const string PHP = 'PHP 8.3';
}

class X {
  protected const string FOO = 'foo';
}

trait Y {
  public const string BAR = 'bar';
}

• Điều gì xảy ra nếu giá trị của constant có type khác với type đã khai báo:

class X {
    const string PHP = 1;
}

// Fatal error: Cannot use int as value for class constant X::PHP of type string

• Ở PHP version trước 8.3, chúng ta có thể override lại giá trị của constant khi triển khai interface hoặc class cha:

interface I {
    const PHP = 'PHP 8.2';
}

class Foo implements I {
    const PHP = [];
}

• Nhưng PHP 8.3 đã ngăn chặn việc thay đổi type của constant không tương thích với type đã khai báo ở interface hoặc class cha:

interface I {
    const string PHP = 'PHP 8.3';
}

class Foo implements I {

    // Illegal
    // Fatal error: Cannot use array as value for class constant Foo::PHP       
    // of type string
    const string PHP = [];
    
    // Illegal:
    // Type must be declared if it was specified in the base class
    const PHP = "PHP 8.3";

    // Illegal:
    // In this case, we can't change the type declared in the 
    // base class, even if the new type and its value are compatible.
    const float PHP = 8.3;
    
    // Legal:
    // It's OK
    const string PHP = "PHP 8.3.x.y.z";
}

• Chúng ta có thể khai báo nhiều kiểu theo dạng “narrowed”:

class Foo {
    public const string|int FOO = 'foo';
}

class Bar extends Foo {
    public const string FOO = 'bar';
    public const int FOO = 8;
    
    // Illegal:
    // Không thể mở rộng thêm types ở class con
    public const string|int|float FOO = 8;
}

❗️ Hai types void và never không được hỗ trợ khi khai báo constant.

2. Dynamic class constant fetch

• Việc fetch các constants, có thể sử dụng hàm constant(). Ở PHP version trước 8.3, chúng ta sẽ làm thế này:

class Foo {
    public const THE_FOO = 9;
}

enum FooEnum: int {
    case FirstMember = 9;
    case SecondMember = 10;
}

$constantName = 'THE_FOO';
$enumName = 'FirstMember';

echo constant('Foo::' . $constantName); // 9
echo constant('FooEnum::' . $enumName)->value; // 9

• Từ PHP 8.3 trở đi, chúng ta có thể fetch chúng một cách linh động và gọn gàng hơn:

echo Foo::{$constantName};
echo FooEnum::{$enumName}->value;

3. json_validate() function

Khi làm việc với dữ liệu JSON-encoded, chúng ta muốn biết liệu phần payload có hợp lệ về mặt cú pháp hay không trước khi làm điều gì đó với nó.

• Trước PHP 8.3, cách duy nhất để xác định xem một chuỗi có phải là chuỗi JSON hợp lệ hay không là cố gắng decode nó và xem liệu có lỗi nào không:

function json_check(string $string): bool {
    json_decode($string);

    return json_last_error() === JSON_ERROR_NONE;
}

$string = '{ "test": { "foo": "bar" } '
echo json_check($string); // false

• Ở PHP 8.3 này, một hàm mới được bổ sung có tên json_validate() trả về true hoặc false để kiểm tra chuỗi đã cho có phải là chuỗi JSON hợp lệ hay không:

$string = '{ "test": { "foo": "bar" } '
echo json_validate($string); // false

• Nếu json_validate() trả về false, nguyên nhân có thể được truy xuất bằng cách sử dụng json_last_error() và json_last_error_msg().

❗️Important: Nếu bạn không làm gì với những thuộc tính trong payload của chuỗi JSON và chỉ cần kiểm tra JSON có hợp lệ hay không để làm 1 việc gì đó (insert vào DB chẳng hạn), thì sử dụng json_validate() sẽ sử dụng ít bộ nhớ hơn json_decode(), vì nó không cần phải mã hoá hay xây dựng cấu trúc array/object trong chuỗi JSON trên.

4. #[\Override] attribute

Giả sử chúng ta muốn override method test() của lớp cha, nhưng lại gõ sai thành best(), việc này ngầm hiểu là tạo ra method mới có tên là best(), không đúng mục đích ban đầu là override lại method test().

class Parent {
  protected function test(): void {}
}

class Child extends Parent {
  public function best(): void {}
}

PHP 8.3 cung cấp một thuộc tính mới có tên #[\Override] có thể được thêm vào các method class.

• Khi thuộc tính #[\Override] được thêm vào một method class có extend class cha hoặc implement một interface, PHP bắt buộc rằng method đó phải override hoặc triển khai method của class cha hoặc interface.
• Mục đích là để ngăn chặn việc chúng ta muốn override/triển khai method của class cha nhưng lại vô tình viết sai tên method hoặc method đó đã bị xoá khỏi lớp cha.

class Parent {
  protected function test(): void {}
}

class Child extends Parent {
  #[\Override]
  public function test(): void {}
  // Good
}

class Grand extends Parent {
  #[\Override]
  public function best(): void {}
  // Bad:
  // Fatal error: Grand::best() has #[\Override] attribute,
  // but no matching parent method exists
}

5. Deep Cloning of readonly Properties

Trong PHP 8.1, các thuộc tính readonly đã được giới thiệu, tiếp theo là class readonly trong PHP 8.2.

Một vấn đề khác là khi clone các đối tượng. Việc clone các đối tượng và thuộc tính readonly là điều không thể.

Kể từ PHP 8.3, bạn có thể linh hoạt khởi tạo lại hoặc unset các thuộc tính readonly trong quá trình clone.

readonly class Foo
{
    public function __construct(private DateTime $createdAt)
    {
    }

    public function getCreatedAt(): DateTime
    {
        return $this->createdAt;
    }

    public function __clone(): void
    {
        $this->createdAt = clone $this->createdAt;
    }
}

$instance = new Foo(new DateTime('2023-12-15'));
$cloned = clone $instance;

// For PHP < 8.3:
// PHP Fatal error: Uncaught Error: Cannot modify readonly 
// property Foo::$createdAt in Foo.php

// For PHP 8.3:
$cloned = clone $instance;
$cloned->getCreatedAt()->setDate(2023, 12, 16);

6. Randomizer::getBytesFromString() method

PHP 8.3 hỗ trợ phương thức Randomizer::getBytesFromString() mới trả về một chuỗi số ngẫu nhiên từ chuỗi đầu vào và có độ dài được yêu cầu.

Cơ hội để một byte được chọn tỷ lệ thuận với tỷ lệ xuất hiện của nó trong chuỗi đầu vào. Nếu mỗi byte xuất hiện với số lần như nhau thì mỗi byte đều có khả năng được chọn như nhau.

$random = new Random\Randomizer();
$alpha = 'ABCDEFGHJKMNPQRSTVWXYZ';

$random->getBytesFromString($alpha, 6); //  "MBXGWL"
$random->getBytesFromString($alpha, 6); //  "LESPMG"

$randomDomain = sprintf(
    "%s.example.com",
    $randomizer->getBytesFromString(
        'abcdefghijklmnopqrstuvwxyz0123456789',
        16,
    ),
);

echo $randomDomain;

Lưu ý rằng phương thức Randomizer::getBytesFromString() hoạt động ở cấp độ byte. Nó không thể xáo trộn một cách hiệu quả các ký tự nhiều byte như biểu tượng cảm xúc, ký tự CJK.

7. Randomizer::getFloat() and Randomizer::nextFloat() method

PHP 8.3 thêm các phương thức Randomizer::getFloat() và Randomizer::nextFloat() tạo ra giá trị float ngẫu nhiên.

7.1. Randomizer::getFloat()

• Ví dụ, generate 1 số float có khoảng giá trị 0 -> 5:

$random = new Random\Randomizer();

$random->getFloat(0, 5); // 2.3937446906217

Phương thức Randomizer::getFloat() chấp nhận \Random\IntervalBoundary Enum làm tham số thứ ba để cho biết liệu các giá trị min và max có phải bao gồm ở kết quả trả về hay không.

enum IntervalBoundary {
    case ClosedOpen;
    case ClosedClosed;
    case OpenClosed;
    case OpenOpen;
}

Rules như sau:

• IntervalBoundary::ClosedOpen: $min có thể được return, $max có thể không.
• IntervalBoundary::ClosedClosed: cả $min và $max đều có thể được return.
• IntervalBoundary::OpenClosed: $min có thể không được return, $max có thể.
• IntervalBoundary::OpenOpen: Cả $min và $max đều không được return.

$random = new Random\Randomizer();

$random->getFloat(0, 10, \Random\IntervalBoundary::OpenOpen); 
// 9.3835746900717

7.2. Randomizer::nextFloat()

Method Randomizer::nextFloat() mới có chức năng giống hệt với Randomizer::getFloat(0, 1, \Random\IntervalBoundary::ClosedOpen), trả về một giá trị ngẫu nhiên trong phạm vi 0 <= x < 1

$random = new Random\Randomizer();

$random->nextFloat(); // 0.3767414902847

8. PHP CLI Lint (php -l) supports linting multiple files at once

PHP CLI cung cấp tính năng Linting để kiểm tra tên tệp đã truyền để tìm lỗi syntax. Điều này rất hữu ích để kiểm tra nhanh tệp PHP hoặc đoạn mã trước khi thực thi.

• Ở PHP < 8.3, chỉ thực hiện kiểm tra lỗi syntax ở file đầu tiên được khai báo:

php -l foo.php bar.php
No syntax errors detected in foo.php

• Ở PHP 8.3:

php -l foo.php bar.php
No syntax errors detected in foo.php
No syntax errors detected in bar.php

9. mb_str_pad() function

PHP cung cấp hàm str_pad được sử dụng để đệm một chuỗi đến một độ dài xác định bằng một chuỗi khác.

Tuy nhiên, hàm str_pad không hỗ trợ các ký tự nhiều byte, dẫn đến các vấn đề khi xử lý các ngôn ngữ sử dụng mã hóa nhiều byte như UTF-8.

Kể từ PHP 8.3, hàm mb_str_pad được cung cấp để giải quyết hạn chế trước đó của hàm str_pad trong việc xử lý mã hóa ký tự nhiều byte như UTF-8.

echo mb_str_pad('卞卞', 6, '义', STR_PAD_BOTH); 
// 义义卞卞义义

echo mb_str_pad('▶▶', 6, '❤❓❇', STR_PAD_RIGHT); 
 // string(18) "▶▶❤❓❇❤"
 
echo mb_str_pad('▶▶', 6, '❤❓❇', STR_PAD_LEFT);  
// string(18) "❤❓❇❤▶▶"

10. str_increment(), str_decrement() functions

Kể từ PHP 8.3, các hàm str_increment có thể được sử dụng tăng một chuỗi chữ và số, và hàm str_decrement giảm một chuỗi chữ và số.

Các hàm này có thể đặc biệt hữu ích trong các tình huống mà bạn cần quản lý các chuỗi chữ và số đại diện cho các giá trị tuần tự.

echo str_increment('ABC'); // ABD
echo str_decrement('ABC'); // ABB
echo str_increment('39'); // 40
echo str_decrement('38'); // 37

Vẫn còn một vài tính năng mới và thay đổi trong version này, mọi người có thể xem thêm tại: https://www.php.net/releases/8.3/en.php#other_new_things

Cảm ơn mọi người đã dành thời gian để đọc 🙇‍♂️

The post Có gì mới ở PHP 8.3? appeared first on Tomoshare.

Ứng dụng Progressive Web Apps (PWA) với Laravel kết hợp những lợi ích của cả ứng dụng web và di động, mang đến trải nghiệm nhanh, khả năng hoạt động offline và cập nhật tự động cho người dùng. Những ứng dụng này cung cấp trải nghiệm giống như ứng dụng di động trực tiếp trong trình duyệt web, cho phép người dùng truy cập ứng dụng mượt mà mà không phụ thuộc vào điều kiện mạng hay thiết bị của họ. Với Progressive Web Apps, người dùng có thể trải nghiệm những lợi ích của một ứng dụng di động mà không cần phải tải về và cài đặt riêng biệt.

Những lợi ích của PWAs

Progressive Web Apps (PWAs) đại diện cho một kiểu mới của ứng dụng web kết hợp những tính năng tốt nhất của ứng dụng web truyền thống và ứng dụng di động native. Bằng cách tận dụng các công nghệ web hiện đại, PWAs mang lại trải nghiệm giống như ứng dụng. Một số ưu điểm chính của PWAs so với ứng dụng web thông thường bao gồm:

1. Offline Access: PWAs có thể lưu trữ dữ liệu cục bộ, cho phép người dùng truy cập nội dung ứng dụng ngay cả khi họ không có kết nối internet. Tính năng này làm cho PWAs trở nên đáng tin cậy và thuận tiện hơn cho người dùng, vì họ không còn phải lo lắng về vấn đề kết nối.

2. Push Notifications: PWAs có thể gửi thông báo đến người dùng, giữ cho họ được thông tin và tương tác với ứng dụng. Tính năng này giúp tăng cường sự tương tác và giữ chân người dùng, vì họ có khả năng quay lại ứng dụng nếu họ nhận được thông báo đều đặn.

3. App-Like Interface: PWAs cung cấp giao diện người dùng giống như ứng dụng, nâng cao trải nghiệm tổng thể. Giao diện này trực quan và dễ sử dụng, khiến cho nó trở nên hấp dẫn hơn đối với người dùng quen thuộc với việc sử dụng ứng dụng di động native.

4. Fast Loading Times: PWAs được tối ưu hóa cho tốc độ, đảm bảo một trải nghiệm người dùng mượt mà. Tính năng này đặc biệt quan trọng trong thế giới kỹ thuật số ngày nay, nơi người dùng mong đợi ứng dụng tải nhanh và hiệu quả.

Triển khai PWA trong ứng dụng Laravel

1. Cài đặt thư viện:

Mở file composer.json và thêm đoạn mã sau

"require": {
    "silviolleite/laravelpwa": "~2.0.3",
},

Hoặc bạn có thể mở terminal của project lên chạy lệnh

composer require silviolleite/laravelpwa --prefer-dist

Để thêm file config thì sẽ chạy lệnh

$ php artisan vendor:publish --provider="LaravelPWA\Providers\LaravelPWAServiceProvider"

Một file config/laravelpwa.php sẽ được sinh ra, bạn có thể thay đổi thông tin tên ứng dụng, màu sắc, kích thược ở đây để phù hợp với ứng dụng của mình.

'manifest' => [
        'name' => env('APP_NAME', 'My PWA App'),
        'short_name' => 'PWA',
        'start_url' => '/',
        'background_color' => '#ffffff',
        'theme_color' => '#000000',
        'display' => 'standalone',
        'orientation' => 'any',
        'status_bar' => 'black',
        'icons' => [
            '72x72' => [
                'path' => '/images/icons/icon-72x72.png',
                'purpose' => 'any'
            ],
            '96x96' => [
                'path' => '/images/icons/icon-96x96.png',
                'purpose' => 'any'
            ],
            '128x128' => [
                'path' => '/images/icons/icon-128x128.png',
                'purpose' => 'any'
            ],
            '144x144' => [
                'path' => '/images/icons/icon-144x144.png',
                'purpose' => 'any'
            ],
            '152x152' => [
                'path' => '/images/icons/icon-152x152.png',
                'purpose' => 'any'
            ],
            '192x192' => [
                'path' => '/images/icons/icon-192x192.png',
                'purpose' => 'any'
            ],
            '384x384' => [
                'path' => '/images/icons/icon-384x384.png',
                'purpose' => 'any'
            ],
            '512x512' => [
                'path' => '/images/icons/icon-512x512.png',
                'purpose' => 'any'
            ],
        ],
        'splash' => [
            '640x1136' => '/images/icons/splash-640x1136.png',
            '750x1334' => '/images/icons/splash-750x1334.png',
            '828x1792' => '/images/icons/splash-828x1792.png',
            '1125x2436' => '/images/icons/splash-1125x2436.png',
            '1242x2208' => '/images/icons/splash-1242x2208.png',
            '1242x2688' => '/images/icons/splash-1242x2688.png',
            '1536x2048' => '/images/icons/splash-1536x2048.png',
            '1668x2224' => '/images/icons/splash-1668x2224.png',
            '1668x2388' => '/images/icons/splash-1668x2388.png',
            '2048x2732' => '/images/icons/splash-2048x2732.png',
        ],
        'shortcuts' => [
            [
                'name' => 'Shortcut Link 1',
                'description' => 'Shortcut Link 1 Description',
                'url' => '/shortcutlink1',
                'icons' => [
                    "src" => "/images/icons/icon-72x72.png",
                    "purpose" => "any"
                ]
            ],
            [
                'name' => 'Shortcut Link 2',
                'description' => 'Shortcut Link 2 Description',
                'url' => '/shortcutlink2'
            ]
        ],
        'custom' => []
    ]

2. Bạn cũng có thể chỉ định kích thước của hình ảnh

[
    'path' => '/images/icons/icon-512x512.png',
    'sizes' => '512x512',
    'purpose' => 'any'
],

3. Thêm vào blade của dự án

Trong view layout bạn chỉ cần thêm @laravelPWA và trong thẻ <head>

<html>

<head>
  <title>App Name - @yield('title')</title>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  @vite('resources/css/app.css')
  @vite('resources/js/app.js')
  @laravelPWA
</head>

<body class="bg-gradient-to-r from-emerald-400 to-cyan-400">
  @section('header')
    @include('layouts.partials.header')
  @show
  @section('sidebar')
  @show
  @yield('content')
</body>

</html>

Chế độ xem ngoại tuyến

Theo mặc định, chế độ xem ngoại tuyến sẽ được triển khai trong thư mục resources/views/vendor/laravelpwa/offline.blade.php. Bạn có thể custom để phù hợp với ứng dụng của mình ở đây

@extends('layouts.app')

@section('content')

    <h1>You are currently not connected to any networks.</h1>

@endsection

4. Kiểm tra ứng dụng

Để kiểm thử PWA của bạn, mở ứng dụng Laravel trong trình duyệt (Chrome, Firefox). Nhấp vào nút “Install” xuất hiện trong thanh địa chỉ của trình duyệt để cài đặt PWA lên màn hình chính của bạn.
Đây là example của mình:

Tổng kết

PWA mang lại nhiều lợi ích, bao gồm hiệu suất, trải nghiệm người dùng, offline… . Nó có thể là một xu hướng mới trong phát triển web tương lại.
Đây là nhưng kiến thức mình tham khảo được từ nhiều nguồn. Hy vọng mọi người cảm thấy thú vị và có thể áp dụng vào dự án. Cảm ơn mọi người đã dành thời gian đọc ạ ☺️☺️☺️

Nguồn:

Thư viện : https://github.com/silviolleite/laravel-pwa
Bài viết tham khảo: https://medium.com/@technophille/a-guide-to-implementing-pwa-in-laravel-applications-dc5e8e460197

The post Progressive Web Applications (PWAs) in Laravel Applications 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.