React là một framework full-stack (hoặc đang dần trở thành như vậy)
(robinwieruch.de)- React đang tiến hóa thành một framework full-stack với việc bổ sung Server Components và Server Actions
Cuộc chiến framework bắt đầu từ năm 2010
- Cuộc chiến framework bắt đầu vào năm 2010 với Backbone, Knockout và Ember, sau đó Angular và React nhanh chóng nối tiếp, và không ai có thể dự đoán được kết cục
- Trong một thời gian dài, các ứng dụng JavaScript render phía client (CSR) đã thống trị
- Những ứng dụng này còn được gọi là ứng dụng một trang (SPA), thường gồm một tệp HTML nhỏ và một tệp JavaScript lớn
- Ít nhất là trước khi kỹ thuật chia nhỏ mã nguồn được đưa vào
Sự tách biệt giữa frontend và backend
- Trong giai đoạn này, phát triển frontend bị chi phối bởi nhiều framework và thư viện JavaScript khác nhau
- Backend thường không gắn chặt với một ngôn ngữ cụ thể, và REST trở thành tiêu chuẩn cho giao tiếp API
- Với tư cách là một lập trình viên web freelance, tôi chủ yếu làm việc với backend .NET, Java, Python và PHP
- Tôi chỉ thấy TypeScript/JavaScript ở phía backend trong các dự án greenfield hoặc các dự án nhỏ nơi có thể kiểm soát backend
- Nhưng điều này có thể thay đổi với sự trỗi dậy của React full-stack
- Thật thú vị khi nhận thức của các lập trình viên về giai đoạn từ 2010 đến 2020 khác nhau tùy vào thời điểm họ bắt đầu sự nghiệp
- Những lập trình viên bắt đầu trước năm 2010 từng sống trong môi trường render phía server (SSR) và có vẻ thoải mái hơn với sự quay trở lại gần đây của các công nghệ phía server
- Trong khi đó, nhiều người khác gần như chỉ làm việc với ứng dụng render phía client (CSR) và REST API trong gần một thập kỷ
- Giờ đây họ không biết phải tiếp nhận thế giới React full-stack mới này như thế nào
TypeScript nổi lên thành tiêu chuẩn ngành
- Trong vài năm gần đây, TypeScript đã nổi lên như tiêu chuẩn của ngành
- TypeScript mang đến cho lập trình viên frontend một ngôn ngữ lập trình mạnh mẽ và có kiểu
- Khi các lập trình viên đã chấp nhận TypeScript, họ gần như không thể quay lại nữa
- Thật thú vị khi một thay đổi nhỏ trong mã nguồn có thể tạo ra ảnh hưởng lớn đến từng cá nhân và cả ngành công nghiệp
Khó khăn giữa TypeScript và REST
- Ảnh hưởng của TypeScript lên REST đã tạo ra nhiều giải pháp chắp vá
- OpenAPI (trước đây là Swagger) tồn tại để tài liệu hóa REST API, nhưng hiện nay chủ yếu được dùng để sinh ra các interface API có kiểu
- Dù có thể tạo ra interface kiểu hoàn chỉnh trong kiến trúc client-server, vẫn có nhiều dự án thất bại trong việc triển khai đúng ngay từ đầu
- Ghi chú cá nhân: "Có thể có những lập trình viên đã có trải nghiệm tốt với kiến trúc dựa trên OpenAPI, nhưng tiếc là tác giả thì không"
TypeScript đã thay đổi bầu không khí
- Khá thú vị khi thấy TypeScript đã thay đổi cục diện ở đây như thế nào
- Một mặt, các SPA không có kiểu dùng REST (với OpenAPI cho mục đích tài liệu hóa) từng có vẻ là “ổn”
- Nhưng khi TypeScript trở thành tiêu chuẩn và được xem là chuẩn mực, các interface kiểu được sinh ra trở nên khó chịu khi sử dụng vì codebase frontend đã quen với một tiêu chuẩn cao hơn
- Những nhược điểm của interface kiểu được sinh ra là rất rõ ràng:
- luôn có một bước sinh mã
- đầu ra được sinh ra rất phức tạp
- mã được sinh ra không phải lúc nào cũng đúng, tùy thuộc vào thiết lập ban đầu
Sự xuất hiện của RPC và tRPC
- RPC không phải là khái niệm mới, nhưng đã trở nên phổ biến trong hệ sinh thái React nhờ tRPC
- Theo trải nghiệm trong 6 tháng với vai trò solo developer trên một ứng dụng 80 nghìn dòng mã, việc gọi hàm ở backend để đọc và ghi dữ liệu giống như một sự khai sáng
- Tôi chưa từng cảm thấy năng suất cao hơn thế ở cả hai phía của stack dùng TypeScript
- Cá nhân tôi chỉ từng cảm thấy mức năng suất tương tự trước đó trong các kiến trúc GraphQL có kiểu (được sinh ra) vài năm trước
- Suốt năm 2023, tôi không thể tưởng tượng có gì tốt hơn tRPC
- Việc gọi hàm ở backend để đọc và ghi dữ liệu tạo cảm giác mang tính cách mạng
- Nhưng đó đã là tất cả những gì tôi cần chưa? Chưa
Bước đột phá của Server Components và Server Actions
- Với tôi, bước đột phá thực sự đến vào năm 2024 với Server Components và Server Actions
- Chúng không chỉ gọi server mà còn giúp thu hẹp khoảng cách với server bằng cách cho phép triển khai và thực thi mã ở phía bên kia
- Server Components cho phép chạy React component trên server, từ đó có thể truy cập trực tiếp vào nguồn dữ liệu (ví dụ: cơ sở dữ liệu) trước khi trả về UI bằng JSX
- Server Actions tạo ra các HTTP API endpoint ở bên dưới để có thể gọi và thực thi hàm tương tự như remote procedure call
- Server Components và Server Actions đang biến React thành một framework full-stack
- Đây là thời điểm đầy hứng khởi để chuyển frontend sang một môi trường full-stack
React hỗ trợ Server Components và Server Actions
- Bản thân React chỉ cung cấp các thành phần nền tảng và đặc tả cho Server Components và Server Actions
- Các meta-framework xây dựng trên React có thể lấp đầy khoảng trống bằng bộ bundler diễn giải các chỉ thị giữa client và server
- Next.js đang dẫn đầu trong việc triển khai Server Components và Server Actions
- Trước đây Next.js đã hỗ trợ render phía server (SSR), nhưng giờ với Server Components và Server Actions, lập trình viên có thể truy cập các tài nguyên phía server như cơ sở dữ liệu và hàng đợi thông điệp
Khởi đầu của phát triển full-stack
- Phát triển full-stack với React hiện mới chỉ ở giai đoạn bắt đầu
- Khi lập trình viên bắt đầu truy cập trực tiếp vào cơ sở dữ liệu thông qua Server Components và Server Actions, sẽ cần một quá trình chế ngự độ phức tạp vượt ra ngoài các ứng dụng CRUD đơn giản
- Thông qua đào tạo bài bản, các lập trình viên frontend sẽ sớm làm chủ việc triển khai kiến trúc backend bằng cách sử dụng các layer, design pattern và best practice
- Nói thật thì chẳng ai muốn thấy các lời gọi hàm ORM ngay bên trong React component cả
Kỳ vọng về một sự chuyển dịch mô hình
- Tôi rất hào hứng với sự chuyển dịch mô hình này
- Một kỷ nguyên mới đang mở ra, nơi các lập trình viên React sẽ xây dựng các tính năng theo chiều dọc từ UI xuống tận cơ sở dữ liệu
8 bình luận
Đã lo hết cả full-stack rồi mà
Nếu xét đến khả năng tương thích với ngôn ngữ khác như trong phát triển ứng dụng, mình nghĩ tRPC không phải là lựa chọn quá tốt. 😅
Mình nghĩ GraphQL là phương án tốt nhất.
Tôi cho rằng server action của Next.js có vấn đề là công khai các API endpoint ngẫu nhiên mà lập trình viên không thể kiểm soát, và đây là một điểm cực kỳ dễ bị tấn công.
Bạn có thể cho biết đó là lỗ hổng nào không? Khi tìm kiếm thì có thấy nói về lỗ hổng SSRF, nhưng tôi không chắc có đúng không. Tôi đang học Next.js nên tò mò muốn hỏi.
Ngay từ đầu, ý đồ của những người thúc đẩy SPA là gì nhỉ? Dù chắc chắn tốt hơn rất nhiều so với thời còn thao tác DOM bằng jquery, nhưng có vẻ như các khái niệm cần thiết cho thiết kế và phát triển backend/frontend không hề biến mất mà chỉ đổi chỗ. Chỉ riêng routing thôi cũng đã chuyển từ server sang client, rồi vì trào lưu server-side rendering mà lại đang muốn chuyển ngược về server.
Tôi cũng nghi ngờ rằng 3 năm nữa liệu các học viện hay khóa học lập trình còn dạy React kiểu SPA hay không
Chẳng phải ưu điểm lớn nhất là cảm giác chuyển trang mượt mà sao (vào thời đó)
Phần cuối của bài viết gốc kết lại bằng việc quảng bá cho khóa học đào tạo phát triển web full-stack The Road to Next mà tác giả dự định khai giảng ^^;