Mã hóa trc khi lưu database là điều nên làm, vì cũng yên tâm hơn nếu database bị xâm phạm. Nhg nếu muốn đơn giản hóa, bn thử ctham khảo các công cụ hỗ trợ, mk đang dùng secrets manager của bên Locker 1 thời gian thì thấy cũng ok, hoặc một dịch vụ tương tự cũng đc vì nó đã tích hợp mã hóa sẵn
Mk nghĩ vấn đề nằm ở độ nhạy cảm của secrets. Nếu đó là API key hoặc token quan trọng, tốt nhất vẫn nên mã hóa trước khi lưu. Nhưng với các secrets ít quan trọng hơn, có thể chỉ cần kiểm soát quyền truy cập là đủ. Kbt mn thg phân loại secrets theo cách nào để quyết định mức độ bảo mật?
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.
THẢO LUẬN
Mã hóa trc khi lưu database là điều nên làm, vì cũng yên tâm hơn nếu database bị xâm phạm. Nhg nếu muốn đơn giản hóa, bn thử ctham khảo các công cụ hỗ trợ, mk đang dùng secrets manager của bên Locker 1 thời gian thì thấy cũng ok, hoặc một dịch vụ tương tự cũng đc vì nó đã tích hợp mã hóa sẵn
@Phannhatnam Team mk đang dùng trình quản lý secret của Locker, bạn gõ locker tìm website là có in4 đầy đủ tham khảo xem sao
Mk nghĩ vấn đề nằm ở độ nhạy cảm của secrets. Nếu đó là API key hoặc token quan trọng, tốt nhất vẫn nên mã hóa trước khi lưu. Nhưng với các secrets ít quan trọng hơn, có thể chỉ cần kiểm soát quyền truy cập là đủ. Kbt mn thg phân loại secrets theo cách nào để quyết định mức độ bảo mật?
giá của bên này tn v bạn?
Cho mk hỏi là bên Locker này có cung cấp chức năng giám sát hđ để theo dõi địa điểm và thời điểm các secrets được truy cập ko?
Quảng cáo trá hình =))
Đang Postgres vs MySQL tự dưng sang quảng cáo ServBay ??
Chưa nữa người anh em ơi, hôm trước tui viết dở ở đó xong quên cập nhật nữa, tui đang bận một số project khác 🥹
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