I am very used to the approach where SSR meant that the page got a full refresh and received a full HTML from the server, where it gets rendered with razor/pub/other depending on the backend stack. So every time the user would click on the navigation links, it would just send a request to the server and the whole page would refresh, receiving a new HTML. That is the traditional SSR which I understand.
With SPA however, we have for example react or angular, where we receive almost empty HTML on the beginning and then the JS so that the whole app gets initialized on the client side. We can then have some REST API to get json data and render views on the frontend (client side routing and rendering) without any page refresh. We don't even need any server really.
Now, what I have a problem understanding is how SSR (such as next.js) works with react.
From what I am reading, the first request returns full HTML+CSS (which helps with SEO etc - I get that), but what happens later? What happens after that first/initial request? Does the whole react app initialize in the browser and then it just behaves EXACTLY as if it was a normal SPA (meaning we have client side routing and rendering from now on, without any need to make requests to that server)? In other words, does next.js still make any server requests after the initial one, or does it act like a typical SPA with CRA from now on?
I spent lots of time reading but all the articles mainly focus on the initial request and SEO and time to first byte, paint etc. and I am simply trying to understand why its called SSR since it seems to work different than the traditional SSR which I described on the beginning.
does next.js still make any server requests after the initial one, or does it act like a typical SPA with CRA from now on?
You got it right. The first (initial) request is handled by the server and after that the frontend handles the routing (at least in the case of Next.js).
If you want to see an example OpenCollective is built with Next.js. Try playing around with it and see the Network tab in the DevTools.
I am simply trying to understand why its called SSR since it seems to work different than the traditional SSR which I described on the beginning.
It is called SSR because the app is effectively being rendered on the server. The fact that frontend routing takes over after the initial render doesn't remove the fact that the server did the work of rendering the app as oppose to the user machine.
That's Not all the things that happen with Next.js, In Next.js You can build something called Hybrid apps.
In traditional SSR, all of your client requests get handled by the server. Every request goes to the server and gets responses.
In classic CSR with something like React, as you said, all the things happens in the browser via the client-side javascript.
But, in Next.js you can define three different approaches (mainly two according to the docs) for pages to get delivered.
based on the app needs and requirements, you can serve a couple of pages in pure traditional SSR mode, a couple of them in classic CSR mode, and a couple of in SSR mode via dynamic data that get fetched and rendered into the pages on the fly.
these features bring lots of flexibility to design a web-app that behaves perfectly in every different scenario that is needed.
Related
There are many ways to fetch data from apis in next.js.
getServerSideProps,getStaticPaths,getStaticProps,Incremental Static
Regeneration and client side rendering.
If I have to make requests to backend on the change of any state, can I use other methods of data fetching apart from client side rendering?
I am from React.js background where client side rendering is mostly used.
What are the specific use cases of different fetching methods?
Can I always use client side rendering only in Next.js also.
Server-side rendering is good for SEO. You can check this, if you view the page source of a react app you won't get much HTML, this is the problem next.js fixes. With getServerSideProps and getStaticProps you can make calls to your API(such as DB back-end) to get your data and server-side render your page. Now when you have to update state of your page you can simply fetch as you normally would, since it doesn't matter because it is triggered by some action anyway.
Can I always use client side rendering only in next.js also.
Yes you can, but you want search engines to index your site and/or display relevant data such as review and preview text, right?
If I have to make requests to backend on the change of any state, Can I use other methods of data fetching apart from client side rendering
When the state is changed you will fetch new information just like you normally did in react.
GetServerSideProps and GetStaticProps only run once when the user visits the page(or reloads etc ofc). You can get the latest data by fetching and updating state with that.
Next.js is much more than react, it can be used as a back-end too i.e. creating APIs for saving data to db, handle authentication etc. Explaining it all is beyond the scope of this answer.
As for when to use what you can read more about it here, or search about it I'm sure SO has many questions about this.
One situation where you can be forced to use next.js features is when you want to consume an old API that does not implement CORS, here you can't control the dev on the other side so you can create an API on next.js which you fetch on your react code like: /getinfo. Now write code on your back-end to handle this which will delegate the result of that third-party API back to you, pretty neat right
I know about ssr (server side rendering) in Vue, such as nuxt. It grabs data in serverPrefetch() function and renders content on server side, only after then the request is returning data to user and he is starting to download app.js.
But can we start loading data from backend immediatelly after user request, not waiting for download of vue script, and not stalling request before all data is loaded. So user is downloading app.js, while our server is doing work with sql requests and forming response.
As long as Nuxt is concerned - you can find a pretty good summary on the SSR (and client-side) options available in the following article. Spoiler alert - I think SSR is still the best shot with what you are trying to achieve. In the Nuxt world - NuxtServerInit and AsyncData are the men for the job.
Say you decided to stay away from SSR - what options do you have?
Have some super lightweight js loaded and ran before the Vue application that would fetch the data and share it with the app somehow (e.g. - saving it to the local storage). Would it really provide a speed advantage? I really doubt it, especially considering how fast the Vue app could load when cached in the client browser.
Dump the backend data into the server response itself. I mean, you could prefetch all the heavy stuff and stick it into your page as a json encoded object. That would save some time for initial requests for sure, but then - how large is that data chunk? Wouldn't it make the initial load too heavy, destroying the initial purpose? Those are the questions you should answer based on your particular use case.
I created an application that some of my pages are rendered on server side, but I realized that something was not going well. I can see that the requested pages rendered as usual on my browser; but I sent a CURL request to my page and the response was stored in a file, mypage.htm, then I opened the mypage.htm, the page was not rendered as expected.
The first reason of why I have chosen SSR is caching the responses into a frontier layer like Nginx or Varnish.
I'd like to know about that does Nextjs provide fully server side rendered pages or does it just joking and playing its role in the industry like an Holy wood star as "Hey I render things on server Side, but things aren't rendered on server side actually!" or i missed something in detail!
Next.js supports 3 methods,
SSR (when you define getInitialProps)
SSG - static site generation, created a static page at BUILD time (when you define getStaticProps)
Static site Re-Generation, creates a static page at BUILD time, and when the data is changes RE generate the static page again (when you define getStaticProps + revalidate field in it)
For more info read this
I am kind of in cross roads in the process of understanding the basic difference between Client Side Rendering and Server Side Rendering. After doing significant amount of research, here is my understanding
When we render on to the server it means:
You have a local server say Apache Tomcat, You host a web application
by clicking the run on server, It renders your HTML on the server.
I understand this completely. Now here starts my confusion:
Client Side Rendering?????
You host a web application without a local server???
I might be wrong, but this is what the conclusion it is taking me too.
I know, ReactJS does both serverSide Rendering and Client Side Rendering. However, I am not getting the basic difference between both these renderings.
Any help would be highly appreciated.
"Rendering" in this context means "Assembling the document from various component parts".
With server side rendering, you would do all that on the server and then send a complete HTML document to the browser.
This is:
Traditional
Robust
Search engine friendly
With client side rendering you would use client side JavaScript to load a template and some data (using multiple requests) and then put them together in the browser to form a DOM and create a page.
This can provide performance benefits for subsequent pages (since less data is being fetched for them) although the cost of bootstrapping the initial page is usually higher.
Lack of robustness and search engine friendliness can be compensated for by combining the techniques. A new request for a page (any page) uses server side rendering, but following links trigger JavaScript to involve Ajax, the History API, and client side rendering. If you use server side JavaScript, you can reuse some of the same code for both (this is sometimes called Isomorphic JS).
I use Parse BaaS
I have a React based web app created by this generator (which uses the latest ES syntax and BabelJS)
I'm new to React, it took me a while to configure and get things working (on my machine and on my mind).
One of the greatest benefits of React is the semi-transparent server side rendering.
I wonder how (and if) I can check the user login status while rendering the page on the server side.
For now I'm not able to achieve it, and React is telling me that this is bad:
Warning: React attempted to reuse markup in a container but the checksum was invalid. This generally means that you are using server rendering and the markup generated on the server was not what the client was expecting. React injected new markup to compensate which works but you have lost many of the benefits of server rendering. Instead, figure out why the markup being generated is different on the client or server