I am trying to assist in setting up AppDynamics with an Angular 2 app that is hosted in IIS. The app is already up and running. There is a part I am having trouble on, the instructions for that part say say:
1) From the root directory of your Node.js application, run this command:
npm install appdynamics#4.3.5
For every Node.js application you are instrumenting, insert the following call in the application source code at the first line of the main module (such as the server.js file), before any other require statements:
require("appdynamics").profile({
controllerHostName: '<controller host name>',
controllerPort: <controller port number>,
controllerSslEnabled: false, // Set to true if controllerPort is SSL
accountName: '<AppDynamics_account_name>',
accountAccessKey: '<AppDynamics_account_key>',
applicationName: 'your_app_name',
tierName: 'choose_a_tier_name',
nodeName: 'choose_a_node_name'
});
2) Restart you application
I did step 1 locally in the console, but I don't know what to do for step 2. If I add that script to the page I get "The Reference error: require is not defined".
I learned that that function is not meant to run on the browser. It's meant to be run server-side, but I do not see node js or any server.js files on our dev web server.
Does anyone have any suggestions on where to put that snippet. Will it even work with the current setup?
It turns out the code I was given was completely wrong for angular 2 implementation. The code they gave me is for running on the web server's side with node js. Since angular 2 is an SPA that runs on the browser, it would never work.
I did some research and found this example application that I added a few tweaks to: https://github.com/derrekyoung/appd-sampleapp-angular2
Related
I have a basic electron app (wrapping a Reactjs app) - everything works fine both in dev and when packaged.
Now I want to introduce a dependency, another basic nodejs express file server. I have written this file server and it works.
This file server is a nodejs module (so that it can be managed seperately). It is then required and spawn within the electron app as a seperate "child process".
Problem:
When I run "yarn start:dev", everything works perfectly but once I package this app(yarn pack:dev), everything works EXCEPT the file server(child process).
I believe this has something to do with the path and the fact that electron will bundle the entire app as "asar". I have tried different approach and exhausted of ideas.
I think the "asar" file path is not accessible or something. I have also disabled the asar in electron-builder.yml but still having same issue.
Please I will really appreciate any help. Thanks.
I'm new to vue and kind of confuse here.
I'm using vue-cli to build a vue app, I understand I can run a development server with npm run serve which is referenced as a script in my package.json for vue-cli-service serve
But my app need some data coming from a local node.js server. I cannot request this server from development mode because it's running on a different server.
To make my app work I'm obligated to build for production with
npm run build
Then to ask my node server to render by default the produced index.html file.
How could I combine development mode and my node server?
What would be the best way to make this work?
Thanks a lot
I stumbled across this, and found the answer buried at the bottom of the comments list, so I thought I'd highlight it.
This answer is taken from #Frank Provost comment, which really should be the accepted answer. As mentioned in his link https://cli.vuejs.org/config/#devserver-proxy all you need to do is create/edit vue.config.js file in your (client) project root to include this:
module.exports = {
devServer: {
proxy: 'http://localhost:3000' // enter dev server url here
}
}
Then start your dev server as usual from your server project:
[server-root]$ npm run dev
And run your client project from vue-cli project
[client-root]$ npm run serve
Then when you visit the client url (usually localhost:8080) all api requests will be forwarded to your dev server. All hot module replacement still works on both client and server.
I have an Angular Universal app that I am deploying to Azure App Service (Windows).
When the app runs locally on my Windows 10 PC it works fine but in the cloud it seems like the process.cwd() is different than when I run it locally. This is causing Express.js to look in the wrong place for some view files.
The process pwc should be based on how I executed node, in my case I have a start script in my package.json that executes "node dist/server.js". But I can remove this script and Azure will still start my app. So I think the root of my pwc problem is in how Azure starts up my node app.
Unfortunately Microsoft thinks that some code snippets and a couple John Papa videos is good enough documentation for developers to resolve issues.
Questions
Does documentation exist that explains any configuration or
conventions that the App Service uses to init my node app? Where is
it?
Given the script "start": "node dist/server.js" why would process.cwd() be different on my local host versus Azure App Service? The file structure is the same in both places.
const DIST_FOLDER = join(process.cwd(), 'dist');
app.set('views', join(DIST_FOLDER, 'browser'));
Error: Failed to lookup view "index" in views directory "D:\home\site\wwwroot\dist\dist\browser"
root
package.json
dist
server.js
browser (client app)
server (server app)
Documentation: Not an exhaustive guide, but this is what I found useful on MSDN forums:
Windows Azure Websites uses IISNode to host the Node process inside of IIS. Your Node site is actually given a Named Pipe which receives the incoming requests, not a TCP port like you would use when running locally or hosting yourself.
...
As a node.js application running on Azure Web Apps, needs a server.js or app.js file as the entrance in the root directory with a web.config file to control the iis
Working Directory: When web.config and iisnode are used to run server.js, the rules rewrite the directory to point to where server.js resides. That is why it isn't able to find a subfolder 'dist'.
I had to change the line above to this, in order for it to work on Azure:
const DIST_FOLDER = process.cwd();
Another thing I found important was to set the right version of node for your App Service, using WEBSITE_NODE_DEFAULT_VERSION in App Settings. Here's a bit more info on that from a blog on MDSN - NodeJs and NPM versions on Azure App Services
Since I am used to hosting Node apps on Linux this totally slipped my mind. The answer is...
see web.config
If anyone else finds themselves here put this in your server.ts file to work both locally and on azure
import * as fs from 'fs';
const distFolderExists = fs.existsSync(join(process.cwd(), 'dist'));
const DIST_FOLDER = distFolderExists ? join(process.cwd(), 'dist') : process.cwd();
big thanks to KayS for their answer - really helpful.
I want to create an offline "Desktop Application/Website" with Electron. The UI/backend is essentially a "React Application".
What I'm trying to achieve:
Have a React application, which I run npm start would launch a server that can be accessed with a browser on my system (and within the local network)
Create a downloadable cross platform "single file" (.app in dmg for Mac, .exe for Windows) that users can download, and run on their system (to achieve the above); for this I thought Electron would do
The above file should work without the user being required to install dependencies locally (e.g. Node)
What I have done
After creating the react app, and installing electron, I edited the electronjs entry file to become the below:
win.loadURL(url.format({
pathname: 'localhost:3000', //path.join(__dirname, 'index.html'),
protocol: 'http:', //'file:',
slashes: true
}))
Then, I used "concurrently" and "wait on" modules to ensure that when I run npm start, the react server starts first before electron launches. It works (for development)!
But when I package the app (for production, producing a Mac executable - MyProject.app), and run it, the server never starts, so electron shows a blank page for localhost:3000
How do I achieve this?
Try this instead -
win.loadURL("http://localhost:3000");
I created a new Node.js app on Bluemix this morning and downloaded the boilerplate code. I worked on it locally and then pushed it up. On Bluemix, it refuses to start. The error according to the logs is:
Instance (index 0) failed to start accepting connections
So I Googled for that, in every case where I found the result, the answer was that my application was trying to use a specific port instead of letting Bluemix set it.
Ok, but I'm setting the host/port with the exact code the boilerplate uses:
var appEnv = cfenv.getAppEnv();
// start server on the specified port and binding host
app.listen(appEnv.port, function() {
// print a message when the server starts listening
console.log("server starting on " + appEnv.url);
});
So if this is incorrect, it means the code Bluemix told me to download itself is incorrect as well, and I can't imagine that is the issue.
To identify whether cfenv is at fault, I've tested that piece of code with a number of more complex Node.js apps I have, and they work perfectly on Bluemix.
That message can also come when an application you've deployed to Bluemix fails to start at all. Here's a few things you can do to troubleshoot your Node.js application on Bluemix.
Tail logs in another terminal while pushing with "cf logs
". Inspect logs after the failure to see if something
failed during the staging process.
Check that your start command in one of two recommended places, scripts.start in package.json or in a Procfile with web: node <start-script>.
Check that your application works locally. First (optional), create a .cfignore file with "/node_modules" in it, so that when you push the app to Bluemix, CF CLI doesn't push your entire folder of node_modules (as they will be installed dynamically). Next, wipe out your node_modules directory and do an npm install --production followed by npm start (or your custom start command). This is what Bluemix does when trying to start your application, so you should double check that it works locally.
Finally, try bumping up your memory, although this is very unlikely that this is why your application fails to start.