Khá thực tế và bổ ích ^^

@phhuy38 vẫn dùng bác ơi, cơ mà chủ yếu để tận dụng cấu trúc database của nó, còn lại thì custom là nhiều , symfony 4 cũng ngon phết mà

Cool bro, bài viết để intro vào fuzzy search rất hay.

Như trên đã nói. Một số bài toán sử dụng Tham Lam sẽ có thể đưa ra kết quả với độ chính xác ko quá cao. Còn nếu có cách khắc phục thì những thuật toán tính hết các nhánh hay rollback nó đã ko ra đời r :>😁

@nam90nh Dưới đây là 1 vi dụ mình có viết thử, các thành phần bao gồm:

• 1 ô input với id = "abc"
• 1 ô select box với id = "location" Action:
• bạn có thể nhập giá trị bất kỳ vào ô input hoặc giá trị bất kỳ vào ô select
• tuy nhiên với đoạn code dưới thì khi nào bạn nhập xong ở ô input thì giá trị của ô select box sẽ luôn là A01 Note: ví dụ này có thể không giống 100% nhưngx gì bạn cần nhưng mà mình nghĩ đi theo cách này có thể giải quyết được vấn đê bạn đang gặp phải

const haha = document.getElementById('abc');
haha.addEventListener("focusout", () => {
    const select = document.getElementById("location");
    select.value = "A01";
})

Rất cảm ơn bạn. Cùng nhau sẻ chia quà tặng cuộc sống.

Cảm ơn bạn đã góp ý, phần này lỗi do mình ùi 😢 ban đầu mình định dùng bcrypt cho đơn giản như quên mất vấn đề max length của nó. Phần này bạn có thể dùng package node:crypto ở trên để giải quyết. Mình sẽ note lại ở bài viết và thời gian tới khi có thời gian sẽ chỉnh sửa lại dùng crypto luôn 😂

Giờ thế giới vẫn dùng ECCUBE hả các bác?

cực kì hữu ích, cảm ơn vì tâm huyết của tác giả

@NamNhiNhanh

1. Đúng rồi, không fair là đúng, vì mục đích của mình là để so sánh 2 phương pháp.
2. Mình nói là chưa thấy ai làm vậy, mình cũng chưa làm nên không có kinh nghiệm để bàn luận thêm.
3. TPS liên tục thì con nào cũng chết cả, con nào chết trước con nào chết sau thôi. Cũng tùy trường hợp, max bạn xử lý tốt 10 connection, mà bạn fixed 8 conn, thì sẽ thua cái pool max size 10 conn, pool size vẫn flexible hơn, cần ít xài ít, cần nhiều keep nhiều.
4. Câu này mình thấy không giống câu hỏi, mà chắc bạn cũng biết rồi nên mình không trả lời.

@VIIGstar2 Thanks b 😊 những vấn đề này mình đã giải thích chi tiết ở comment phía trên hết rồi. Mình hoàn toàn đồng ý với 3 ý này của bạn nhé!

@Plumpboy Bạn đọc kĩ bình luận mình có giải thích vấn đề này cho bạn Kỵ Long ở trên rồi đó 😊

@nguyentuan239

1. Đã sử dụng multipart và chunk rồi thì thường ng ta hướng đến việc gửi nhiều phần cùng lúc -> ko nên await từng phần. Theo template multipart của s3 thì mình có thể gửi các phần của file kèm với index của nó theo thứ tự. Sau khi upload hết các chunk thì gửi tín hiệu complete để BE thực hiện ghép theo index
2. Chặt chẽ hơn thì trước khi upload, cần khai báo (gọi API) request multipart upload, có timeout để BE chủ động biết những file rác/chunk rác nào có thể được clean. Khai báo tổng số phần, kích thước mỗi phần, loại dữ liệu, data hash để so sánh sau khi ghép ... rất nhiều cách để khớp thông tin server /client
3. Nếu mà lquan đến ổ đĩa đầy, thì định lưu disk, sẽ cần phải tính đến trường hợp scale nhiều bản sao service ở máy ảo, container khác nhau, ko chung disk để ghép -> anh nghĩ lưu db hơi chậm nhưng phù hợp hơn khi muốn scale

Cảm ơn anh vì series chất lượng này. Nhưng có một vấn đề em gặp phải khi làm theo đó mà dùng bcryptjs để mã hóa refreshToken trước khi lưu vào db, đó là việc giới hạn kí tự được mã hóa và cắt bỏ kí tự thừa. Dẫn đến việc em dùng refreshToken cũ gọi api /auth/refresh (api refresh token) vẫn hoạt động, tức bcrypt compare refresh token cũ và refresh token mới được mã hóa trong db bằng nhau. Em có thấy vấn đề trên Link. Không biết có phải do em làm sai ở bước nào đó không, mong được a giải đáp ạ😥

Hay đó bạn. Đúng chỉ những cty outsource lớn mới hay có role này.

e đổi thử 127.0.0.1 -> localhost xem nhé

hello a, đây là wu quals hay final v ạ

@systemdesign.vn

thank bác. Các vấn đề chưa xử lí đc chắc để mình nghĩ thêm và lên thêm 1 bài nữa

@NamNhiNhanh Em đồng ý với bác là việc sử dụng redis là rất cần thiết. Nhưng cái em focus là cơ chế recovery khi redis chết. Nếu chỉ load checkpoint của redis thì sẽ chưa đáng tin cậy (reliable). Em nghĩ nên có thể kết hợp với việc load dữ liệu từ 1 Source Of Truth nào đó sẽ reliable hơn.

Nếu không có yêu cầu về thứ tự kích hoạt lệnh thì em không có phản biện gì thêm. Nhưng giả sử có yêu cầu này thì sẽ phát sinh nhiều vấn đề hay ho về thứ tự, error handling, ...

Thank you bác ♥️

không thuyết phục, nếu await như vậy thì chunk ý nghĩa gì đâu