Đây là 1 tính năng hay, nhưng thực tế mình nghĩ khá ít use case sử dụng chung frontend+backend như vậy. Vì khả năng scalability, bảo mật, và quản lý chi phí khá khó khăn với hệ thống tầm trung hoặc lớn. Còn với hệ thống nhỏ thì nên sử dụng serverless có vả frontend + backend thì ổn hơn mà cũng không tốn kém
Cái server actions này làm tăng sức mạnh của FW Nextjs nhưng rõ ràng chỉ áp dụng cho những case mà app có quy mô nhỏ tới rất nhỏ với architecture ko quá phức tạp, chứ cỡ lớn hoặc enterprise là toang ngay. Thoạt nhìn có vẻ như nó làm cho nextjs thành full meta framework cover cả FE + BE như thằng meteor nhưng ko ổn lắm. Những architecture như microservices, hexagonal, rồi tới distributed system đều cần tách bạch riêng rẽ giữa FE và BE để đạt dc sự customization tối đa, như ông nextjs này thi ko làm dc, ngoài ra còn đầy rẫy "security risks"...
Theo em thấy thì tính năng này next nó đang hướng tới phụ thuộc hệ sinh thái của vercel và dành cho các công ty startup, các dự án có nhu cầu phát triển nhanh, hoặc internal project. Còn đối với 1 dự án lớn với nhiều business lắng nhằng thì khó mà có thể phát triển theo hướng này được
Tương lai sẽ có thay đổi bạn ơi, k ai nói trước được gì đâu, như ngày xưa react mới ra ngta chê react vì dồn hết code html css js vào 1 file đó, giờ nhìn lại nó lại là framework đứng đầu đó
Next.js là công cụ để Vercel bán dịch vụ, Vercel tương lai phải đẩy mạnh Nextjs hơn nữa để hái ra tiền, phải nhìn xa hơn. Ơ cấp business lớn ngta kết hợp nhiều thể loại. Nextjs chỉ là 1 phần nhỏ có thể hướng tới.
Trà đổ vào sữa hay sữa đổ vào trà Ngày trước viết code backend => render view Ngày nay nghĩ ra spa => rồi move lên server render => rồi viết backend trên code fe. Back to basic
Tính năng SSR của Next.js rất tiện lợi cho việc cấu hình dự án & tối ưu hoá SEO. Nhưng em đang lo ngại về vì toàn bộ render được đẩy về máy chủ có làm cho việc quản lý chi phí dự án bị tăng cao so với SSG (render ở phía trình duyệt khách), không tận dụng được thiết bị của user & phải trả thêm chi phí cho việc thuê dung lượng máy chủ không anh. Vậy, anh đánh giá khi nào nên dùng SSR & khi nào nên dùng SSG vậy anh.
thực sự thì cũng hữu dụng nhưng chỉ đối với những nghiệp vụ nhỏ thôi, chứ nghiệp vụ lớn thì thôi nên chia rõ ràng backend cho dễ quản lý chứ gộp kiểu nó khó kiểm soát quá
hồi xưa thì BE SSR, dần dần xu thế muốn tách biệt FE & BE ra như ngày nay. Và hiện tại lại muốn quay về thời xưa =)) liệu php có hồi sinh 1000% máu ko ae
cải lùi à what :(( đầu tiên gắn với nhau kiểu mvc xong chia thành front end với back end , rồi lại nghĩ cách chèn sql vào . Tại sao lại làm thế. Chán thật
Project React có cả code html, code javascript component, code xử lý logic nghiệp vụ, tính năng và code SQL chung trong 1 file thì tiến hóa ngược à, vì điều này PHP đã làm từ hơn chục năm trước và bị chửi rất nhiều, lý do là có quá nhiều thứ trong 1 file dẫn đến khó maintain, và vi phạm nguyên tắc trách nhiệm đơn lẻ S trong SOLID
được cái là trải nghiệm sẽ tốt hơn, sẽ không phải reload lại page từ trên server xuống như thời xưa. Nhưng mà code kiểu này thì chả khác mẹ gì xưa là mấy, gặp phải dự án lớn thì thành mớ bòng bong. Kiếm 1 ông dev chuyên FE hoặc BE đã khó, giờ yêu cầu vừa phải FE + BE. Mấy thằng framework cứ tham vọng ôm đồm hết mọi thứ.
về cơ bản thì nếu viết chay như vậy sẽ có nguy cơ bị sql injection nhưng code production ko ai viết tường minh như vậy mà sử dụng 1 lib thứ 3 nên sẽ ngăn chặn được vấn đề này em
Cảm ơn anh đã chia sẻ
Klq nhưng chúc thầy 20/11 vui vẻ ạ🎉🎉
Cảm ơn em nhiều nhé!
Đây là 1 tính năng hay, nhưng thực tế mình nghĩ khá ít use case sử dụng chung frontend+backend như vậy.
Vì khả năng scalability, bảo mật, và quản lý chi phí khá khó khăn với hệ thống tầm trung hoặc lớn.
Còn với hệ thống nhỏ thì nên sử dụng serverless có vả frontend + backend thì ổn hơn mà cũng không tốn kém
Tuyệt vời, video hội tụ bao chất xám và kiến thức của anh. 😊
Cái server actions này làm tăng sức mạnh của FW Nextjs nhưng rõ ràng chỉ áp dụng cho những case mà app có quy mô nhỏ tới rất nhỏ với architecture ko quá phức tạp, chứ cỡ lớn hoặc enterprise là toang ngay.
Thoạt nhìn có vẻ như nó làm cho nextjs thành full meta framework cover cả FE + BE như thằng meteor nhưng ko ổn lắm. Những architecture như microservices, hexagonal, rồi tới distributed system đều cần tách bạch riêng rẽ giữa FE và BE để đạt dc sự customization tối đa, như ông nextjs này thi ko làm dc, ngoài ra còn đầy rẫy "security risks"...
cảm ơn anh ạ, video hay, hữu dụng và ra sớm luôn ạ
Theo em thấy thì tính năng này next nó đang hướng tới phụ thuộc hệ sinh thái của vercel và dành cho các công ty startup, các dự án có nhu cầu phát triển nhanh, hoặc internal project. Còn đối với 1 dự án lớn với nhiều business lắng nhằng thì khó mà có thể phát triển theo hướng này được
đúng rồi b, cái này làm dự án nhỏ thì rất nhanh luôn
Tương lai sẽ có thay đổi bạn ơi, k ai nói trước được gì đâu, như ngày xưa react mới ra ngta chê react vì dồn hết code html css js vào 1 file đó, giờ nhìn lại nó lại là framework đứng đầu đó
Next.js là công cụ để Vercel bán dịch vụ, Vercel tương lai phải đẩy mạnh Nextjs hơn nữa để hái ra tiền, phải nhìn xa hơn. Ơ cấp business lớn ngta kết hợp nhiều thể loại. Nextjs chỉ là 1 phần nhỏ có thể hướng tới.
gần đây em thấy khá nhiều bài viết nói về react-query, mong anh làm video về nó ạ
Trà đổ vào sữa hay sữa đổ vào trà
Ngày trước viết code backend => render view
Ngày nay nghĩ ra spa => rồi move lên server render => rồi viết backend trên code fe.
Back to basic
Đúng kiểu đi một vòng =)))
Tính năng SSR của Next.js rất tiện lợi cho việc cấu hình dự án & tối ưu hoá SEO. Nhưng em đang lo ngại về vì toàn bộ render được đẩy về máy chủ có làm cho việc quản lý chi phí dự án bị tăng cao so với SSG (render ở phía trình duyệt khách), không tận dụng được thiết bị của user & phải trả thêm chi phí cho việc thuê dung lượng máy chủ không anh. Vậy, anh đánh giá khi nào nên dùng SSR & khi nào nên dùng SSG vậy anh.
Nextjs càng ngày càng mạnh mẽ.
thực sự thì cũng hữu dụng nhưng chỉ đối với những nghiệp vụ nhỏ thôi, chứ nghiệp vụ lớn thì thôi nên chia rõ ràng backend cho dễ quản lý chứ gộp kiểu nó khó kiểm soát quá
4:52 anh dùng extension gì để gợi ý code như vậy ạ
github copilot
Nếu mà người ta tìm được cách để giấu đoạn code backend khi publish thì thích làm sao chả được.
Tiến hóa ngược à =]]]], không biết họ sẽ giải quyết vấn đề bảo mật như nào
Nhiều app bh viết để thay thế desktop app ko cần bảo mật đâu. App mình đang làm cũng vậy. Giới hạn ip access vào là oke.
Monolithic -> microservices giờ quay ngược lại monolithic :))
Nhìn giống sql ko phải sql đâu 🤣
Mong anh 1 series nề Nextjs ạ
rất mong anh Tùng làm tiếp video handle phía frontend ở cái topic accesstoken và refresh token ấy anh. Em cám ơn
a ra them video lap trinh ung dung di a
Tính năng hội viên còn đang hoạt động không bạn ơi, và có gì trong đó, giới thiệu cho mọi người join với
Hay quá, cảm ơn anh
hay qúa anh, mong anh làm thêm video về phần server component và client component nữa là đẹp
ko biết có ai thấy như em không, nhưng tống tất cả code fe, be chung 1 file được nhưng để làm những cái như loading thì lại phải tách file
thees react viết dc cả backend lẫn fontend
Tao xin chúng mày, làm chuyên một việc thôi. Mới được vài năm đã ngồi ôm đồm cho lắm vào. Rồi lại thành PHP version 2 à.
Muốn linh hoạt thì tự build từ các library cho khỏe, cái thời dùng các framework cồng kềnh qua rồi. Đừng làm một frameworker
hồi xưa thì BE SSR, dần dần xu thế muốn tách biệt FE & BE ra như ngày nay. Và hiện tại lại muốn quay về thời xưa =)) liệu php có hồi sinh 1000% máu ko ae
mỗi khi anh viết có code gợi ý màu mờ mờ phía sau là dùng extension gì vậy ạ
hinh nhu la Github Copilot
quá bá đạo :)
xài prisma riết mấy lệnh sql nhìn ngáo luôn 🙂🙂
cải lùi à what :(( đầu tiên gắn với nhau kiểu mvc xong chia thành front end với back end , rồi lại nghĩ cách chèn sql vào . Tại sao lại làm thế. Chán thật
ông chỉ suy nghĩ được có thế thôi à
làm 1 app hoàn chỉnh giống react nha anh
Tiến hóa ngược à ad :V
Fullstack React Developer xD
tương lai mới cho React Dev =)))
sql thuần ntn thì không biết bảo mật như nào nhỉ, ví dụ tấn công bằng sql injection chẳng hạn,...
về vấn đề security của Server Actions bạn có thể đọc thêm ở đây nhé
nextjs.org/blog/security-nextjs-server-components-actions
Khác gì PHP đâu =)))
Project React có cả code html, code javascript component, code xử lý logic nghiệp vụ, tính năng và code SQL chung trong 1 file thì tiến hóa ngược à, vì điều này PHP đã làm từ hơn chục năm trước và bị chửi rất nhiều, lý do là có quá nhiều thứ trong 1 file dẫn đến khó maintain, và vi phạm nguyên tắc trách nhiệm đơn lẻ S trong SOLID
Vậy bạn chưa hiểu react rồi. Nó rất khác với thời php
Ôm đồm nhiều thứ là không hay.
được cái là trải nghiệm sẽ tốt hơn, sẽ không phải reload lại page từ trên server xuống như thời xưa.
Nhưng mà code kiểu này thì chả khác mẹ gì xưa là mấy, gặp phải dự án lớn thì thành mớ bòng bong. Kiếm 1 ông dev chuyên FE hoặc BE đã khó, giờ yêu cầu vừa phải FE + BE. Mấy thằng framework cứ tham vọng ôm đồm hết mọi thứ.
php =))
php không viết sql ở view mà =))
@@sanghoangvan7848 php core ý ô =))
đang liên tưởng tới wordpress à
theo anh tính năng này có thể dễ dẫn đến tình trạng sql injection ko anh
về vấn đề security của Server Actions em có thể đọc thêm ở đây nhé
nextjs.org/blog/security-nextjs-server-components-actions
về cơ bản thì nếu viết chay như vậy sẽ có nguy cơ bị sql injection nhưng code production ko ai viết tường minh như vậy mà sử dụng 1 lib thứ 3 nên sẽ ngăn chặn được vấn đề này em