Hosting Nuxt on Azure App Service (iisnode) with custom Git based deployment (kudu)

..Instructions

Previously this gist had a series of files showing a working setup, but, 
@burkeholland found a much easier way and demonstrates it here:
https://github.com/burkeholland/nuxt-appservice-windows

Essentially, you'll:
1. add a .deployment file to instruct kudu to run `npm install` for you, 
2. leverage npm tasks' `postinstall` hook in package.json to trigger the full nuxt build,
3. add a server.js file in the root that `require`s the default server\index.js file that a nuxt app will already have

Step 3 will be noticed by kudu, which will:
* auto-create you a default web.config for iisnode (if no web.config exists), and 
* use that server.js as the entry point, which you've now redirected over to nuxt's default server.js cleanly

Notes: 
* For step 3, you'll only have a `server\index.js` if you've chosen a server-side framework in the `npm create nuxt-app xyz` setup. 
  I had success with express.
* Don't forget to make sure your Azure app is on a high enough node version for both running AND building. 
  You can now create apps from the portal with a version picker which is nice. 
  Otherwise you'll wanna configure it with the app setting for runtime and in the .deployment config file for kudu/building.

Kudus to Burke! (pun intended)

Thanks ben!

No worries @julen-folky. How's this? Feel free to chip in any thoughts.
https://cmty.app/nuxt/docs/issues/c243 and associated GitHub issue.

Wow! The post perfectly describes the problem. Thanks again!

@julen-folky, no worries. It's easy to describe because I come from the same place and have always wondered the same. I'm a dotnet dev, not a node dev :P Hopefully we get a good answer and some action on it!

I posted on Stackoverflow on the neccesity or not to restart the node process with every deployment.

Sorry if this is not the appropriate thread, I thought it may be of interested for the people following it.

I think it's a good question and happy for it to be in this thread. I guess my thinking is that as long as you get your built files inside the wwwroot, then IIS / AppPool doesn't really have an impact, it's just a thin web server layer handling requests and routing them to the node app.

If IIS/AppPool was doing something else, like in-memory caching or the like, depending on the mechanism, you may need to start thinking about an app pool recycle / cache bust, but if the web.config doesn't have anything like that, it's safe to say you'll be fine without one.

Looks like is like you say @benmccallum. Today I checked by chance the page on Azure of the nuxt guide; in the web.config example, by the end there is an explanation about defining a set of files to be watch and recyle the server if they change.

Nevertheless, I would ask for further clarification to a NodeJS/Express expert.

Good spot! I guess if you were doing in-memory caching (inside your node app of config files or something) then it makes sense that you'd need to configure watching of those files to restart the app. Since they haven't indicated anything in particular I'd say that nuxt itself doesn't do anything like this or can handle those kinds of filesystem changes. Static assets (those picked up by the static rewrite rule) will cache bust themselves as part of standard IIS if you had static asset caching I imagine (which isn't demonstrated here but should probably be turned on).