I learnt that getServerSideProps will generate the whole page on each request, instead of doing it at the time of build. Does getServerSideProps generates the whole page at each request at the server? or it just generates the whole page at the server IF the data has been changed in the database?
If it does generates a whole page, each request at the server, Isn't vanilla react JS doing the same thing?
(Except the fact that it is generating the page on the client's end but it is calling the APIs independent of the fact if the data has been changed or not.)
getServerSideProps pre-renders the page on every request. That means you the page is sent with all the data filled in. That is very different from sending an empty page and making API calls.
Also there is an option to cache by setting cache-headers in response, so if the data remains the same a particular browser can cache it and the API calls are not made again.
As long as props which is sent to page has some space to change, SSR has to occur every request. getServerSideProps is always depending on the request from client unless caching is activated.
Related
Let’s say a Single Page Application (SPA) written in angular or vuejs for example loads 3 components on a page and each component calls a different backend api.
Then, a user refreshes the page. The same 3 calls are made but this time, the backend returns 304 for each of them.
The SPA components are just js code. So with each call to the backend they expect data returned. When a 304 is returned. There’s no data. However things function fine...
There’s some magic I don’t understand. Can someone help me understand this?
The server will only return a 304 response with no content if the client includes an If-Modified-Since or If-None-Match request header. Without those headers the server will always respond with the full content. There's now two possibilities:
The Javascript code itself adds those headers because it still has the data somewhere, to explicitly allow empty responses. The Javascript code may have stored the data in local storage.
The browser includes those headers because it still has an implicit cache of the data, and if the server returns 304, it transparently returns the cached data to the Javascript request. I'm not sure whether browsers actually do this; I believe not, but it's a possibility.
It's more likely the Javascript is managing a local cache, perhaps with a web worker.
Can use Browsersync to call only once a backend server?
Currently I have a web application that displays a graph online of statistics, that it does is make calls every 1 second to backend for AJAX request.
The problem is that every time the web application opens, multiply calls to the backend is produce.
I would like to call only once at the backend, and update in all client who have opened a connection in the web application.
Looking at the documentation Browsersync I see do that, but only for static pages. Nowhere do I see where to use it to combine with called Ajax that refresh the DOM automatically depending on the response of Ajax.
Thanks in advance for your help.
I have an React Redux server rendered application that runs well.
When I go on different page, I measured some server response time:
On my /singin page, I got the response in 60ms. Good.
On my /user page (require an authentication) I got the response in 300ms. because the server has to prefetch the current user session and the current user by asking an API to know if the user has access to this page
On my /user/graph page. I got the response in 600ms. because the server has to prefetch the current user session, the current user and the graph data by asking an API.
The main issue is that I can't parallelize all these requests.
Here is the server flow:
Receive page request for /user/graph
Fetch /api/user/session and /api/user/me in parallel
Do the route matching with React-Router (it needs to know if the user is authenticated or not to redirect him)
At this point, the server knows the components that will be rendered. Foreach of them, it fetches the needed data in parallel. That means Fetch /api/graph, /api/graphConstants1, /api/graphConstants2, etc..
React rendering
Here are my questions:
What is the best practice?
How could I decrease this initial rendering time due to prefetching requests?
Should I do big request (like /api/graph) only on the client? But what is the purpose of server rendering then?
Should I ask my api team to create a custom super method only for the rendering server to retrieve all data in one request?
Here is the server flow:
Receive page request for /user/graph
Fetch /api/user/session and /api/user/me in parallel
Do the route matching with React-Router (it needs to know if the user is authenticated or not to redirect him)
At this point, the server knows the components that will be rendered. Foreach of them, it fetches the needed data in parallel. That means Fetch /api/graph, /api/graphConstants1, /api/graphConstants2, etc..
React rendering
This looks perfect to me, this is how a Microservices based architecture should behave.
As stated by you, most of the API calls are being made in parallel, so there is not much to worry about the latency between successive API calls.
The main issue is that I can't parallelize all these request.
However, you could ask the API team to provide an umbrella API for the desired Microservices. In that scenario the API team needs to handle the processing in parallel or mutithreads.
Fetch /api/user/session and /api/user/me in parallel
Looks like, you are calling /api/user/session to validate the users' session. However, shouldn't you leverage caching for /api/user/me.
I guess /api/user/me this is a GET request, one approach to reduce this sort of calls. The data being sent by this API could easily be sent the signin API, if signin is successful and cache the data.
On any update to user data, i.e. on any POST, PUT, DELETE call, the exiting cached data can be purged, and the APIs, can return the latest state of the user which will be used to warm up the cache.
PS: This sort of decision can/must not be made on a StackOverflow answer but needs in depth discussion and agreement between the API provider and consumer.
I have the following situation: A frontend server redirects with HTTP Post to a backend server. At entry of the backend server, I execute some PHP code before the page has been loaded. I would like to send a notification, at this point, back to the frontend server that the redirection was successful.
The entry page on the backend uses the Post/Redirect/Get pattern to prevent browser form resubmission alert, so after this the PHP code does a HTTP Get request to itself. After the Get header has been sent, the notification back to the frontend should not be sent from PHP code, to prevent sending it each time the page is refreshed on the backend server.
Can this be done from PHP code, or do I have to wait until the document has loaded and then use an Ajax call from Javascript and somehow check that the notification is only sent once (the first time)?
After all processing was complete, your backend server could redirect back to the front-end server, with any custom data to be passed either as POST vars or url parameters in a GET. The front end server would then handle the UI display of this custom data.
But I think thats a sloppy design... systems should be segregated not just for security reasons, but also for scalability. The best design IMHO would be to make bi-directional AJAX calls between your "frontend" web server to a firewalled, "backend" system.
Whenever I make a single-page HTML5 app, I generally have the following procedure:
The user requests a page from the server, and the server responds
with the appropriate html.
Once the page returns, Javascript on the client-side requests documents from the server (the current user, requested docs, etc.)
The client waits for yet another response before rendering, often resulting in a 'flicker' or necessitating a loading icon.
Are there any strategies for preloading the initial document requests and somehow attaching them -- a javascript object or array -- to the initial page response?