|
He's not wrong in some cases. If bandwidth cost from Next->Client exceeds cost from DataSource->Client, then you want to opt out of SSR, to avoid DataSource->Next->Client in favor of direct DataSource->Client during CSR. Example: Next deployed to AWS (metered bandwidth), with DataSource deployed to colocation (unmetered bandwidth). Page fetches 1GB CSV from DataSource in order to render an HTML Table. In this case, you likely prefer the client to fetch directly from DataSource and render the HTML table during CSR. An exception might be if you care about the table for SEO purposes (e.g. structured data) – but in that case, you should find a way to fetch the first 10 rows instead of 1GB. It's a fairly niche use-case, though, and it's easy to opt out of SSR for specific code/requests (check if window is defined) or pages (use Next getServerProps vs. getStaticProps). As an aside... this convoluted scenario highlights one criticism I have with Next.js: It is NOT a friendly mental model for junior engineers. You cannot write a robust Next app without a thorough understanding of the HTTP request lifecycle, network architectures, closures, database/HTTP pools, caching, cookies, etc. If you stay within the lines, you can avoid worrying about most of this stuff, but it's impossible to fully grok Next without a strong background in web fundamentals. If I were advising a beginner on the best stack for practicing React, I would suggest starting with create-react-app, even though I think Next is ultimately the best production framework. |