I am working on one application which has rest services and these rest services are running on tomcat server.
I have one more tomcat running which has only UI part.I have built this UI in Angular. I am creating a war out of these Angular related files and deploying in this tomcat, which is accessing other tomcat's rest services.
I have two options of running my UI code, I can either use tomcat or use express js, but I am not sure which to use.
As I am comfortable with tomcat, so I am using tomcat only but if using express on node platform is more beneficial then I should be using that.
Could anybody please explain the pros and cons of using express js over tomcat for my UI project.
Overall it doesn't really matter. Both tomcat and NodeJS/express can do the job.
The benefit of NodeJS is that you are using the same language (javascript) on the front-end and on the back-end.
The benefit of Java/tomcat is its maturity. There's a lot more tools, IDEs, etc for Java than for NodeJS code.
There's also the difference between a scripted language and a compiled language:
Scripting Languages vs. Compiled Languages for web development
If you are trying to get things done, I would stick with Java/Tomcat since that is what you already know. You don't want to waste time figuring things out.
On the other hand, if you you have plenty of time to complete your project and have time to learn, I would recommend going with Express. It's a framework with growing popularity and it's always nice to be able to write the whole app in one language (aside from CSS/HTML).
Express is overkill to serve static files and slower than a native http server. Even Tomcat is overkill imho (it's not a simple web server). If you're looking for a light and fast way to serves static files, there is nginx: benchmark here. Or you could stay with Tomcat, it's already setup and faster than Express.
Related
Can someone enlighten me on web frameworks using nodejs? I recently started learning express js from free code camp and while it's all going good I'm confused as to what express entirely is. Is it a full stack framework? Is it purely for backend? I see that you can use different templating engines along with it.
I see things where people say you can use front end frameworks along with it. If express is able to already render views, what's the point of using a front end framework.
Also, what's the difference between express and something meteor, vuejs or react? There's just so many buzzwords out on the web that it's confusing.
Express is a back-end web server framework that runs in nodejs. It is purely for the back-end, though you can define routes/endpoints in it that any front-end can make ajax calls to.
You use Express to make the handling of web server requests and responses easier and fasster. It has support for things like:
Defining routes/urls/endpoints that you want to handle.
Serving static web pages.
Installing middleware for a wide variety of things including sessions and authentication.
Hooking into one of many template rendering engines.
Automatically parsing things like query parameters and form submissions.
Is it a full stack framework?
No. Express does not have a front-end component.
Is it purely for backend?
Yes.
Because Express has become so popular, there are also thousands of add-ins that can plug into express (often as middleware) for things like sessions or authentication.
Since it handles standard HTTP requests, you can use it with any front-end technology from just a plain browser to the many front-end frameworks.
Also, what's the difference between express and something meteor,
vuejs or react?
Express is a back-end framework (runs on the web server). vuejs and react are front-end libraries (run in the browser). Meteor is a full-stack framework. On the back-end, it runs on nodejs and the front-end component runs in the browser.
I see things where people say you can use front end frameworks along
with it. If express is able to already render views, what's the point
of using a front end framework.
Yes, Express can serve the web pages you view and it can use a server-side template engine to render them. But, there's potentially a lot more to a front-end framework than that. For example, express provides nothing to manage a user's interaction with a page in the browser or the building of dynamic web pages that change based on user interaction. If you're building web pages that create, read and update data from a database, then Express by itself provides no automation for doing that while other frameworks can offer a lot of help with that. You could build all that in your own JavaScript that would live in the web pages that Express was serving, but Express provides no help with that at all other than just delivering the JavaScript that you wrote on your own.
If you want to know more about what front-end frameworks do, then I'd suggest you read about frameworks like react, vuejs or angular to understand their value proposition. I'm not saying that you have to use a front-end framework (because you do not). There are zillions of sites on the web that consist of some sort of back-end framework and then plain JS/HTML web pages. Whether a front-end framework would benefit your development depends on what you're doing and how well it aligns with what a particular front-end framework offers.
Here are a couple good articles about what reactjs is:
ReactJS For Stupid People (fyi, I found it a very good article for smart people too).
What is React.js and Why I recommend it to other JavaScript Developers?
This article Full-Stack Frameworks contains a useful discussion of pre-built full-stack functionality such as Meteor vs. using a combination of technology such as MEAN (Mongo + Express + AngularJS + Node.js) or MERN (Mongo + Express + React + Node.js) and also touches on which technologies are more commonly used together.
Doing a one page application on one side and a REST API to get the ressources on the other side is something a lot companies do. I've been doing a pet project consisting on a REST API built with the Symfony2 framework and a SPA with Web Components and Polymer. The SPA is doing AJAX requests to get the ressources.
Now I'm wondering how to deploy it on the web. I don't have a lot of experience with deployment and I'd like to know if there are best practices to deploy a web app and where to do it.
I've looked at Heroku and the git push is very convenient but I don't know if (of how) I can push my 2 apps on the same dyno and handle the routing between the two.
Any idea on how to deploy such architecture?
You should look at using a deployment manager such as Capistrano. Symfony has it's own version which can be useful. Both a written in Ruby, whilst I like using Magallanes as it has most of the same functionality but is written in PHP so less dependencies and easier to modify.
I have an application and I have a debate with my peers on if we need to use node.js or not.
Our decision is to use angular.js for the front-end and to communicate via REST api with the app server. The application server will not be in node.js. It could be in .net or Java
Nginx will be in front as it is better for serving static files, gzip etc..
There are many options to boilerplate your angular application and many of them includes nodejs. My first approach was to use node.js as the primary web server and scale it out for solving performance issues. Although, it wasn't a good approach as node's roles isn't to act as web server. Well, here my question arrives.
By keeping in mind the two aforementioned points are there any reasons to generate the front-end including node.js ?
Is there something that I could benefited by that I haven't think of?
Here's the short answer: If you are set on using nginx in front of a .net or Java back end, and you're just looking for a deployment tool for angular.js, then just choose whatever javascript deployment tool makes sense, which may well be built with node.
What follows is a little more exposition:
I'm not quite sure what you mean by "node's roles isn't to act as web server"... if you mean in general, then that's precisely how it's generally used, if you mean your application server will be .net or java, but not javascript, then fine.
Generally speaking, nginx will perform faster for static files, but the margin of improvement over node.js is likely to be meaningless for pretty much anyone. If you need to (or it makes sense to) include node as part of your stack for angular deployment, then it could make sense to use it as your reverse proxy and just eliminate nginx altogether. The odds that you'll get measurable benefit from using nginx instead is vanishingly small.
That said... if you've already got nginx set up and moving to node instead represents extra work that you've already done once, then it loses its primary appeal.
What node.js has going for it more than any other project I'm aware of is that it's extremely capable at every level of the web stack. But it's not necessarily more capable than individual projects used in their appropriate level of the stack, and if you're not going to use it to reduce the complexity of your stack by homogenizing the technology and applications involved, then it just comes down to preference.
If you are caring about performance especially for static files, you could add caching layer as a proxy in front of your backend nginx or a server of your choice .. Varnish-cache is a good choice.
If you want to serve static files at large scale, there is yet a better solution through which you could host your static files in CDNs that will be much better solutions for your live deployments .. Clouding services are built for ease of use and also cost effective for example fastly.com is a good choice for hosting static files with a very persistent cached layer that is built on top of Varnish-Cache .. Cloud front is also another choice if you are fan of Amazon services.
More resources that might help is a comparison benchmarks having popular servers, also another benchmark existshere
I asked this (voted to be too broad) Question while working my way through a starter book on node. Reading this book, I'm sure I'll learn the answer to this later, but I'd be more comfortable if I knew this up front:
My Question: Can I (efficiently) continue using a usual webhost such as iPage or GoDaddy to host my web application, building and hosting the front end in a simple, traditional manner through an Apache web server, and communicate with a separate Node.js server (my application back-end) via AJAX for queries and other things that I can more efficiently process via Node?
More specifically, would this be a bad programming practice in terms of efficiency and organization? In other words, would it be likely that a large scale commercial application would ever be handled via this method?
Yes, you can separate the front-end of your web application and the APIs that power it. In fact, this is a very common configuration, especially for "large scale commercial applications".
Where you draw the separation line between the two specifically depends on what you are doing, how you're doing it, and what your needs are. Also, in terms of hosting, remember that if you're accessing something server-side across the internet, you're adding extra latency to everything. Consider getting off Go Daddy and using another host that gives you more flexibility, such as a VPS provider.
It's ok. Actually, this is how things shoud be done. You have a backend API on a separate server and lots of apps which are using the API. Just go with Nginx server, check this Apache vs Nginx.
Yes you can use node js as a part of some big application. It depends on wich type of interaction you would like to get. Is it comfortable to you to mix technologies? Then node is pretty good thing to work over web. I've finished a part of big nodejs-ruby-php-c-flash application (my part was nodejs) for very large data mounts. This application have different levels of interaction. Sometimes I use 2 languages at one time to create each part of my application the best for task I'm working on. There is applications that initiate, run and destroy mutiple OS instances. So using of multi environmental application not so hard.
I am working on a project which allows users to monitor energy consumption. The main dashboard page is a web app which is pretty neat and makes extensive use of javascript and ajax. The server currently runs apache and uses php; however, I am planning on installing node.js and updating the server side scripts in order to support websockets (and I also like the idea of using javascript on the server and client side).
I have followed several online introductions but I am struggling to find answers to specific questions, one of which is outlined below.
All guides to node seem to only support single page web apps. This is an issue as there are a number of different pages which require files to be served. How can I support file serving but enable one of the pages to use websockets. Does this functionality, which is only required for one page, need to be coded into the main server script on the site or is there a way of separating this so that the server goes to server the dashboard html file and then discovers that the file requires specific websocket dependencies?
Thank you very much for taking the time to read my questions. If you can answer any of them, or even provide any general advice, it would be greatly appreciated.
1: The only reason the guides do single page web apps is because that's node's forte. Node.js serves static files and rendered templates just fine. Just include the JS for the websockets only in the pages that need it.
2: It's not quite as simple as with php, but take a look at express.js
3: Yes, and really you shouldn't even need different ports, you can write a proxy in node in one line.
4: CentOS is fine, node is platform agnostic. All the linuxes have top support followed by osx, solaris and windows.