Chương 2: Modern Frontend Development with React
Đây là Phần 2 của series Modern Frontend Development. Hiện nay các AI tools có thể gợi ý và quyết định giúp bạn toàn bộ frontend architecture chỉ trong vài phút, nhưng câu trả lời nhanh nhất không phải lúc nào cũng là câu trả lời đúng cho thứ bạn đang build.
Trong bài này, chúng ta sẽ đi qua 3 frontend architecture phổ biến cho 1 React app: SPA + API Server, full-stack frameworks, và micro-frontends với BFFs, rồi so sánh chúng dựa trên các yếu tố thực tế như team size, nhu cầu SEO, và chi phí deployment để bạn chọn được cái phù hợp nhất.
Yêu cầu
Architecture is how you arrange the pieces for your constraints.
Nội dung bài hướng dẫn
5 phần • khoảng 45 phút
Ngày nay, AI tools có thể chọn dùm bạn cả tech stack chỉ với một prompt. Việc này rất tiện và nhanh, nhưng đó cũng là một cái bẫy. Câu trả lời nhanh nhất không có nghĩa là câu trả lời đúng cho cái bạn đang build.
Mà không chỉ AI làm vậy. Community cũng chạy đúng kịch bản này từ nhiều năm nay: framework mới ra, blog posts tràn ngập internet, và vậy là nó thành lựa chọn "hiển nhiên". Rồi thứ tiếp theo xuất hiện và vòng lặp reset. Các developer mới rất khó tìm được cái gì thực sự phù hợp với thứ mình đang build.
Tại Sao AI Hay Gợi Ý "xài Next.js"
AI coding assistant đã trở thành nguồn tư vấn architecture phổ biến. Bạn mở ChatGPT, Claude, hay Copilot và nói "giúp mình build React app cho [use case]" mà không cung cấp đủ context, gợi ý mặc định thường là Next.js.
Không phải vì Next.js luôn là lựa chọn đúng. Mà vì cách các model được train. Internet có rất nhiều tutorials, blog posts, Stack Overflow answers, và GitHub repos về Next.js. Khi model học được "hầu hết recommendations chỉ về X," nó nội suy thành "X là recommendation." Được recommend nhiều nhất và phù hợp nhất cho tình huống của bạn là hai thứ khác nhau.
Đừng Đọc Quá Nhiều Comments tranh cãi về tech
JavaScript ecosystem đã cãi nhau hơn một thập kỷ. jQuery vs Backbone. Angular vs React. Webpack vs Vite. Next.js vs Remix. Server Components vs SPAs. Những cái tên mới ra đời, nhưng các cuộc tranh cãi vẫn như cũ mà thôi.
Theo dõi những cuộc tranh cãi này không giúp bạn giỏi hơn. Bạn lướt qua một thread 200 comment mà phần lớn mọi người đang bảo vệ thứ họ đang xài, xong rồi lại tự cảm thấy sai sai với quyết định ban đầu của mình.
Building an internal B2B dashboard behind auth for 50 users. Thinking of just making a SPA with our existing REST API. Is that still a good choice?
Thứ quan trọng thật sự là học cách đánh giá. Khi framework hay pattern mới xuất hiện, thử hỏi: Nó giải quyết vấn đề gì? Project của mình có vấn đề đó không? Mình mất gì khi xài nó? Nếu câu trả lời không thật sự thuyết phục và hữu ích cho project của bạn, thì có lẽ không cần gấp phải xài nó.
Chia sẻ với mọi người
Về tác giả
NAB, Lead Engineer
Mình là Vũ, hiện là Lead Engineer ở NAB (National Australia Bank). Mình bắt đầu ở mảng Home Lending, giờ đang lead một team làm sản phẩm cho HICAPS, dịch vụ point-of-sale claiming bảo hiểm sức khỏe tư nhân lớn nhất ở Úc. Trước NAB, mình từng làm ở các startup và nhiều team khác với đa dạng stack.
Upskills là nơi mình chia sẻ những kiến thức thực tế từ công việc, để giúp bạn build và ship dự án tốt hơn. Ngoài tutorial, sắp tới sẽ có thêm nhiều nội dung: project showcase, interview prep, và các AI tool, như những resource cho hành trình học của bạn. Mình rất vui được chia sẻ những kiến thức và kinh nghiệm đã học được trong suốt quá trình làm việc, và có thể chia sẻ thêm nhiều điều thú vị cùng nhau khi chúng ta tiếp tục build những thứ hay ho.
Các bài deep-dive về web development thực tế, một đến hai tuần một số, viết bởi engineer thực sự có kinh nghiệm build sản phẩm. Không sáo rỗng, không câu view.
Chúng tôi tôn trọng quyền riêng tư. Hủy đăng ký bất cứ lúc nào.