I've set a custom server from the example but, my question is...
Can the server code access the NextJs code?
I mean, NextJs is built with webpack, therefore packed in its own context, so if I want to initialize something (let's say, database, logging system, etc.) in the server before NextJs has started, and then access it from NextJs... is it possible? I don't see how unless server code and NextJs code are in the same bundle, is it?
Yes, I guess there are some hacks that can be used, like importing files in runtime with __non_webpack_require__... but that seems like a hack (?) and only in one direction.
Any other better option?
If you use SSR in NextJS, you can access to APIs before rendering.
https://nextjs.org/docs/basic-features/data-fetching/get-server-side-props
If you export a function called getServerSideProps (Server-Side Rendering) from a page, Next.js will pre-render this page on each request using the data returned by getServerSideProps.
It fetches your data upon a user requesting your website everytime.
Thatmeans no matter what you build first on your server. Next.js will fetch for it every time. The comment above me sent the correct link. https://nextjs.org/docs/basic-features/data-fetching/get-server-side-props
TO view all data fetching techniques from next.js visit: https://nextjs.org/docs/basic-features/data-fetching/overview
PLease comment back to this to see if this helped, or if we missunderstood the question, so that we can help solve this issue, or if you resolved it. happy coding!
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.
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.
When I turn on webpack5 and call internal api(/api/*) from page after first render, the page refreshes and logs Refreshing page data due to server-side change. after refreshing once, it works fine as webpack4.
Expected Behavior
The page should not refresh on api call after first render.
I recently updated to Next JS 12 and suddenly started encountering this issue also. I'm not sure if it's necessarily related to that as I believe Next JS 11 was also using Webpack 5 for HMR, but they certainly switched over to socket communication for hot reloading, rather than server sent events as they had with previous versions. [https://nextjs.org/docs/upgrading#nextjs-hmr-connection-now-uses-a-websocket]
I have a file /inc/paths.js where I am organizing and exporting URI path string variables for different resources in my app. There were a number of paths in that module which were also being utilized by parts of my /api scripts, namely object keys for AWS S3 bucket paths. So, this module was being imported by not only React components in the /pages directory and elsewhere, but also to the modules in the /api directory. By moving all the variables used by the /api modules into their own file and making sure that none of those variables are imported by React components or pages, the error seems to have disappeared for me.
This may be related to this quote from Vercel:
Finally, if you edit a file that's imported by files outside of the
React tree, Fast Refresh will fall back to doing a full reload. You
might have a file which renders a React component but also exports a
value that is imported by a non-React component. For example, maybe
your component also exports a constant, and a non-React utility file
imports it. In that case, consider migrating the constant to a
separate file and importing it into both files. This will re-enable
Fast Refresh to work. Other cases can usually be solved in a similar
way.
https://nextjs.org/docs/basic-features/fast-refresh
Although the logic doesn't quite match up, it leads me to believe there is something occurring along those lines.
I updated next.js due to the console warning I get whenever next.js run, telling me its using using weppack 4 instead of 5
You can still use webpack 4 by changing it from your next config as it's an update issue
On the client page, I changed to call the internal API by useEffect() hook to fetch data, instead of triggering the data-fetch function by onclick. I found the issue was gone.
I have some pages that could benefit from being statically generated by implementing getStaticProps. The problem is, inside getStaticProps I need to call some api and access resources aren't available when I want to do the build (that is when building the docker container in which next.js will run).
Is there a way to tell next.js that I want to postpone the build of some pages untill they are requested for the first time? I feel like it should be possible, the revalidate option for getStaticProps almost does what I want (it re-generates the page the first time it's called if the previously generated one is older that X), problem is, it still tries to generate the page on next build.
There's also the fallback option for getStaticPaths that almost works for me because it allows to postpone the generation of a dynamic-route page. Problem is, I need it for static-route pages too.
This has been asked in similar forms here and here but it seems pretty important, and the framework is under rapid development, so I'm going to raise it again:
Assuming your login page needs to face the public internet, how do you prevent Meteor from sending all of the authenticated user templates to a non-authenticated client?
Example use case: You have some really unique analytics / performance indicators that you want to keep secret. You've built templates to visualize each one. Simply by visiting the login page, Meteor will send any rando the templates which, even unpopulated, disclose a ton of proprietary information.
I've seen two suggestions:
Break admin into a separate app. This doesn't address the issue assuming admin login faces the public internet, unless I'm missing something.
Put the templates in the public folder or equivalent and load them dynamically. This doesn't help either, since the file names will be visible from other templates which will be sent to the client.
The only thing I can think of is to store the template strings in the server folder and have the client call a Meteor.method after login to retrieve and render them. And if you want them to behave like normal client templates, you'd have to muck around with the internal API (e.g., Meteor._def_template).
Is there any more elegant way to do this?
I asked a similar question here:
Segmented Meteor App(s) - loading only half the client or two apps sharing a database
Seems to be a common concern, and I certainly think it's something that should be addressed sometime.
Until then, I'm planning on making a smaller "public" app and sharing the DB with an admin app (possibly in Meteor, possibly in something else, depending on size/data for my admin)
These 2 packages try to address this issue:
https://atmospherejs.com/numtel/publicsources
https://atmospherejs.com/numtel/privatesources
It uses an iron-router plug-in to load your specific files on every route.
The main drawback I see here is that you must change your app structure, as the protected files need to be stored in /public or /private folder.
Also you are supposed to use iron-router.