công nhận là xử lý đc bài toán routing này khá là chuối, nhưng chúng ta nên chọn giải pháp sao cho phù hợp với business của từng người mình nghĩ là cũng oke rồi, ko cần cover hết mọi trường hợp ko cần thiết.
Với cả nếu xử lý được routing thì sẽ dễ hơn nhiều để ta đưa các app đang là standalone vào kiến trúc MFE:
ví dụ như đang có vài team maintain project của họ riêng, làm sao ta họ có thể đưa app của họ vào MFE dễ nhất, thường là các app đó sẽ có routing các thứ
ví dụ nếu ta muốn lấy một app open source về để phục vụ cho business của cty, liệu có dễ dàng??
Thực tế khi mình làm MFE thì mình lại thấy App view cũng phổ biến ko kém Widget view, rất nhiều team họ có app sẵn và thường họ sẽ chỉ ok dùng MFE nếu kiến trúc support routing cho họ
Cá nhân mình thấy việc xử lý routing trong các micro-frontend là rất khó khả thi vì với mỗi micro sẽ áp dụng các thư viện khác nhau rất dễ chồng chéo và ko kiểm soát đc. Với routing hoặc các thứ khác liên quan tới trình duyệt mình sẽ luôn đặt ở root app. Các front-end chỉ cung cấp phần UI và 1 số thứ khác liên quan.
Hiện tại thì Locker chưa công bố giá chính thức và vẫn để user sử dụng miễn phí trong thời gian đầu bạn ạ, mk cũng ko rõ lắm. Để chắc chắn hơn bn thử contact với customer support xem 😅
@yuisofull chỗ này thì có 2 cái limit, 1 là số opened file, 2 là số ephemeral port của haproxy khi trỏ tới 1 ip + port backend. Nên để tăng số lượng ws connection thì ngoài việc cấu hình lại opened file và ephemeral port range thì nếu full sẽ cần 1 là thêm backend server, 2 là thêm IP cho con HAproxy để có thể mở nhiều connection hơn.
cho mình hỏi là 1 proxy server hay 1 backend server cũng có số port giới hạn, vậy muốn mở nhiều websocket connection thì phải có nhiều proxy server và backend server nhỉ
được bạn. mục đích của mapping tự động là đỡ phải viết code thủ công. ví dụ bạn có 5 lớp thì sẽ rất tốn thời gian để (.setOne, .setTwo) và dễ gây nhầm lẫn.
vì đây là bài hướng dẫn cơ bản nên mình không thêm các chi tiết đó vào. Bạn xem phầm mapping có phần map từ dto sang entity. thì id của dto sẽ không được mapping qua. và còn một số tính năng như mapping với tùy chọn tên trường giữa 2 bảng khác nhau. mapping từ id sang class của một thực thể. Ví dụ Category và product và mỗi cái đều có dto -> có 4 class. ở productId bạn chỉ lưu id của category thôi. thì bạn vẫn mapping từ ProductDto(name, price, categoryId) sang một thực thể product với category đúng của nó. Và còn nhiều tính năng hay ho hữa + lý do dùng Mapstruct là hiệu suất của nó nhanh trong top 2. so với các các lib mapping khác như ModelMapper (tuy nhiên modelMapper dễ dùng hơn). Nhưng quan trọng nhất là chúng ta nên biết mấy món đồ chơi này dùng thế nào. chứ không thì viết bằng tay cho chắc nhé.
THẢO LUẬN
công nhận là xử lý đc bài toán routing này khá là chuối, nhưng chúng ta nên chọn giải pháp sao cho phù hợp với business của từng người mình nghĩ là cũng oke rồi, ko cần cover hết mọi trường hợp ko cần thiết.
Với cả nếu xử lý được routing thì sẽ dễ hơn nhiều để ta đưa các app đang là standalone vào kiến trúc MFE:
Thực tế khi mình làm MFE thì mình lại thấy App view cũng phổ biến ko kém Widget view, rất nhiều team họ có app sẵn và thường họ sẽ chỉ ok dùng MFE nếu kiến trúc support routing cho họ
Cá nhân mình thấy việc xử lý routing trong các micro-frontend là rất khó khả thi vì với mỗi micro sẽ áp dụng các thư viện khác nhau rất dễ chồng chéo và ko kiểm soát đc. Với routing hoặc các thứ khác liên quan tới trình duyệt mình sẽ luôn đặt ở root app. Các front-end chỉ cung cấp phần UI và 1 số thứ khác liên quan.
VC bạn chính là Mai Lam trong bài viết ha
có bài sau về optional chưa bạn ơi
Về cơ bản cách dùng vẫn vậy, tối ưu về hiệu năng hơn
Bài viết chi tiết quá. Cảm ơn bạn nhìu :>
Mời cười nhưng content không có gì để cười 😜
Kiến trúc Microservices là một khái niệm hot. Đó là lý do mình sẽ mày mò nghiên cứu và up bài lên đây!
Cùng theo dõi series này của mình và góp ý thêm những nhận xét nhé!
Bài viết này. của mình bị lặp!
@Tran_hieu cái này mình cũng ko rõ 😅
Cảm ơn bạn! Bài viết rất dễ hiểu
rút gọn link để chạy SEO với chạy quảng cáo trên các nền tảng tốt hơn thôi, còn về tốc độ thì chưa chắc
Hiện tại thì Locker chưa công bố giá chính thức và vẫn để user sử dụng miễn phí trong thời gian đầu bạn ạ, mk cũng ko rõ lắm. Để chắc chắn hơn bn thử contact với customer support xem 😅
Dạ đúng rồi. Cảm ơn b nhiều ạ
Co đc dùng thử k bạn nhỉ, hay dùng thì mất phí từ đầu luôn?
chí mạng luôn bro ạ 😂
@yuisofull chỗ này thì có 2 cái limit, 1 là số opened file, 2 là số ephemeral port của haproxy khi trỏ tới 1 ip + port backend. Nên để tăng số lượng ws connection thì ngoài việc cấu hình lại opened file và ephemeral port range thì nếu full sẽ cần 1 là thêm backend server, 2 là thêm IP cho con HAproxy để có thể mở nhiều connection hơn.
cho mình hỏi là 1 proxy server hay 1 backend server cũng có số port giới hạn, vậy muốn mở nhiều websocket connection thì phải có nhiều proxy server và backend server nhỉ
được bạn. mục đích của mapping tự động là đỡ phải viết code thủ công. ví dụ bạn có 5 lớp thì sẽ rất tốn thời gian để (.setOne, .setTwo) và dễ gây nhầm lẫn. vì đây là bài hướng dẫn cơ bản nên mình không thêm các chi tiết đó vào. Bạn xem phầm mapping có phần map từ dto sang entity. thì id của dto sẽ không được mapping qua. và còn một số tính năng như mapping với tùy chọn tên trường giữa 2 bảng khác nhau. mapping từ id sang class của một thực thể. Ví dụ Category và product và mỗi cái đều có dto -> có 4 class. ở productId bạn chỉ lưu id của category thôi. thì bạn vẫn mapping từ ProductDto(name, price, categoryId) sang một thực thể product với category đúng của nó. Và còn nhiều tính năng hay ho hữa + lý do dùng Mapstruct là hiệu suất của nó nhanh trong top 2. so với các các lib mapping khác như ModelMapper (tuy nhiên modelMapper dễ dùng hơn). Nhưng quan trọng nhất là chúng ta nên biết mấy món đồ chơi này dùng thế nào. chứ không thì viết bằng tay cho chắc nhé.