Về việc phục vụ SEO khi dùng SPA thì mình thấy có vài giải pháp là viết riêng 1 render-server phục vụ cho con Google bot (angular có support việc này…)
vậy có nghĩa là khi site đó được tìm thấy trên search engine và khi người dùng click vào sẽ được redirect đến trang sử dụng client side render đúng k ông?
Ứng dụng của bác đã có sẵn chưa nhỉ. Nếu đang có rồi mà apply NextJS vào chỉ để phục vụ SEO thì cá nhân mình thấy khá tốn resource.
tốn cả tài nguyên server nữa, mình đang tìm slution thỏa cả 2 thôi 
Đúng rồi á ông, server nó sẽ check request nếu nó là Google crawler thì mình sẽ route nó tới server render riêng á. Trong browser cũng có option chỉnh request là Google crawler để mình test tính năng này.
Lắp thêm 1 server hoặc sử dụng dịch vụ third-party chỉ để xử lý giao diện mình nghĩ không phải giải pháp tối ưu lắm, trong khi server chính monitor CPU chạy chưa đến 50%
thank ông, slution này tôi chưa nghĩ tới, cũng là 1 giải pháp hay, nó vẫn tốn server nhưng server này chỉ phục vụ cho con bot thôi nên khả năng tèo là không thể 
Và mình cũng không cần UI đẹp cho cái này, chỉ cần đủ nội dung cần SEO là được
Nếu server chính dùng ít thì mình nghiên cứu để phần code server render vào chung server này luôn xem sao ông. (Dùng third party thì tốn money nên nó là 1 option thôi chứ mình cũng ko chuộng lắm)
thì mình đã nói nó sinh ra ko phải để render ở server mà là render ở client, nếu bạn render tại client thì hiệu suất sẽ tốt hơn, còn cái render ở server là người ta đưa thêm vào thôi, bạn đọc mấy dòng cuối mình có nói mà, nếu chỉ render ở server thì chả ai sài mấy cái framework kia làm gì, tuy nhiên bạn thử nghĩ nếu 1 backend mà cung cấp api cho cả web, mobile, hoặc các thiết bị khác thì response về nguyên 1 trang web đc ko? cần phải đưa ra những tình huống cụ thể những yêu cầu cụ thể chứ nói khơi khơi thì nó vô vàn lắm
nếu họ request đến quá nhiều thì liệu con nuxt server này có lăn ra ngủm hay k >> cái này server nào chả ngủm
nếu reactjs thuần hoặc vuejs thuần thì khi deploy mình có thể đẩy nó thành static site, khi đó thì k sợ ngỏm >> cái này mình chưa hiểu ý của bạn, nếu bạn muốn 1 server static thì cần gì render gì nhỉ? , việc render diễn ra khi bạn cần nội dung động, chứ tĩnh thì bạn sài cdn như cloudflare rồi cache lại là xong
Đương nhiên là được, sao lại không nhỉ? điển hình là WordPress, WordPress return thẳng HTML/CSS cho browser nhưng vẫn có controller RESTful phục vụ mobile bình thường, odoo cũng tương tự nó render giao diện ở server muốn thành web service thì cài thêm module web service, …
Đoạn này có gì khó hiểu đâu 
reactJS thuần túy khi chạy lệnh npm run build sản phẩm cuối cùng tạo ra là HTML/CSS/JS thuần túy thì nó chính là nội dung tĩnh rồi, hơn nữa nó có thể được đặt trong bất kỳ web server nào cũng được, điển hình là deploy react lên firebase hosting (chuyên chứa nội dung tĩnh). Khi user truy cập web lần đầu sẽ download file index.html đầu tiên, sau đó download tiếp JS, CSS mà file index này reference, cuối cùng mới fetch data bằng cách tạo http request đến server bằng axios, react query hay bất kỳ thư viện tạo http request (đây này chính là cái mà bạn gọi là dynamic content đấy)
Bạn hơi nóng vội và chưa hiểu vấn đề thì phải. Theo mình đọc cuộc trò chuyện nãy giời thì nội dung như này:
Web thương mại (bán hàng, quảng cáo, …) có user là người tiêu dùng (không phải nhân viên nội bộ của cty) cần SEO tốt nên chọn cách render giao diện phía server vì:
+để bot google dễ crawl (môi trường SEO cạnh tranh khóc liệt)
+Chúng tôi sẽ bỏ tiền ra thuê server khoẻ để render UI, laptop khách hàng không phải tốn điện để render UI nữa.
Bài viết này tạm gác công nghệ client side rendering qua một bên vì không đúng use case này vì khi nói đến nói đến SSR thì các framework đều có module support việc này kiểu như:
+Spring boot đã có thymeleaf rồi tại sao không nó luôn mà tăng thêm 1 server nextjs để render giao diện làm gì?
+Blade trong laravel sao không dùng mà lại thêm nextjs nữa làm gì?
+tương tự nếu backend viết bằng expressJS (nodejs) cũng có thể return về HTML luôn, tại sao làm triển khai bộ đôi NextJS/ExpressJS làm gì?
Chủ topic cũng nói rõ chỉ quan tâm đến vấn đề hiệu năng của máy chủ, tiết kiệm chi phí vận hành còn việc team frontend làm trước team backend, chia nhỏ công việc v,v … thuộc vấn đề teamwork, quản lý nhân sự, … rồi không liên quan câu hỏi.
Mình thấy đây là một hỏi khá hay, mong cao nhân vào giải đáp. Có thể có nhiều options, chọn là do sở thích hay Nextjs vừa có SSR vừa có CSR, mà CSR làm bằng JQuery rất cực 
?? bạn phân biệt được 1 server response về static file với 1 server response về nội dung dynamic ko vậy, với server static ko cần quá trình router, xử lý, ghép nối nội dung để tạo thành response trả về, nên nó chạy rất nhanh, nếu bạn muốn tôi có thể tạo ra 2 server 1 cái response trực tiếp file binary từ ổ cứng, và 1 cái phải đi vòng vèo qua controller rồi tách ghép dữ liệu trên các template ( hoặc tạo 1 string html) cho bạn xem cái nào nhanh hơn? , cùng là trả về nhưng nó khác nhau về cách xử lý bạn nói vậy, thì cơm với gạo trước sau gì cũng ăn vào bụng, vậy nấu làm gì??
Có vẻ như bạn chưa hiểu react sau khi build nó sẽ hoạt động thế nào, SPA, CSR khác gì với SSR. Sản phẩm sau cùng khi bạn chạy lệnh npm run build không phải gọi là static file thì gọi là gì? có phải chỉ là file css,js, html thuần túy không? không lẽ là scss, ts, xhtml?
Giờ mới lòi ra thanh niên chưa nắm được mô hình client-server trong mạng internet. Bạn luôn nhắc đến từ render nhưng bạn có phân biệt được reactjs render phía client hay phía server không? nextjs render ở vị trí nào? cái nào render được cả 2 vị trí?
bạn vui lòng đọc lại giải thích web SPA tại đây
Đoạn này lạc đề không liên quan. Chủ topic đang bàn luận về SSR thì bạn lái sang CSR. giờ đang nói CSR lại chuyển lại SSR.
Lý thuyết bạn nắm chắc, ở đây không ai nói bạn sai, nhưng mọi người muốn bàn luận chuyện thực tế, cái mà mọi người muốn nghe là giải pháp, hiệu năng, chi phí.
Đọc cái chủ đề này thì thấy ông chủ topic tick vào nút Solution câu trả lời không giải đáp trực tiếp vấn đề của anh ta. Như vậy, có thể hiểu rẳng có khả năng là những người tham gia vào thảo luận ở đây đang tham gia vào một cuộc… ông nói gà bà nói vịt do không chắc đang thảo luận là gì, mà cái này lỗi là cách đặt vấn đề của chủ đề mơ hồ, không phải lỗi người tham gia. Mình cũng góp phần vào blah blah gà vịt này cho vui vậy:
Hiện nay JavaScript và những người anh em/ họ hàng hệ phái của nó như TypeScript, CoffeeScript, Nodejs, các framework/ libarary như Emberjs chạy trên Dạy Nhau Học này, Reactjs, Angular, Vue, Jquery, Axios, Underscore, Express, Nuxt,… liệt kê không xuể luôn và bọn này có cái chạy ở client, có cái ở server, có cái dường như là có cả 2 bên. Và rồi vì đều cần dùng đến các thứ như NPM, Yarn, GULP,… liên quan mật thiết với Nodejs. Lại thêm nhiều “code sĩ” ngày nay vội vàng bắt tay vào học lập trình web nhưng chưa từng chịu “nằm xem hoạt hình” về mấy thứ dạng “How it works…” như một đứa trẻ để có cái nhìn tinh khôi, đẹp đẽ về thế giới này, sẽ làm cho vấn đề rắc rối thêm lên.
Rồi lại thêm sự “nấu lẩu” vô nữa giữa các ngôn ngữ lập trình, bộ công cụ phụ trợ nên có những cái mà “người cũ, già nghề” nếu ít cập nhật kiến thức thì khó có thể hiểu được thế quái nào giờ đây có những trang web dường như không có server-side script mà vẫn có thể tương tác nội dung động được, các chức năng đăng nhập, điền form đều ngọt ngào. Điều này trước kia những ai từng lập trình dính dáng đến Flash, Silverlight, ActiveX còn có thể hình dung, còn chưa đụng mấy thứ này là… ngáo Husky ngay và luôn.
Lại thêm có những quái kiệt chơi rất đau đầu nữa đó là cái JavaScript ở client còn có khả năng là trình biên dịch để tải code từ file text từ nguồn nào đó về và biên dịch nó chạy được trên trình duyệt cứ như trình duyệt là VMWare hay Hyper-V không bằng… khiến cho client, server rối beng tùng phèo cả lên, ranh giới mong manh, trộn lẫn vào nhau hoặc đôi lúc chỉ là đặt tên đọc lên nghe lẫn lộn, chứ thực sự nếu phải ôm full-stack và vẽ sơ đồ lên để soi thì thấy “à há, khỉ thật, chỉ là có quá nhiều… nhãn hiệu kêu loảng xoảng mà thôi”.
Cho nên, giờ thì xin đầu voi đuôi chuột một chút: chủ topic không cần đến Nextjs nếu back-end (nên dùng server-side scripting language cho đúng bản chất hơn, back-end là từ của marketing hơn là kỹ thuật) không viết bằng JS (hoặc TypeScript, CoffeeScript, Dart, ClojureScript…), không sử dụng Nodejs (hoặc 1 cái tương đương ).
Trong thực tế theo mình biết một cách hồ đồ là có những đơn vị mà sản phẩm website của họ được tạo nên bởi team lắp ghép lộn xộn, làm việc không ăn ý nhau. Bên phía lập trình front-end thì cũng chỉ biết là kết nối tới API để lấy/ cất các file JSON mà họ không có kiến thức về web thuở ban đầu. Còn bên back-end cũng thế, họ không tự tin rằng với ngôn ngữ mà họ đang viết code họ dễ dàng tạo ra Web API cho bên kia mà không cần dính dáng gì đến Nodejs và hoặc 1 framework hay thư viện JavaScript nào hết.
Đây chính là vấn đề mà chủ topic bị hai cái nhóm đó làm cho điên cuồng hoặc tự him đang phân mảnh vì mơ hồ không rõ, cứ băn khoăn suy nghĩ rằng phải có Nextjs thì mới thuận tiện cho bên Front-end mà không hiểu rằng cần quái gì cái này. Nếu là mình trong trường hợp này, mình mời 2 ông đứng đầu 2 team đó ra và yêu cầu đổi vai trò cho nhau vài ngày là ra vấn đề ngay (điều ông back-end nhảy qua cầm team front-end & ngược lại).
Anh em nào ở đây mà từng phải ôm full-stack sẽ dễ dàng nhìn thấy nếu dùng thêm Nextjs khi server-side không dùng JavaScript/ hoặc Nodejs. Lúc này đây, sẽ xuất hiện 2 server script interpreter/ complier trong 1 web server (chưa kể thêm đống database server, cache server) quả là rách việc. Cần quái gì ông nội JavaScript server-side ở đây chứ? Chỉ là trả về mấy cái file JSON thôi mà? Nếu bọn kia cứ thích là server-side rendering gì đó thì thay vì print ra JSON, ta print ra HTML, cũng bấy nhiêu chuyện. Có phải điên không nếu giờ đây lại phải bê thêm cái Node vào? Trong khi ta đang viết Perl, C#, PHP, Python, Java, Go, Ruby thì còn đèo bòng thằng Node lên nữa, điên quá điên, mất năng lượng vô ích. Ta có đủ tự tin để cấu hình nó không? Không là cái chắc! Dẹp nó đi là vừa, dành thời gian đi… đấm vào mặt mấy thằng Reactjs gì đó gà mờ phát cho sướng tay 
(Xin lưu ý, ở đây chỉ giới hạn lập trình web thôi nhé, bởi JS hiện nay còn áp dụng vào thứ khác không phải lập trình web nữa, đi xa đến vậy thì nguy cơ là vỡ chủ đề).
nếu mình nhớ không nhầm thì NextJS có thể config cho request đầu tiên là SSR, sau đó các request tiếp theo sẽ là CSR.
tức là khi mình nhập URL vào (tương tự như khi bot của search engines vào crawl website) NextJS sẽ thực hiện SSR và trả về luôn nội dung đầy đủ. Sau đó mình thao tác chuyển trang bằng phía react như dùng router thì sẽ là CSR.
Ý bạn có phải cái này không? Sử dụng thư viện react router DOM với nextJS framework?
trước mình làm nextJS thì dùng luôn cái next/link của nó thôi.
còn cái mà mình nói ở trên kia thì nó là cái này đây:
À cái này thì mình có sử dụng rồi, router này vẫn là SSR mà bạn?
như docs có nói đó, request bằng next/link sẽ là CSR đó, chỉ là cần server để xử lý phần getServerSideProps thôi.
Đối với ý này thì cũng giống như ý kiến của ông @Michael trên, đó là vẫn phải start 1 con service để SSR cho thằng gg bot nó scan, còn người dùng request tới sẽ là static site, cách này giải quyết được 50% vấn đề. đây cũng là cách mà tôi thấy khả dĩ nhất hiện tại
Xin phép được xưng hô là ông/bác nhé, dù sao đây cũng là internet, xưng hô thế này cho thân thiện
Thật ra tôi cũng không biết nói gì với những điều ông chia sẽ, nếu phải làm như @Michael thì tôi cũng chỉ định cho chính con server API đó đảm nhận luôn việc SSR cho con bot gg (đáp ứng được tiêu chí thứ nhất là chi phí server), đương nhiên tôi chỉ cho phép nó render những nội dung tôi cần SEO thôi, chứ k phải là nguyên site map vì điều đó là k cần thiết.
Đối với người dùng thì vẫn sẽ truy cập vào domain chính và tương tác trực tiếp với static site (đáp ứng được tiêu chí 2 là CSR). đương nhiên những user tìm thấy site trên google thì sẽ được redirect về domain chính (điều kiện vẫn là phân biệt được dâu là con bot đâu là con người để redirect).
Tôi thấy giải pháp trên cũng là 1 giải pháp khả dĩ rồi
Ông dân IT mà hành văn như nhà văn vậy 
Xin lỗi các bác vì đã đào mộ :D,
E chia sẻ tý về việc tại sao lại dùng Nextjs theo quan điểm cá nhân :D.
Ngày xưa để viết 1 trang web thì cách chúng ta hay làm là viết toàn bộ css, html và để server return về như blade của laravel, thymeleaf của springboot,… hay gọi tạm là SSR đó. Ưu điểm thì tối ưu SEO là đúng rồi, tuy nhiên nhược điểm viết khá cực, xong việc viết thêm script để web thành web application cũng cực không kém, (chắc các bác còn nhớ JQuery)…
Tuy nhiên sự xuất hiện CSR như angular, react, vue đã giúp những người lười như e viết nhanh hơn, cú pháp khá đơn giản, hiệu suất thì ok vì client render hết, tách biệt server và client và server api, tuy nhiên nhược điểm lại là SEO
Vậy tạo sao lại sinh ra nextjs, nuxtjs => theo quan điểm cá nhân của e thì nó kết hợp đc cả 2 cái ưu điểm của cách viết cũ và mới, khi mà e vẫn muốn code theo phong cách React, Vue nhưng vẫn muốn trang web return ra hết HTML (next/nuxt sẽ compile ra còn CSR chỉ compile ra js script) để search engine có thể đọc được. Khi lựa chọn Next/Nuxt hay 1 framework nào tương tự thì thường sẽ không quan tâm đến performance cũng như phải tốn thêm server này server nọ, vì nó giải quyết được nhiều thứ hơn là việc chỉ chăm chăm vào performance. Vậy nên hãy tuỳ vào nhu cầu sử dụng, ưu nhược nó mang lại mà lựa chọn SSR hay CSR nhé các bác. Thân!
Nhưng ngoài thực tế việc chọn công nghệ phụ thuộc vào ông leader đang biết công nghệ nào 
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?
