thảo luận Quá chán với đống dependencies của Javascript, công ty mình dần chuyển về MVC

[spam102]

1. Các thư viện đa số là stable, kể cả bên lib chưa update lên thì vẫn có thể dùng được lib hiện tại

2. Làm cho code FE stupid, theo cá nhân mình thì code FE nên stupid, còn lại cứ để BE lo hết. Giờ các FE framework làm được lắm thứ quá nên nhiều ng nhét cả business logic vào BE

3. Code dễ hơn rất nhiều, ... thay vì phải học 1 đống hổ lốn JS

4. KHÔNG TỐN THỜI GIAN KHI PHẢI NPM I => rồi fix những bug quỷ quái từ trên trời rơi xuống => cái này là thích nhất

ông này chỉ nói cho sướng mồm thôi, chứ có giúp được gì đâu. Ít ra cũng nên chia sẻ thông tin, kiến thức để mọi người cũng học hỏi.

1) số 4 ko phải là ko biết lock files, làm NPM mà ko biết lock file thì có đáng bị chửi là éo biết ccc gì ko?
2) số 3 thể hiện kiến thức JS ecosystems kém đấy, nó cũng củng cố cho cái ý số 4
3) cái số 1 thể hiện ý kiến chủ quan dựa trên cái mình biết ở MVC xong đi chê Js ecosystems còn gì? Éo quản lý tốt và biết lựa chọn thư viện xong đổ lỗi cho hẹ thống

Và nhìn chung cảm giác là do éo biết lock file là chính, dẫn đến liên tục gặp lỗi khi install rồi đổ cho cái này cái kia, ko phải lúc nào cũng cần phải nâng cấp framework hay các lib, kể cả khi có security issue thì cũng cần hiểu nó impact thế nào, và thường cũng sẽ có bản patch cho các version phổ biến

 

[canh_1412]

ông này chỉ nói cho sướng mồm thôi, chứ có giúp được gì đâu. Ít ra cũng nên chia sẻ thông tin, kiến thức để mọi người cũng học hỏi.

Kinh nghiêm thứ nhất là nên có version lock.
Thứ 2 là năm rõ quy tắc đánh version, thường là senmatic version x.x.x
Thứ 3 là Đọc migration document.
Thứ 4 là đừng nhảy cóc nâng version. Ví dụ muốn nâng từ 13.x.x lên 15.x.x Thì nâng 13 lên 14 trước giai quyết hết issue rồi hãy lên 15.

Sent using vozFApp

 

[ToBe_or_NotToBe]

Anh đưa react.dev tutorial của React với 1 trong những framework rác rưởi ở trên cho 1 đứa chưa dùng FE framework bao giờ xem nó “sợ” cái nào hơn. Cái framework méo gì mà mấy chục đầu mục, đầu mục nào cũng dài thườn thượt. Tôi tự học React từ 2017-2018 mà học cả tuần vẫn thấy tối mù, xong tới React hooks là nản hẳn, code rối hơn backend vài bậc. Gần đây pick thử svelte 3 thì 1 ngày là release PoC lên được luôn, vì nó đơn giản, ko phải đụng đến state, flux gì cả… cho đến svelte 5… dcm

tôi cũng dcm svelte 5 1 cái ké

 

[spam102]

Kinh nghiêm thứ nhất là nên có version lock.

Sent using vozFApp

Phải chứ không phải là nên đâu thím

 

[thieugiatri4492]

Những người có kinh nghiệm sẽ làm khi thực sự cần thiết, ví dụ như môi trường bắt buộc phải thay đổi chẳng hạn. Vì phải đánh giá các rủi ro, kế hoạch backup thì mới ra quyết định. Sao bạn ko đặt câu hỏi là các hệ thống lớn tại sao vẫn dùng những cái cũ? Vì đợn giản nó stable.

Một vấn đề đặc biệt cần quan tâm nữa là những hệ thống liên quan đến bảo mật thì cần cẩn thận khi upgrade mọi thứ, vì ko ai biết trong các lib bạn dùng có bị chưa backdoor hay ko?

Cho mình hỏi cái này, ví dụ bên mình có bộ phận An toàn thông tin, nó kêu phải update cái thư viện đó do nó quét thấy lỗi bảo mật, không đảm bảo. Tuy nhiên hệ thống hiện tại đang vận hành ổn định, update cái thư viện mà bên kia kêu cái nó lỗi luôn, phải mò đi fix. Vậy trách nhiệm lúc đó thuộc về ai? Và làm thế nào để giải quyết tình trạng này?

 

[thieugiatri4492]

Hiểu câu "chỉ làm khi thực sự cần thiết" ko? Muốn làm thì cần đánh giá rủi ro, ưu nhược điểm thì hãy làm.

Trong trường hợp "Cần thiết" ở đây là bị ép buộc theo ý các bạn kia, và rủi ro cao là đã có dự trù trước, đã có đánh giá là không nên nhưng bắt buộc phải làm, và lúc đó thì đi dọn hậu quả rất là mệt. Nó như là 1 cái vòng lẩn quẩn vậy

 

[kikokiko00]

Cho mình hỏi cái này, ví dụ bên mình có bộ phận An toàn thông tin, nó kêu phải update cái thư viện đó do nó quét thấy lỗi bảo mật, không đảm bảo. Tuy nhiên hệ thống hiện tại đang vận hành ổn định, update cái thư viện mà bên kia kêu cái nó lỗi luôn, phải mò đi fix. Vậy trách nhiệm lúc đó thuộc về ai? Và làm thế nào để giải quyết tình trạng này?

Đảm bảo fix trên các môi trường kiểm thử trước khi đưa lên production. Các dev cần nắm được việc đảm bảo môi trường đồng nhất (có thể dùng docker) để hạn chế tối thiểu các lỗi conflict giữa các môi trường dev, staging, production với nhau nhé.

Ngoài ra luôn có plan backup, khi làm thì cần đặt câu hỏi, nếu nó ko work thì sao? Có cách nào recover được hay ko? Bên bạn giải quyết được các steps này thì tự tin 80 -> 90% việc deploy rồi nhé.

 

[thieugiatri4492]

Đảm bảo fix trên các môi trường kiểm thử trước khi đưa lên production. Các dev cần nắm được việc đảm bảo môi trường đồng nhất (có thể dùng docker) để hạn chế tối thiểu các lỗi conflict giữa các môi trường dev, staging, production với nhau nhé.

Ngoài ra luôn có plan backup, khi làm thì cần đặt câu hỏi, nếu nó ko work thì sao? Có cách nào recover được hay ko? Bên bạn giải quyết được các steps này thì tự tin 80 -> 90% việc deploy rồi nhé.

Cho mình hỏi thêm ngoài lề chút, bên mình cái mô hình app và Database (DB) tách biệt nhau, thì docker có thể đảm bảo được đồng nhất cái tầng app. Tuy nhiên cái DB con product thì làm cách nào để đồng nhất dc với bên DEV nhỉ? Lúc update phải chạy các script riêng để tạo bảng phát sinh, hay package stored procedure mới cho DB Nên cực và rủi ro nhất là phần cập nhật cho DB
Tại DEV dùng 1 DB riêng máy yếu, dữ liệu thô sơ test còn thằng product thì dùng DB xịn hơn, dữ liệu khổng lồ thực tế bên khách hàng. Khi bên DEV đưa phiên bản update app, nó có cả update luôn cấu trúc DB các stored chạy dưới DB nữa, lỗi thì hay phát sinh ngay tầng DB này, và tầng DB này chứa Business logic khá nhiều. Cụ thể luôn DB mình đang dùng là Oracle

 

[Ruoi Den]

Cho mình hỏi thêm ngoài lề chút, bên mình cái mô hình app và Database (DB) tách biệt nhau, thì docker có thể đảm bảo được đồng nhất cái tầng app. Tuy nhiên cái DB con product thì làm cách nào để đồng nhất dc với bên DEV nhỉ? Lúc update phải chạy các script riêng để tạo bảng phát sinh, hay package stored procedure mới cho DB Nên cực và rủi ro nhất là phần cập nhật cho DB
Tại DEV dùng 1 DB riêng máy yếu, dữ liệu thô sơ test còn thằng product thì dùng DB xịn hơn, dữ liệu khổng lồ thực tế bên khách hàng. Khi bên DEV đưa phiên bản update app, nó có cả update luôn cấu trúc DB các stored chạy dưới DB nữa, lỗi thì hay phát sinh ngay tầng DB này, và tầng DB này chứa Business logic khá nhiều. Cụ thể luôn DB mình đang dùng là Oracle

nên quản lý database scripts bằng code. Na ná code first của Entity framework nhưng tinh gọn hơn nhiều, mình đã từng dùng thằng này DbUp (https://dbup.readthedocs.io/en/latest/) hoặc bác có thể build 1 con service riêng để xử lý.
Còn invalid data làm lỗi hệ thống thì là bài toán muôn thuở rồi, bác có thể valid nó ở tầng FE, BE, thậm chí cả DB tùy vào độ quan trọng của data đó.
Mình đã từng làm dự án quản lí script bằng tay nên cũng có những lần fix prod đau thương lắm

 

[kikokiko00]

Cho mình hỏi thêm ngoài lề chút, bên mình cái mô hình app và Database (DB) tách biệt nhau, thì docker có thể đảm bảo được đồng nhất cái tầng app. Tuy nhiên cái DB con product thì làm cách nào để đồng nhất dc với bên DEV nhỉ? Lúc update phải chạy các script riêng để tạo bảng phát sinh, hay package stored procedure mới cho DB Nên cực và rủi ro nhất là phần cập nhật cho DB
Tại DEV dùng 1 DB riêng máy yếu, dữ liệu thô sơ test còn thằng product thì dùng DB xịn hơn, dữ liệu khổng lồ thực tế bên khách hàng. Khi bên DEV đưa phiên bản update app, nó có cả update luôn cấu trúc DB các stored chạy dưới DB nữa, lỗi thì hay phát sinh ngay tầng DB này, và tầng DB này chứa Business logic khá nhiều. Cụ thể luôn DB mình đang dùng là Oracle

DB staging và production phải giống nhau, bước đưa lên production là bước cuối, và phải đảm bảo các bước trước đó ko có vấn đề gì. Ngoài ra các hệ thống tốt thì nên triển khai ci/cd cho các pull request từ dev đẩy lên các môi trường, ví dụ như tự động clone hay làm các việc liên quan đến DB trước khi kiểm thử code. Devops sẽ đảm nhận viêc đó, họ biết nên làm gì để đảm bảo chạy tốt nhất và ổn nhất cho hệ thống. Khi lỗi xảy ra trên production thì trách nhiệm sẽ thuộc về tập thể vì mỗi ông đều có trách nhiệm khi để nó lọt lên production nhé

 

[kikokiko00]

nên quản lý database scripts bằng code. Na ná code first của Entity framework nhưng tinh gọn hơn nhiều, mình đã từng dùng thằng này DbUp (https://dbup.readthedocs.io/en/latest/) hoặc bác có thể build 1 con service riêng để xử lý.
Còn invalid data làm lỗi hệ thống thì là bài toán muôn thuở rồi, bác có thể valid nó ở tầng FE, BE, thậm chí cả DB tùy vào độ quan trọng của data đó.
Mình đã từng làm dự án quản lí script bằng tay nên cũng có những lần fix prod đau thương lắm

Chạy migration db bằng code thì có tiện đó, nhưng ko nên làm quy chuẩn. Vì bên quản lý DB sẽ ko quan tâm code của bạn là cái gì, họ chỉ quan tâm đến script bạn gửi cho để check và deploy thôi. Vì khi có rủi ro từ DB thì họ sẽ phải chịu trách nhiệm nhé.

 

[Ruoi Den]

Chạy migration db bằng code thì có tiện đó, nhưng ko nên làm quy chuẩn. Vì bên quản lý DB sẽ ko quan tâm code của bạn là cái gì, họ chỉ quan tâm đến script bạn gửi cho để check và deploy thôi. Vì khi có rủi ro từ DB thì họ sẽ phải chịu trách nhiệm nhé.

Dự án phải gửi script cho đội db thì mình cũng đã từng làm và gặp issue như bác, ko thể chạy migration db được.
Còn các dự án khác mà dev maintain db thì mình thấy migration là hợp lí. Sorry vì từ ngữ hơi quy chụp, nó là case by case chứ ko thể là quy chuẩn đc

 

[RaitoLight4492]

DB staging và production phải giống nhau, bước đưa lên production là bước cuối, và phải đảm bảo các bước trước đó ko có vấn đề gì. Ngoài ra các hệ thống tốt thì nên triển khai ci/cd cho các pull request từ dev đẩy lên các môi trường, ví dụ như tự động clone hay làm các việc liên quan đến DB trước khi kiểm thử code. Devops sẽ đảm nhận viêc đó, họ biết nên làm gì để đảm bảo chạy tốt nhất và ổn nhất cho hệ thống. Khi lỗi xảy ra trên production thì trách nhiệm sẽ thuộc về tập thể vì mỗi ông đều có trách nhiệm khi để nó lọt lên production nhé

Chuyện này thực tế làm thế nào để đạt đc vậy bạn? Bên mình cũng có vấn đề như bạn trên. Nhưng cty nhỏ, budget hạn chế, hệ thống product 8 triệu khách hàng là đã quá chi phí rồi, con staging không có cách nào làm y con chính đc, do hạn chế hệ thống. Mình đang nói DB thui nha

 

[GreenArrow]

Tiện thể e hỏi ngu phát npm ci với npm i khác nhau gì ạ

 

[RaitoLight4492]

Dự án phải gửi script cho đội db thì mình cũng đã từng làm và gặp issue như bác, ko thể chạy migration db được.
Còn các dự án khác mà dev maintain db thì mình thấy migration là hợp lí. Sorry vì từ ngữ hơi quy chụp, nó là case by case chứ ko thể là quy chuẩn đc

Bên mình là có riêng tổ Db quản lý db luôn. Trường hợp này theo bạn thế nào là tối ưu cho việc cập nhật tự động và đồng nhất?

 

[kikokiko00]

Chuyện này thực tế làm thế nào để đạt đc vậy bạn? Bên mình cũng có vấn đề như bạn trên. Nhưng cty nhỏ, budget hạn chế, hệ thống product 8 triệu khách hàng là đã quá chi phí rồi, con staging không có cách nào làm y con chính đc, do hạn chế hệ thống. Mình đang nói DB thui nha

Tuỳ quy mô dự án, tài nguyên của team thì leader sẽ đưa ra cách nào để lèo lái dự án nhé bạn, có thể bỏ có thể dùng thì đều đánh giá ưu nhược điểm, rủi ro và làm. Cái nào biết trước nhưng vẫn chấp nhận thì vẫn làm được nhé Ở đây mình nói giống nhau ko có nghĩa là như nhau. Còn cách nào thì team sẽ có những giải pháp phù hợp hơn nhé.

 

[RaitoLight4492]

Chạy migration db bằng code thì có tiện đó, nhưng ko nên làm quy chuẩn. Vì bên quản lý DB sẽ ko quan tâm code của bạn là cái gì, họ chỉ quan tâm đến script bạn gửi cho để check và deploy thôi. Vì khi có rủi ro từ DB thì họ sẽ phải chịu trách nhiệm nhé.

Ví dụ như dev xây dựng code package sql dưới DB thì nếu lỗi hoặc code chậm hệ thống thì Dba có trách nhiệm tuning và hỗ trợ code ko bạn? Bên mình dba đang làm công tác này, không biết có đúng trách nhiệm không?

 

[kikokiko00]

Ví dụ như dev xây dựng code package sql dưới DB thì nếu lỗi hoặc code chậm hệ thống thì Dba có trách nhiệm tuning và hỗ trợ code ko bạn? Bên mình dba đang làm công tác này, không biết có đúng trách nhiệm không?

dba chủ yếu check theo slow query log và thiết kế db thôi nhé. Đánh giá và optimze indexing các thứ nhé. Còn nếu muốn đánh giá performance phía code thì cần profiling nha

 

[lyhungk09]

Nếu dự án k kĩ thì k cần ụpdate làm gì, chứ mấy dự án ngân hàng hay bảo hiểm, bảo mật nó tối quan trọng thì update là điều bắt buộc, mà ít ra FE update nó dễ thở hơn BE r

 

[Eternity95]

npm ci, thôi, ông npm install làm gì để ăn hành

hóng bác chia sẻ thêm, trước 1 số dự án outsource mình toàn npm install package name