thank bạn

@kylong Lời đầu tiên là mình very super thank bạn vì đã đưa ra bình luận và đặc biệt dành thời gian lúc khuya để viết comment chi tiết, đầy đủ và đúng các thứ cần phải improve nếu muốn áp dụng thực tế. Chứng tỏ chủ đề này khá được quan tâm và mình buộc phải bật dậy lấy máy tính vào reply bạn kk 😀 Trước khi trả lời từng ý của bạn mình xin phép nói 1 vài ý về bài viết của mình

1. Bài viết của mình chỉ là nêu solution hay idea về chủ đề này và implement draft các bước chính happy case.
2. Do thời gian không có + mình nghĩ bài viết cần tóm gọn để đọng lại ý chính tránh việc chi tiết quá người đọc sẽ cảm thấy dài. Từ đó sẽ không đọc hết được bài.

Vậy nên mình xin phép trả lời bạn từng ý trong comment của bạn nhé:

1. Chỗ await uploadChunk sẽ làm việc upload thành tuần tự Yes chuẩn xác b. Phần này nếu áp dụng thực tế thì có thế áp dụng tuỳ biz và PM/PO

• Không await cứ cho gửi nếu lỗi thì retry lại 5 lần hoặc 1 số nào đấy
• Await để đảm bảo truyền lên đúng từng phần.
• Gửi theo batch. Ví dụ split 5 phần thì gọi API Back-end. => Mình suggest dùng cái này thực tế nhé

2. Tiếp theo là không có xử reupload khi 1 part bị failed Yes bạn có thể handle để retry n lần nhé

3. Việc tiếp theo là server, client không có liên kết với nhau về thông tin file như tên file, loại gì, tổng trọng lượng, số lượng file chia ra bao nhiêu Đúng luôn nhé bạn. Hiện tại trên kia mình demo ý tưởng nên mặc định đang .mp4 nhé => Thông tin API gửi lên sẽ có: id, part file, index part, file type, number of parts...

4. Ngoài ra 1 vấn đề quan trọng nữa là tính toàn vẹn của 1 part, từ client về đến server không đảm bảo được nó còn giữ được data ban đầu không. Có nhé bạn ơi. Chỉ là chia nhỏ file rồi concat lại nên không mất data được đâu => Nếu trong thực tế thì thường sẽ có 1 con job đi concat lại file.

5. client: split file ra thành 1000 file trước => Việc bao nhiêu file thì tuỳ vào set batch size và size file upload nhé bạn không cần fix cứng đâu. Mỗi lần split 1 part thì gắn nó 1 index để phần biệt với các part khác: part_1, part_2, part_3,... => từ đó BE sẽ biết thứ tự cũng nhiêu số lượng part file.

6. Token, mất internet giữa chừng, đầy ổ đĩa => Yes mình đồng ý nhé. Áp dụng thực tế thì cần handle những case như thế này.

Còn thực tế thì bạn có thể bật Zalo và f12 xem Zalo xử lý nhé. Mình thấy idea giống như bài mình đề cập đó. Lời cuối cùng mình thank bạn đã góp ý, xây dựng nhé. Have a nice weekend!

Chỗ await uploadChunk sẽ làm việc upload thành tuần tự, vậy nó sẽ ko đạt đc khả năng đa luồng như ý tưởng ban đầu. Thành ra lúc này nó chỉ được cái là khó dẫn đến timeout cho mỗi part, chứ ko đẩy nhanh tốc độ.

Tiếp theo là không có xử reupload khi 1 part bị failed, nên lúc này chỉ cần 1 phải reupload cho đến khi xong.

Việc tiếp theo là server, client không có liên kết với nhau về thông tin file như tên file, loại gì, tổng trọng lượng, số lượng file chia ra bao nhiêu. Lúc này server sẽ bị mù. Cho dù nó merge xong cũng ko biết file đó là gì.

Ngoài ra 1 vấn đề quan trọng nữa là tính toàn vẹn của 1 part, từ client về đến server không đảm bảo được nó còn giữ được data ban đầu không.

Vậy nên mình xin suggest thêm idea của mình nha.

1. sau khi user upload file
2. client gởi 1 request đến server gồm:

{
name: video.mov
size: 100GB
}

3. server sẽ reponse về 1 số thứ để tiến hành upload

{
status: yes/no //no có thể là server đang quá tải, storage không đủ để xử lý file này.
chunk: 1000 //nên để server quyết định số lượng chunk, hoặc maximum size của 1 chunk vì config về upload do phía server quản mà :D
_token: $ABC$ //cái này để đảm bảo vấn đề bảo mật, chứ ai cũng up bậy vào link này đâu có được. 
//Cái tiếp theo là để cho phép duplicate trong quá trình upload. Nếu user họ upload 2 file đều tên video.mov thì sao.
}

3. <<tiến hành xử lý thôi>>
4. client: split file ra thành 1000 file trước, mỗi file như vậy cần phải được đặt tên = index + hash(chunkedFile) => khi này server có thể kiểm tra tính toàn vẹn khi nhận được.
5. client: tiến hành upload thôi, nhưng cần handle success và failed. Success thì khi đủ file thông báo, failed thì cho retry nhưng nhiều lần quá cũng ko ổn nên cho giới hạn.

let done = 0;
let stopAll = false;
const checkDone = function () {
  done++;
  if (done === server.chunk) {
	alert("File uploaded successfully.");
  }
}

const uploadChunk = function(chunkedFile, retry) {
  
  if (retry > 10) {
    stopAll = true;
	alert("Uploading failed");
  }
  
  if (stopAll) {
    return;
  }
  
  post(chunkedFile)
	.done(res => res.success ? checkDone() : uploadChunk(chunkedFile, retry+1))
	.failed(res => uploadChunk(chunkedFile, retry+1));
};
 
chunkedFiles.forEach(chunkedFile => uploadChunk(chunkedFile, 0);

6. server: cần giải quyết vấn đề tính hợp lệ của request thông qua file, hashName và _token, và _token cũng giúp biết được thông tin file và tmp lưu trữ. Vd: /tmp_$ABC$
7. sau khi nhận đủ 1000 file thì trigger đến việc merge. Tất nhiên vẫn sẽ có thành công và thất bại, nên ném user thông báo sau khi xong.

Ngoài ra còn nhiều thứ phải lo nữa, nó cũng thực tế:

• Giải quyết các file tmp, nếu HAPPY CASE thì sau khi merge xong thì ok xoá luôn đc, nhưng case user up giữa chừng bị rớt mạng đi, vậy tmp files kia sẽ thành rác. Nên sẽ cần 1 schedular chuyên đi scan xem tmp nào để lâu quá rồi thì xoá.
• Giải quyết chuyện có thể xảy ra như server đang nhận chunkedFile ngon lành thì có thông báo không đủ bộ nhớ, vậy thì thôi tạm dừng cuộc chơi. Có nghĩa response của server phải rõ ràng để client handle các case cần phải ngưng ngay lập tức.
• Còn về thuật toán split/merge của client/server cũng nên được xem xét, mà chắc dùng split/merge binary cũng ổn.

Đấy là những gì mình chém gió, mn có thấy cần chỉnh sửa gì thì đưa ý kiến thêm nhé. Thanks

cụ thể như nào bạn nói rõ hơn đc o

Bài viết hay quá. Cảm ơn tác giả ạ 😍

không thấy mô tả việc cài gitlab runner và cấu hình đăng ký nó thế nào nhỉ?

lưu lại để tham khảo

Sử dụng stored procedure như bạn không đảm bảo chống hoàn toàn việc hack mật khẩu bằng SQL injection. Stored procedure có thể giúp giảm nguy cơ SQL injection bằng cách khai báo biến khác và xử lý đầu vào, tuy nhiên để đảm bảo chặt chẽ bạn nên sử dụng tham số và câu truy vấn tham số hóa (parameterized queries) trong stored procedure nhé.

Cảm ơn góp ý của bạn

Trong các phương pháp này thì theo tác giả, phương pháp nào là tốt nhất ?

Nếu ref mà mình truyền vào object có được ko ad ? Thanks Bạn

ví dụ máy chạy win10, cài wamp hoặc laragon thì sao để trỏ về địa chỉ localhost vậy bạn

@Croud141 oke e nhe

mấy nữa rảnh a sẽ hoàn thiện lại series đó e nhé, nhìn vào series chưa xong cũng nôn nao lắm

nghe từ lâu và được ngồi 1 bạn trong cty demo nhưng sau 2 năm vẫn chưa thực sự bắt tay vào làm thử. Đến giờ trong bank cũng đang theo trend MFE

Cảm ơn bác, rất hay và hữu ích, những cái nhìn có vẻ đơn giãn nhưng khi gặp chuyện rồi mới thấy nó hữu đến mức nào.

@maitrungduc1410 Câu trả lời rất ngắn gọn xúc tích và dễ hiểu ạ. Cảm ơn a 🤟

Em hay dùng procedure để kiểm tra tài khoản và mật khẩu, tránh được SQL Injection. Em không biết procedure như vậy có tránh hoàn toàn được không ạ 😁?

có vẻ là e đang bị hiểu lầm các trường hợp đó với nhau

• việc thêm node_modules vào dockerignore là để đảm bảo, chẳng may trong trường hợp môi trường ngoài của e có node_modules thì mình ko copy nó vào lúc build image, bởi vì node_modules có thể bị ảnh hưởng bởi môi trường, nên ở môi trường nào thì ta nên chạy lại npm install cho môi trường đó và k dùng lại node_modules của môi trường khác
• ý thứ 2 là dùng container tạm thời để dev: là mục đích trong trường hợp môi trường gốc của mình ko có nodejs luôn (ko có npm), mình ko muốn cài nodejs mà vẫn muốn dev, thì mình tận dụng container thời, tạo container node để chạy npm install, cái node_modules đc sinh ra là từ container mà ra, sẽ tương thích, phù hợp để dev trực tiếp trong container