Nextjs và server-render?

#21

Đọ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 :smiley:

(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ủ đề).

1 Like
#22

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.

1 Like
#23

Ý bạn có phải cái này không? Sử dụng thư viện react router DOM với nextJS framework?

#24

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:

image
image719×421 16.2 KB

2 Likes
#25

À cái này thì mình có sử dụng rồi, router này vẫn là SSR mà bạn?

#26

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.

2 Likes
#27
  • Sorry mọi người, tôi là chủ topic đây, bị mất acc nên reg lại acc khác vào confirm là bác này nói đúng ý tôi này.
  • Hiện tại tôi có vài site reactjs, build static file và deploy thẳng lên s3 static site.
    và như đã nói, CRS khiến cho thằng gg k thể đọc được nội dung khi tôi get từ API về và render DOM ra ngoài (maybe vẫn được nhưng những api call quá lâu thì sẽ bị miss). ưu điểm của việc đẩy thằng lên s3 static site như này thì quá rõ ràng là tiết kiệm chi phí và load source nhanh, còn vụ api ngỏm thì thằng static site này sống làm gì thì rõ ràng nó vẫn vẫn sống để render được những component mà k cần gọi api, đại loại thế.
  • Tại sao tôi lại đề cập đến Nextjs ở trên? -> vì tôi đã research tìm kiếm giải pháp và đa số là mọi người suggest xài nó vì Nextjs có cú pháp giống reactjs, dễ chuyển đổi từ react sang hơn là chuyển sang 1 nền
    tảng khác (ý của họ tôi hiểu là chuyển từ CSR sang SSR, nhưng làm như thế là phạm phải điều kiện phải là CSR và phục vụ tốt cho SEO), và theo tôi xem qua (chưa xem hết được vì vẫn đang tìm giải pháp) thì thằng này đến cuối vẫn là SSR, vẫn tốn 1 con server để deploy nó lên và ngồi hóng request từ client để response.

Đố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

#28

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 :smile:

#29

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!

3 Likes
#30

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 :rofl:

83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?