I'm considering integrating nuxt.js into our vue.js application. I'm trying to figure out if it's feasible. By feasible, I mean how much of an overhaul would it require.
I understand that nuxt.js is more than just a pluggin. If it were a plugging, it would be super easy. You would just npm install and Vue.use(nuxt) and that's it. But as a framework, I understand that nuxt.js expects certain structures to be in place. For example, I know from https://hiswe.github.io/2018/12-vue-with-nuxt/ that nuxt expects a certain folder structure (/static, /page, /layouts...), but can these live side-by-side with the standard vue.js folders (/assets, /components, /views...) or do they have to be replaced? If side-by-side, then no overhauling of existing code (just add new folders). Otherwise, there could be quite a bit of work to overhaul the structure.
And if they can live side-by-side, would the nuxt folder supersede the vue.js folders (ex. would it no longer look for components in /components or /views and instead expect them to be in /pages)?
I also understand that nuxt router depends only on the folder/file structure in /pages rather than the router.js file that vue.js depends on. Does this mean router.js will no longer be used? Or will router.js still be used until we tell it not to (by removing certain routes from it, for example).
You don't need to answer the above questions (although it would be super useful if you did). I just provide them to give an example of the things I need to consider. The main question is: how much work is involved in overhauling a vue.js application when nuxt.js is being integrated.
To give some perspective of the size/complexity of our application, you can see it here:
https://www.bodecanada.com/
The source code is just under 600MB (compared to a startup vue.js application which is usually < 100MB). It includes a backend API that connects to a postgres database. We host it on AWS Lambda. We'd like to take advantage of the SSR abilities of nuxt.js but as I understand it, that requires a node.js server (not sure how easily that integrates with our Lambda instance).
^ Those are the specs. Just looking for a rough idea. Easy? Difficult? Thanks for any feedback.
Related
First of all, I know that nextjs has support for .env files... and this is great.
However, I do not wish to write secrets to disk, ever, becuase they might wind up in a docker image in an amazon ecr repo and someday get read by a hacker... so I won't write them to a yaml or a .env file. This is our company policy: we integrate with hashicorp vault.
Now, my idea was to get these secrets, and store them in nconf. Nconf is just a memory-based storage engine for organizing config... nothing special. I had planned to eject from nextjs cli and use a custom express server (with typescript). Fine... I can do that. But it's a little bit of a pain because it seems like people aren't doing that as much as they did 3 years ago when I used nextjs last.
That is probably because they don't want to miss out on the automatic static rendering, and neither do I.
But basically what I want to do is to make a global variable available server-side in nextjs on every page: my nconf config. I want to run things on the server and not in the browser (no secrets in the browser).
For instance... what about middleware? Can I run middleware without setting up a custom express server and ejecting? I feel like we're going to need middleware at some point, we're make an enterprise app. So I'm kind of using nconf as a litmus test. But hey, if there's a good way to handle secrets, LMK.
Am I missing something in the nextjs docs? Are there events or hooks I can tap into? Or is the whole thing kind of "nextjs way or the highway?" Because in that case I will need to eject. (I grew up in Drupal, where there were tons of hooks and you could do what you needed to with the right hook.)
Thanks for your help.
I've built multiple sites with Nuxt SSR, but never touched the static part.
As far as I know, upon build-time, Nuxt automatically executes all API calls and caches them.
If I want to make a blog with a static Nuxt site, how would I update the content? Is it only possible when I rebuild the app?
Seems unnecessary to rebuild everything every time I add a new blog post. With SSR I just reload the page.
Also wanted to note that I have a Strapi.js backend running on a VPS and I usually make changes weekly. Nuxt's docs state that I need to push my changes to the main repo branch but there's no changes on the frontend.
Does this also mean that the headless cms should be local only?
The whole point of having a static build is to have all the generated files with no additional server Node.js server needed. It reduces heavily the costs, removes a point of failure, discard any notion of server charge (amount of users at the same time on your app) and probably some other advantages yeah.
Downside, you indeed need to actually yarn generate the whole app again if it's something that was added/changed in the codebase. Usually it's pretty fast and there are also incremental builds if I do remember properly (you will not regenerate all the 99 old blog posts but only the 100th, the new one).
Headless CMS like Strapi usually work with a webhook: you add a new CMS article or alike, Strapi will notify your JAMstack platform to rebuild your app. Even if no front-end code was changed, you can force to build it with the new data coming from the headless CMS' API.
I just started working with Nuxt JS, and I'm trying to pass a request from the client to my Express server, but Nuxt treats the routes like they were suppose to be pages.
Hence I get the errors page not found in pages folder. Help please.
I've gotten into using an express backend with nuxt and it's a great way to go about it. As there is quite a lot steps to take and files to set up it's perhaps beyond the scope of a single answer here to cover what's needed. I'd recommend you start with this tutorial on codeburst which covers all the steps you need and can be expanded upon easily once you understand it. Good luck.
I'm learning webpack, and this is a theoretical question. For each webpage in a site, I'm planning to make a page-specific module that itself will require a module for site-wide code. I'm planning to use webpack's splitChunks so that the sitewide code is saved to a separate bundle.js. In theory, is this plausible / best practice? I suppose the inverse is possible where the sitewide module is the main entry. Thoughts?
OK I had my a-ha moment. Yes, each page in the site is an entry and needs to be registered as en entry in one main webpack.config.js. When I webpack the site, webpack will automatically split common code into chunks. Since each page will require the site-wide module, webpack will see that common dependency and optimize the chunks.
Folks:
I'm creating an app using Node Webkit. The purpose of this app is to display images and pdfs. The app needs to download those files from a central repository, and cache them locally. When the app runs offline, the files should still be available, and displayed.
On the face of it, this sounds like appcache is the answer - and that indeed is where I was heading when this was a pure webapp in a browser. However, now I've discovered node-webkit, and here we are.
node-webkit's GitHub wiki states:
"However, application cache is designed for browser use, for apps using node-webkit, it's less useful than the other two method, read HTML5 Application Cache if you want to use it."
But doesn't say why.
I've also researched node.js filesystem - but that seems like a whole magnitude of complexity above what I need.
Can anyone point me in a sensible direction?
Thanks.
It has to do with the nature of App Cache itself.
You specify a manifest file that lists all the static assets required for your app to run offline. You don't have any programmatic access to the cache to add and remove files via JS.
So for a node-webkit app, it'd make more sense to fetch these files and store them in the Application Support folder (Or AppData, depending on the platform). That's where the node.js part is really useful, the file IO stuff.