I'm building a small project using Angular 7. When you run
ng serve
and a NodeJS server is spun up to handle requests, does each request block until processing is complete? We are trying to evaluate how effective using this in production would be as opposed to using a more traditional application server.
Run build --prod to generate a "./dist" folder.
Then you have to put that on a web server.
You can use Angular Server Side Rendering (SSR) to run it on a node.js server.
You should not use ng serve for production because it use webpack-dev-server that is build for development only.
Github link
ng serve runs a webpack development server behind the hood.
a development server.
It's made to mimic the production build and see your final application in an esay way.
If you didn't have that command, you would need to run a command like simplehttpserver after rebuilding all of your application on every change.
This is a convenience tool provided by the CLI to ease your development, in no case it's suited for production mode. This is a server without security, without optimization, without performance, without ... Well, without anything that makes a server, a server. By default, it deosn't even make your application accessible outside of your localhost. Not so useful for a production mode ...
So, never, I repeat, never, use this command for your production server.
Run ng build --prod
It will generate minification code in "dist" folder. you have to upload the file content of this "dist" folder. It will give faster response for loading web pages.
For more details please refer Angular deployment guide
When using ng serve, you are spawning a backend nodejs environment with a web server to handle requests towards your angular application. That's great for reloading and quick startup when developing. But needing such resources for static pages is unnecessary.
At the end of the day Angular is just a framework telling you its opinion on how to build an SPA. No matter the framework or library you use, you will always end up with an index.xxx, Javascript files and other resource files from vendors or internally. Only these matters to the browser loading the webpage.
Hence, you need to build your app to generate the static files that will be served (i.e. ng build --prod). Then you have 2 good options:
Choose a web server that will serve the files (i.e. nginx) on a dedicated server (or even container).
Place the files behind a CDN provider. Since they are static, they will be cached and served to a browser requesting them based on its location.
I would opt for #2 as opposed to #1 forcing you to keep running resources (CPU, RAM, HDD) for files that will be requested not that often. I say not often because your SPA will be handling all routes within itself in the client's browser (and minimum once a day will request a cache refresh).
Related
I have a node.js application that run as a application server.
It is deployed on an Ubuntu 20.04 machine running on AWS, uses nginx as a reverse proxy and PM2 as a service starter.
Everything seems perfectly configured.
What looks strange to me, is that I have a React application, in a similar environment, but, before to move it on the server, I run build it, so creating a sort of packed and not easily human readable application.
My question is: Is there the need to do the same with a node.js application?
And, in case of positive answer, How to 'build' a node.js application?
There is no need to build a normal nodejs application.
What you mean is the use of a bundler e.g. webpack and a javascript compiler e.g. babel. To create a react application, you usually use a tool like create-react-app that sets up all this stuff for you. For react you need the compilation beacause you use the jsx syntax that browsers do not understand. In addition to that a bundler has some more advantages.
Check out this video if you want to know more about it:
https://www.youtube.com/watch?v=5IG4UmULyoA
No you don't have to build anything for node.js you just have to run the server. for client side apps you need to build and serve the Dist through web servers like apache or nginx.
I have an application built with Create React App that I want to use Node.js as a backend to load data from a database. Basically, I want Node to load the data and then use Create React App to do stuff with it. To do so I used this tutorial: https://www.freecodecamp.org/news/how-to-make-create-react-app-work-with-a-node-backend-api-7c5c48acb1b0/. I have set up a working development environment where I have all the Create React App in a client folder, a server.js that loads the data (from MS SQL Server if that's relevant), and a proxy set in client/package.json (CRA's package.json) for the port that the node app is running on (5000 in my case). I then run yarn dev and these two servers run together and talk to each other and everything works great.
The issue is deploying. My organization uses IIS. From what I can gather Node and IIS are not the ideal combination but IIS is what we use for everything. I would like the server.js and the CRA to be in the same folder and to basically function like one app as much as possible (I know that Node will need to run its own server). I would also like a setup that can be easily changed or moved to another machine. What I've done thus far is:
Set up a single application with a client folder, which is the build for CRA, and then server.js in the root
In my react code, made API calls to http://localhost:5000 (in the development environment I could do fetch('api/somestuff') but to make it work in production I needed to do fetch('http://localhost:5000/api/somestuff') )
Installed pm2 and used it to run server.js and start the Node server
This worked, however I'm wondering whether this is the optimal way to do things. This worked on my local machine but I don't know what will happen when I put it on our production machines. Will the Node server block other applications? Will it stay running no matter what or might it crash? Ultimately this is going to be deployed in a multi-server environment where we have 2 load-balanced servers with identical code that are put through an F5 to form a single URL--will this impact anything?
I'm pretty new to programming so bear with me, I'm sorry if this question was confusingly phrased.
I suggest you install ARR to work with IIS as a reverse proxy, which can forward the HTTP request to the backend NodeJS server.
Besides, for cross-domain request forwarding in the rewrite action type, we need to install Application Request Routing, and enable the proxy functionality.
Here are two examples of applying this feature, please check it.
How to successfully run node server with IIS?
ASP.net URL Rewrite subdirectory to external URL
Feel free to let me know if there is anything I can help with.
I have been using webpack to build a server side app using express. This code is harder to debug since I don't have the immediate comfort of a web browser and if I use something like VS Code to debug, it won't accept breakpoints inside request handlers when using source maps. Besides it takes no time to compile if I just stick to Node compatible JS and skip all transpiling and whatnot. Further, if I use treeshaking, I can reduce the size, but what is the point of that when it is running on the server (no client will ever download it).
My point is that I don't see why one would want to create a bundle of server side code if the server don't have any issues with memory or other limiting factors. It's easier to read, takes no time to compile and is easier to debug.
So a question. Is it ok to have the server app as an npm package and deploy that? Is that what is common or what do people do?
The project my team works on is a TypeScript monorepo that includes a web application and server-side daemon processes. We use webpack for producing build artefacts for all targets.
I've read some posts saying there's no point using webpack server-side because it was designed for web (obv), and I can understand that point of view.
However, even if our code was JavaScript and didn't require any transpiling, we'd still use webpack for the server-side. I want a single, minimal set of files and no node modules to deploy to the servers.
Size itself doesn't matter that much for server side (though every bit helps), but running 'yarn install' on servers is out of the question IMO.
Seeking some ideas on how to better improve my teams local development workflow...
We have a Vue CLI shell application project that runs locally via node. Then we have a number of small Vue CLI web-component applications that served up via node.
When the shell is ran it reaches out to each web-component application retrieving a manifest.json file which tells the shell where/when to display the respective web-components.
Our web-component applications are built using something like...
vue-cli-service build --target wc --name foo 'src/components/*.vue'
Having to continuously build the web-component projects after making a code change... debug... and then rebuild again seems cumbersome. This is a new application so at the moment the codebase is in constant flux.
Was hoping someone may have suggestions on how or tools we might use to increase our productivity.
Don't overcomplicate things.
Here's Nuxt.js
As far as I can tell it does everything you want to do straight out of the box. Just set up a basic hello world project with Nuxt and see if it does everything you need it to do for you. It uses Vue.js and Webpack to build the exact same type of application you'd be developing otherwise with Vue, it just has a nicer layout and easier workflow in general. It supports hot reloading on file changes, you'd just run nuxt in the root folder of your project and a local server is started that hot reloads your project whenever you save changes to a file. You then distribute it either as a static application with nuxt generate or build it as a server side rendered application using nuxt build and nuxt start.
I am new to Angular2. I have stated learning through resources in Internet.
I am using Angular-Cli tools for building my test application.
When I issue command ng serve --open I got my example project running on a default port 4200 and console shows,
** NG Live Development Server is listening on localhost:4200, open your browser on http://localhost:4200 **
Now I am very confused with NG Live Development Server.
I have the following concerns,
Being a Client Side Framework why angular needs an development server.
Where Live Server is physically Located in running machine
The Live Server
can serve only Javascript or any other language.
What is the
complexity in integrating Angular2 application with Server side
frameworks like Spring-MVC.
Could anyone please provide your thoughts on this? Please correct me if I have understood the concepts wrongly.
Tl;Dr the cli live server is only for local development. Not for production or any environment other than local dev.
To answer your specific questions:
Being a Client Side Framework why angular needs an development server.
Angular is an SPA framework. The compiled application code needs to be loaded into the browser from a web server.
Where Live Server is physically Located in running machine
The server is part of Webpack, which is a dependency of Angular-CLI. So it is in your node_modules folder.
The Live Server can serve only Javascript or any other language.
The development server is only for running your Angular code on your local development machine. If you have a API backend, you should look at proxying requests through the dev server to your dev API.
What is the complexity in integrating Angular2 application with Server side frameworks like Spring-MVC.
This is trivial. You will not host your Angular application in production on the live dev server. Instead you will run ng build --prod --aot to build the production bundles into the project dist folder. These are the build artefacts that will be deployed to your frontend webserver. Configure the frontend to run at the root contest i.e. www.foo.com/ and the the Spring API to run at the /api context www.foo.com/api/.
You may want to take a look at this:
Node live server
This clearly explains what exactly is a live server and also how it works:
Quoted from the link:
The server is a simple node app that serves the working directory and
its subdirectories. It also watches the files for changes and when
that happens, it sends a message through a web socket connection to
the browser instructing it to reload. In order for the client side to
support this, the server injects a small piece of JavaScript code to
each requested html file. This script establishes the web socket
connection and listens to the reload requests. CSS files can be
refreshed without a full page reload by finding the referenced
stylesheets from the DOM and tricking the browser to fetch and parse
them again.
If you go through the entire post, you would get the answer to almost all your questions.