@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

@Plumpboy Bạn có thể đọc câu trả lời ở bình luận ngay phía trên đó 😀

// Make an API call to upload the chunk to the backend
            await uploadChunk(chunk, chunkIndex);

Tại sao lại await ở đây nhỉ ?

anh ơi, cho em hỏi giữa thuật toán annoy và faiss thì cái nào search face encoding nhanh và chính xác hơn ạ. Em tìm hiểu thì annoy sẽ phù hợp với số lượng vector không quá lớn, faiss thì tối ưu hơn với số lượng lớn vector. Các bài toán nhận diện khuôn mặt với dữ liệu khoảng 5000 người thì nên chọn thuật toán nào hợp lý nhất vậy anh, có thể có nhiều thuật toán hay hơn faiss và annoy.

@kiendev

1. Vấn đề k fair benmark là bạn dùng pool có size > 1 khi b test thì ứng dụng của b sẽ mở nhiều hơn 1 connection còn singleton connection là 1 connection thôi
2. Bạn nói k ai dùng việc mở trực tiếp connection đến db thì bạn quá sai. Có thể b chỉ làm các hệ thống bé. Khi b làm hệ thống lớn thường b cần kiểm soát số lượng connection 1 cách triệt để. Ví dụ có 100 service thì b cần kiểm soát chặt chẽ nhất có thể. B thử dùng pool cho 100 service thì việc db hết connection sẽ cao hơn việc b kiểm soát số connection từ đầu. => ý này mình phản biện câu k ai mở connection trực tiếp chứ k bài trừ pool
3. Bạn ns việc việc tạo connection fixed size sẽ khi bị peak nó sẽ lỗi đúng k? Trường hợp bạn dùng pool với size đaya với các hệ thống lớn tps liên tục thì cũng chết như thường nhé

=> mục đích dùng pool là để protected database, tiết kiệm resource cái ý của b ns chỉ là 1 phần lợi điểm thôi.

Tiện đây mình hỏi b thêm 1 câu nữa. Việc dùng pool có nhược điểm gi không? Trên đời này chả có cái gi là ưu điểm tuyệt đối cả.