i have an ssr quasar app , when i lunch the website for the first time in chrome developer mode i see that the server return an html document.
but when i navigate to another page the server return only js scripts soo not rendering at the server side , it behave like a spa after the first page,
Is there any parameters i can change to render all the page at the server side ?
i read all the documentation regarding quasar ssr mode but couldn't find anything
and here is how the ssr config object looks like inside quasar.config.js
ssr: {
pwa: false,
prodPort: 3000, //
middlewares: [
'render', // keep this as last one
],
},
This is by design. Quasar is VueJS based, which (unlike e.g. PHP) focuses on delivering pages basically as SPAs, i.e. giving you data + JS to render it.
SSR only means that the first page is rendered on the server (e.g. for SEO purposes) and javascript takes over for fetching and rendering all subsequently loaded pages (or better the data + a recipe to render them) on the client. Thus, SSR will only get you server-side rendered pages upon initial load or page reload, all other renders are client-side.
You may learn about SSR, but also SSG (Static Site Generation), that might fit your needs, here: https://vuejs.org/guide/scaling-up/ssr.html
Related
Server Side Rendering (in Nuxt, but I think this is fairly universal) has been explained to me as:
When using Nuxt SSR, you request an URL, and get sent back a
pre-rendered HTML page. After loading, the browser starts the
hydration code, at which point the static page becomes a Vue SPA application.
I presume (perhaps incorrectly) that regardless that you are now in SPA mode, if you request a new page (eg. you are on "blog/ten-blue-things" you follow a NuxtLink to "blog/ten-red-things") the browser sends a new request to the server for this page, and effectively break SPA-mode? Or am I wrong?
I really hope the answer is that it does not make a request. In my scenario all the required data is very likely already available, and if not the page would make an API call to get anything missing to dynamically render the new page "blog/ten-red-things". Fetching a pre-rendered page after the first fetch is wasteful in my scenario where everything is already on the client (to clarify this further, this is a PWA offline-first app; I'm adding SSR for the SEO and social sharing of pages).
However, I also wonder that if it indeed does not make a request, does that (generally?) hold true for crawlers as well? I'd rather they DO make a separate request for each page in order for them to get the prerendered SEO-friendly version of the URL. If a crawler has js enabled, it may execute the hydration code, and then what?
Can anybody clarify this perhaps?
Does it matter for this anwser if instead of SRR we employ ISG (incremental static generation)?
It does not break the SPA mode, once you've SSR'ed and hydrated, the app stays as SPA. You can notice the fact that you don't have any "page reload" because you're doing a vue-router client-side navigation (as to oppose to a regular a link navigation).
The rest of the app will still be SSR'ed properly, you will not go back to the server meanwhile (as to oppose to Next.js).
They are several ways to debug all of this thanks to some devtools + trying to disable the JS/inspect the source code. But yeah, crawlers will properly parse the SSR'ed content.
PS: you can also choose what kind of rendering mode you want for a given page so if you want some to be SPA-only, you can. The rest could be SSR'ed (during initial render) + SPA after the hydration.
SSR or ISG will not make any impact regarding crawlers/SEO.
It works differently from SSR of course, but the rendering part will be the same regarding the markup. Only the "freshness" will be different.
I recently started working with Svelte via SvelteKit and I have a few questions about this framework to which I haven't been able to find any direct answers in the source/documentation:
SvelteKit has SSR and in the documentation it says:
All server-side code, including endpoints, has access to fetch in case you need to request data from external APIs.
What code is server-side rendered besides endpoints and how it decides this? All the code from scripts from svelte pages runs on the client or some of it runs on the server?
In order to make use of SSR locally you need an adapter for it or does svelte start a server on its own?
How does SSR work in a production environment like Netlify for example. Is the netlify adapter is used for SSR (running the endpoints in a netlify function)? If a netlify adapter is not provided, how/where would the endpoints run?
If I want to use custom netlify functions in a sveltekit project what configurations are needed (besides netlify.toml and netlify adapter) in order for netlify to recognize the functions from inside the functions directory?
What is the difference here between SSR and prerendering? SSR is used only for endpoints and other js code and prerendering is used for generating the Html to send it to the client which will then be hydrated, with the compiled js code, also sent to the browser?
Thanks!
By default, pages are also server-side rendered when you first visit a site. When you navigate to a subsequent pages they will be client-side rendered.
Adapters are only used in production. If you run npm run dev for local development you still get SSR. In production, how exactly SSR is run depends on the adapter you choose. An adapter is required for production. adapter-node runs SSR on a Node server, adapter-netlify runs SSR in Netlify functions, etc.
See here for discussion of custom Netlify functions: https://github.com/sveltejs/kit/issues/1249
SSR is used for pages as well, but prerendering means that rendering happens at build time instead of when a visitor visits the page. See this proposed documentation for more info: https://github.com/sveltejs/kit/pull/1525
Pages are SSR when you first visit the site, including all the code in the script tag of your svelte page. However, as you navigate to other pages, the code will be run on the client and the page will be dynamically rendered as Sveltekit makes a single page web app look like it has different pages with the history API.
You can decide which code runs on the server and which runs on the client. If you don't do anything special, Sveltekit and your deployment environment will decide that for you. If you want some code to run only in browser (perhaps it needs to use the window object or need authentication), you can use the browser variable.
import { browser } from '$app/environment';
if (browser) {
// Code that runs only in browser
}
You can also put the code in the onMount function, which will be run when the component first mounts, which only happens in browser.
import { onMount } from 'svelte';
onMount(() => {
// Do stuff
})
If you want SSR, you can put the function in the load function in route/+page.js. One typical use case is for a blog entry that grabs the content from the database and populates and formats the content. If you get to the page from a URL, or refresh page, the code in the load function will be executed on the server. If you navigate to the page from elsewhere in your web app, the code will be run on the client, but it will look like SSR as the UI will refresh only after the load function returns (you won't see loading screen or a blank page). See the official docs for more for more.
import { error } from '#sveltejs/kit';
/** #type {import('./$types').PageLoad} */
export function load({ params }) {
if (params.slug === 'hello-world') {
return {
title: 'Hello world!',
content: 'Welcome to our blog. Lorem ipsum dolor sit amet...'
};
}
throw error(404, 'Not found');
}
I am not very sure about how to use Netlify function, as Ben mentions, you can see the discussion on https://github.com/sveltejs/kit/issues/1249. Although I think that you might be able to implement the same functionality with +page.server.js, and the "Actions" to invoke them.
At the moment, I am trying to make an application with NEXT.JS. When I come to revalidate of page using method ISR. I very confused to understand how it works for the system or how is it auto to rebuild data of the pages in the system?
Many thanks.
You can think ISR as the combination of the SSR and SSG.
When you defined revalidate in getStaticProps, Next.js will generate the static HTML during build time because getStaticProps is exported.
When a user makes a request to the page, that Next.js app will serve the statically generally page. In fact, all the users will see the same page.
After the validation time is reached, the first user request to the page will make Next.js server-side rendered the page again. The generated page will be saved locally.
All users will be served with that newly generated HTML until the next validation. We then go back to step 3 again.
I have a MERN app in which I have integrated NextJS. First time with NextJS so bear with me. I have initially used SSR everywhere (getServerSideProps).
Key points:
I have over 150,000 pages with static content that it's never going to change.
Every week I add around +100 new pages.
I guess the ideal situation here would be using getStaticProps and getStaticPaths and, after an initial build of those 150k pages, just build the new added pages every week and keep what I already have built as it is since it's never going to change.
How can I achieve this? Should I use revalidate here? I have been reading about it in the documentation but I don't completely understand it.
That can be achieved with getStaticProps/getStaticPaths. You'll have to use fallback: true or fallback: 'blocking' in getStaticPaths.
With fallback: true the paths not generated at build time will serve a fallback page on the first request while Next.js statically generates the page. When this is done the page will be swapped from the fallback page to the actual full page.
With fallback: 'blocking', the paths not generated at build time will wait for the HTML to be generated by Next.js, then serve the page once that's done. Unlike fallback: true, since there's no fallback the rendering gets blocked until the page is generated, similar to what happens during server-side rendering.
In both cases the page gets added to the list of pre-rendered pages. Subsequent requests to the same path will serve the pre-generated page.
Neither of these options is supported by next export, in case you depend on that.
Note that revalidate is used in getStaticProps for Incremental Static Regeneration - in cases where you'd want to update existing, generated pages. Since you mentioned generated pages will never change, then there's no need to use revalidate.
I'd like to use Next.js static site export, but I'd also like to have dynamic components within the templates so that a build wouldn't need to be done every time they change, for example, a 'navigation' component. From what I've read this doesn't seem possible? Are there any workarounds, aside from creating a separate client-side build step?
Next is working on allowing for a combined static + SSR generated site, but they're not there yet. I see a few options currently:
You can export a static site, but have that static site make api calls, etc. So you can load your navigation or whatever via api calls. Benefit - no new build. Drawback - those links/that markup is not available to search engines and won't appear initially for users.
If you're using a CMS and CI system (eg, WordPress for content, Travis for CI), you can set up webhooks or functions in WordPress to fire and trigger a rebuild & deploy in Travis when your content changes.
Go full SSR. It still delivers a fully rendered "static" page to the browser, it's just not a static HTML file at build time but one at run time. This is your best option if you need to have your dynamic content rendered immediately for the user and don't want to build with every change.