nextjs – Blog Hoc Tap

Vũ trụ Nextjs và Headless CMS

Sau nhiều ngày chờ đợi để xem NextJS có ra bản 13.5 hay không thì cũng không chịu được nữa (nằm ở v13.4 đã gần 3 tháng) và đành khởi công dự án xây dựng Public CMS Framework (hay nói kiểu nhà quê là làm cái website) với phiên bản NextJS 13.4.12.

Server Side Rendering (SSR) với PHP

Ở #Cropcom, mỗi một Public CMS Framework được xây dựng thì xác định tối thiểu phải 5 năm sau mới thay đổi công nghệ nên việc lựa chọn công nghệ nền ban đầu ảnh hưởng rất lớn đến trải nghiệm phát triển tính năng của team, cũng như phải “chịu đựng” trong quá trình xây dựng tính năng nếu lỡ nó lạc hậu hoặc team đó bỏ rơi không phát triển tiếp công nghệ nền.

Nếu bạn quan tâm thì Public CMS Framework gần nhất của công ty do Tuấn xây dựng là dựa trên PHP 7, sử dụng một phần của Symfony HTTPFoundation để xây dựng core, sử dụng Smarty cho tầng View (HTML, CSS..), còn layer Model & Controller thì kết nối đến hệ thống microservice theo cơ chế Headless CMS. Public CMS này thực ra hiện tại vẫn ổn vì nó tương thích hoàn toàn với khả năng Server Side Rendering (SSR) để tận dụng tối đa khả năng onsite SEO.

NextJS cho SSR & CSR trong tương lai

Hướng cũ này có một bất lợi duy nhất là, sẽ khó khăn nếu tiếp cận xây dựng các tính năng không cần SEO (sau màn hình đăng nhập) như thông tin tài khoản, các tính năng sau khi đăng nhập (submit này nọ, tương tác với thành viên khác…). Lỡ theo kiến trúc này nên phần lớn các tính năng đòi hỏi thuần Client Side Rendering (CSR) toàn phải xài jQuery và code chay, rất khó mở rộng theo nhánh này. Mà ngày nay, làm gì có website nào chỉ thuẩn SEO content, nếu vậy xài WordPress cho rồi, viết framework đồ chi.

Nếu muốn viết lại Framework mới cho Public CMS thì phải giải quyết được 2 bài toán là cần có SSR, hỗ trợ được các công nghệ CSR như Reactjs…để vừa đạt hiệu quả làm SEO, vừa hỗ trợ team dev phát triển tính năng một cách hiệu quả, nhanh chóng. Thế là đến với NextJS. Hiện tại sau hơn 4 năm chạy với Nextjs (từ nextjs 8.x đến nay thì phiên bản 13.4 được coi là siêu ổn để giải quyết 2 vấn đề lớn mà Tuấn cần giải quyết cho Public CMS của mình.

Lựa chọn UI Component Library

Tuy nhiên, sau khi trào lưu di dời sang Nextjs thì sẽ phát sinh 1 vấn đề khác là không có một bộ Component UI Library hoàn hảo. Và vấn đề này luôn là mối quan ngại khi xây dựng CMS với Nextjs bởi chưa có “cái nào” mà mình đánh giá là xài được. Radix UI thì có vẻ phức tạp, ngôi sao mới nổi Shadcn thì tạo ra các giao diện không mấy thân thiện với người dùng bình thường nên chủ yếu shadcn để xây các sản phẩm hơi hướng tinh giản và tech savy. Chưa kể nhiều UI Lib không tương thích với React Server Component.

Dường như vũ trụ Nextjs đã lắng nghe, và sau 1 ngày xây dựng thì dự án NextUI (không liên quan đến Vercel) hôm qua đã ra mắt phiên bản 2.0 với RẤT nhiều cải tiến mà sẽ dùng tốt cho NextJS 13 (dùng App Router). Việc thấy được sự ra mắt của NextUI 2.0 chính là cảm hứng cho mình chia sẻ bài viết này cũng như mọi người có thể hình dung xây dựng một Public CMS cần có nhiều yếu tố cân nhắc vì tính dài hạn và hướng người dùng (UX) & hướng dev (DX).

NextUI Website: https://nextui.org/

Trong tương lai nếu có lib nào xịn hơn thì sẽ xem xét và cân nhắc, nhưng cho đến hôm nay thì mình thấy NextUI là chân ái và sẽ apply cùng với TailwindCSS cho toàn bộ các design của CMS.

CHỌN CX HAY DX?

Dạo gần đây trên twitter có rất nhiều chỉ trích từ cộng đồng làm frontend về việc bản #Nextjs 13.4 cho tới 13.6 có trải nghiệm compile ở máy rất tệ khi sử dụng kiến trúc mới là App Router. Thời gian mỗi lần hot reload tính bằng giây và bản thân Tuấn đang phát triển cho hệ thống IDP của #cropany cũng thấy trải nghiệm tương tự, gần đây mỗi lần nhấn lưu là banh xác, chờ vài giây và compile vài ngàn module.

Việc này ảnh hưởng lớn đến #DX – hay gọi dễ hiểu là Trải nghiệm của lập trình viên (Developer Experience), cái được cộng đồng đánh giá công ty Vercel (hay dự án Nextjs) là một công ty có DX rất tốt, riêng mình nói về vụ DX thì Vercel là dẫn đầu thị trường thì nay lại bị chê bai rất nhiều.

Tuy nhiên, giá trị của kiến trúc App Router từ bản Nextjs 13.4 là không thể chối từ, nó đem lại trải nghiệm tốt hơn về thiết kế UI, Render flow (page, layout, template, server component, server action…) và cải thiện SEO ở mức tốt nhất cho các dự án CMS/Ecommerce. Đây cũng là lý do chính mà cả bộ sậu Vercel đầu tư rất nhiều vào kiến trúc App Router (thư mục “app”) để thay thế cho kiến trúc thư mục “pages” cũ. Những lợi ích này có giá trị rất lớn cho #CX – hay gọi dễ hiểu là Trải nghiệm của khách hàng (Customer Experience) 👍.

Các cuộc tranh cãi nổ ra kiểu nếu DX của App Router còn tệ hại như vậy thì chúng tôi sẽ bỏ đi, sẽ Vite + ReactJs, sẽ Angular, sẽ Gatsby 🤭…mà hoàn toàn phủ nhận giá trị của CX mà Nextjs mang lại.

Lịch sử đã cho thấy, chúng ta (developer) sẽ sẵn sàng đánh đổi 1 chút DX của mình để khách hàng được trải nghiệm tốt nhất. Chúng ta đã từng có giai đoạn dành cả tiếng đồng hồ để compile một phần mềm trong mỗi lần thử, dành cả ngày để render cái scene 3D cho đẹp hơn xí,… mà giờ có vài giây cũng kêu ca. Tuy nhiên, nếu sự chờ đợi dành cho quá trình phát triển để đem lại trải nghiệm cho khách hàng (CX) tốt hơn thì hoàn toàn xứng đáng. Vì trải nghiệm khách hàng khi sử dụng website tốt sẽ đem lại tiền cho doanh nghiệp.

Nói đi cũng phải nói lại, nếu DX của hệ thống tệ và đối thủ làm tốt hơn thì cộng đồng có thể quay lưng (như cách chúng ta đã quay lưng với nhiều thứ để đến với Nextjs). Hoặc nếu trong một dự án mà DX tệ thì sẽ ảnh hưởng không tốt đến nguồn lực dev của công ty. Mọi người sẽ tiếp cận dự án khó hơn, phát triển tính năng lâu hơn, chỉnh sửa, nâng cấp cũng vất vả…

Và sáng nay thật nhanh chóng, NextJs đã ra bản 13.4.8 với rất nhiều cải thiện để tối ưu cho DX sau rất nhiều càm ràm (và đòi bỏ đi) trên mạng. Quả thực, đi theo Nextjs từ bản 8.x tới giờ thì Nextjs không bao giờ làm ta thất vọng và phải nói trải nghiệm DX và CX từ Nextjs luôn làm ta ngạc nhiên và xứng đáng đầu tư toàn bộ stack ở cms/ecommerce đi theo Nextjs. Và việc release này cũng làm cảm hứng cho bài chia sẻ này.