Ở phần new RTCPeerConnection(configuration) thì configuration có bắt buộc không vậy anh?
Nếu configuration có iceServers thì khác gì với không có iceServers vậy ạ?
"tuy nhiên về bản chất thì Middleware sau khi gọi hàm next() thì sẽ không biết handler nào sẽ được gọi sau đó".
@ntngoc96wd : Anh ơi, tại sao lại không biết handler nào được gọi vậy ạ ? E nghĩ nó gọi tới middleware hoặc hanlder function đặt ngay sau nó chứ ạ ? VD: app.use("/", middleware1, middleware2, ...) thì khi gọi hàm next() của middleware1, thì ứng dụng nó chuyển quyền kiểm soát tới handler đặt sau nó mà ạ ? Không biết e hiểu vậy đúng chưa, mong anh giải thích giúp e đoạn này với, e chưa hiểu sao nó không biết gọi handler nào sau đó ạ ?
Chào bạn, mình đã đọc qua mô tả vấn đề của bạn và đang hiểu nó nằm ở Third party, không biết Third party đang dùng có phải là loại phổ biến không (Stripe, Paypal, ...), đang dùng trả phí hay trial, nhiệm vụ giao cho Third party có phải tác vụ nặng không. Nhưng mình có một số giải pháp bạn có thể tham khảo: 1. Khai thác Third party để giảm thiểu lỗi:
a. Liên hệ với Third party thông qua email để xin sự trợ giúp, xem xét tình trạng như bạn mô tả (đây là cách mà ít developer nghĩ đến), sau khi họ kiểm tra log và có thể có câu trả lời chính xác cho bạn (này của Third party nên mình cũng chịu). Đây là thông tin hữu ích để có thể khai thác tiếp
b. Đọc lại tài liệu của Third party xem có giới hạn request/second không, có một số service triển khai điều này để tránh DDos. (Mình cũng từng gặp trường hợp Third party limit request/second với khoảng thời gian random và phải tìm cách để khai thác điều đó mà không ảnh hưởng đến tác vụ của client)
2. Sử dụng WebHook
Nếu Third party có hỗ trợ Webhook thì sẽ một giải pháp tốt, bạn thêm endpoint webhook vào Third party chỉ gọi đến API xử lý trên Third party, lúc nào thành công thì Third party sẽ call API của server mình để báo kết quả. Sau đó có thể dùng Notification push thông báo phía client để gửi kết quả. Trường hợp không có Notification, có thể dùng API GET call check kết quả trên server sau n giây, tất nhiên chỉ trong phạm vi tác vụ của client đó muốn.
Đọc bài này thì thấy bạn có phân tích về số lượng module của GetX không cần thiết, cũng như việc GetX update code khá nhiều. Cái này nếu dùng làm điểm trừ để cân nhắc giữa Bloc và GetX thì cũng không phải lợi thế quá lớn.
Còn về phần giao tiếp giữa các phần.
contronller -> view:
Bloc: emit lưu state rồi thông báo tới Bloc widget
GetX: obs.value nó cũng là 1 hàm set. lưu giá trị rồi gửi thông báo tới Obx
=> phần này bản chất là như nhau.
view -> controller:
GetX: dùng trực tiếp các api định nghĩ trong controller
Bloc: view bắn các event xong bên trong bloc switch tới các api. hoàn toàn có thể bỏ qua event mà dùng trực tiếp như getX (thằng Cubic triển khai như này).
=> nhìn qua thì cũng không tính là khác biệt.
Nếu như bên Bloc có BlocProvider.of<LoginBloc>(context) thì bên GetX cũng có Get.find<LoginController>()
Chỗ Bloc có thể nhận event khi có noti, DB thay đổi thì bản thân thằng Getx có thể triển khai được.
Tổng kết: Như phân tích của bạn thì Bloc làm được gì thì GetX cũng có hoặc setup triển khai được thậm chí là tốt hơn. Mình vẫn không thể tìm được điều gì khiến Bloc được đánh giá cao hơn so với GetX cho các dự án size lớn
alo ông đóng góp cái bài mà tôi đ hiểu luôn đấy, AC rồi qua gpt vì cái đề nó khó hiểu vãi ien. Sol GPT đổi mỗi ma trận A là 3 dòng cuối ma trận B là 3 dòng đầu thì AC, đề thì cho A trước B sau hay ông chơi chữ, có tâm tý đi bạn ơi
alo có phải ông là tác giả của bài play matrix trên cái nền tảng viblo này không? nếu phải thì cho tôi hỏi ông description cái bài đấy kiểu đ gì thế tôi đọc đ hiểu ông ạ, ông giải thích rõ nét hơn được không?
THẢO LUẬN
Ở phần new RTCPeerConnection(configuration) thì configuration có bắt buộc không vậy anh? Nếu configuration có iceServers thì khác gì với không có iceServers vậy ạ?
"tuy nhiên về bản chất thì Middleware sau khi gọi hàm next() thì sẽ không biết handler nào sẽ được gọi sau đó".
@ntngoc96wd : Anh ơi, tại sao lại không biết handler nào được gọi vậy ạ ? E nghĩ nó gọi tới middleware hoặc hanlder function đặt ngay sau nó chứ ạ ? VD: app.use("/", middleware1, middleware2, ...) thì khi gọi hàm next() của middleware1, thì ứng dụng nó chuyển quyền kiểm soát tới handler đặt sau nó mà ạ ? Không biết e hiểu vậy đúng chưa, mong anh giải thích giúp e đoạn này với, e chưa hiểu sao nó không biết gọi handler nào sau đó ạ ?
Copy nếu dùng Spread Operator thì chỉ là Shallow thôi chứ nhỉ, nếu tồn tại ref type trong lúc cop thì cũng bê sang mà
cảm ơn anh đã dành thời gian tổng hợp ạ
Còn mounted anh trai ơi
Bài viết bao năm mà vẫn chất lượng thật
hài thật
Cảm ơn bạn mk sẽ cập nhật lại
Chào bạn, mình đã đọc qua mô tả vấn đề của bạn và đang hiểu nó nằm ở Third party, không biết Third party đang dùng có phải là loại phổ biến không (Stripe, Paypal, ...), đang dùng trả phí hay trial, nhiệm vụ giao cho Third party có phải tác vụ nặng không. Nhưng mình có một số giải pháp bạn có thể tham khảo:
1. Khai thác Third party để giảm thiểu lỗi:
a. Liên hệ với Third party thông qua email để xin sự trợ giúp, xem xét tình trạng như bạn mô tả (đây là cách mà ít developer nghĩ đến), sau khi họ kiểm tra log và có thể có câu trả lời chính xác cho bạn (này của Third party nên mình cũng chịu). Đây là thông tin hữu ích để có thể khai thác tiếp
b. Đọc lại tài liệu của Third party xem có giới hạn request/second không, có một số service triển khai điều này để tránh DDos. (Mình cũng từng gặp trường hợp Third party limit request/second với khoảng thời gian random và phải tìm cách để khai thác điều đó mà không ảnh hưởng đến tác vụ của client)
2. Sử dụng WebHook
Nếu Third party có hỗ trợ Webhook thì sẽ một giải pháp tốt, bạn thêm endpoint webhook vào Third party chỉ gọi đến API xử lý trên Third party, lúc nào thành công thì Third party sẽ call API của server mình để báo kết quả. Sau đó có thể dùng Notification push thông báo phía client để gửi kết quả. Trường hợp không có Notification, có thể dùng API GET call check kết quả trên server sau n giây, tất nhiên chỉ trong phạm vi tác vụ của client đó muốn.
Mình đã phản hồi bạn rồi, cám ơn bạn
Bảng nhỏ nên là partition sẽ chậm hơn chưa partition nhé bạn. Cái này là để xử lý khi dữ liệu tăng trưởng từ 2GB trở lên
mình làm theo như hướng dẫn nhưng vẫn hiện số người là 0 Cái cày có phải khởi chạy Laravel Echo ji thêm không ad ơi
Nên dùng từ package-private thay vì default sẽ ok hơn.
bạn có thể cho mình thông tin để liên hệ được không.
Cam on ban nha 😁
bác làm đc không ạ?, t cũng đang mắc chỗ này
Đọc bài này thì thấy bạn có phân tích về số lượng module của GetX không cần thiết, cũng như việc GetX update code khá nhiều. Cái này nếu dùng làm điểm trừ để cân nhắc giữa Bloc và GetX thì cũng không phải lợi thế quá lớn. Còn về phần giao tiếp giữa các phần.
contronller -> view:
=> phần này bản chất là như nhau.
view -> controller:
=> nhìn qua thì cũng không tính là khác biệt.
Nếu như bên Bloc có BlocProvider.of<LoginBloc>(context) thì bên GetX cũng có Get.find<LoginController>() Chỗ Bloc có thể nhận event khi có noti, DB thay đổi thì bản thân thằng Getx có thể triển khai được.
Tổng kết: Như phân tích của bạn thì Bloc làm được gì thì GetX cũng có hoặc setup triển khai được thậm chí là tốt hơn. Mình vẫn không thể tìm được điều gì khiến Bloc được đánh giá cao hơn so với GetX cho các dự án size lớn
alo ông đóng góp cái bài mà tôi đ hiểu luôn đấy, AC rồi qua gpt vì cái đề nó khó hiểu vãi ien. Sol GPT đổi mỗi ma trận A là 3 dòng cuối ma trận B là 3 dòng đầu thì AC, đề thì cho A trước B sau hay ông chơi chữ, có tâm tý đi bạn ơi
alo có phải ông là tác giả của bài play matrix trên cái nền tảng viblo này không? nếu phải thì cho tôi hỏi ông description cái bài đấy kiểu đ gì thế tôi đọc đ hiểu ông ạ, ông giải thích rõ nét hơn được không?
good job!!