Is there a difference between a network and server application? For instance, node.js boasts the ability to "build fast, scalable network applications". How is this any different than writing a servlet with PHP? Or are they one and the same?
Server application run on server and clients use some network protocols to connect and make some operation over it so it means every server application is a network application too. But with this sentence
build fast, scalable network applications
I guess they try to emphasize node.js has a lot of ability to do operation over network,IO and database operation with its libraries.
There are 3 different things asked at this question
Node.js can be used for server programming like servlet. You can write javascript to developed a asynchronous server with the help of node.js libraries. You use javascript for client(jquery) and server(node.js) side.
You developed a server use of java programming language and help of servlet libraries. Also you can use java at both side client and server side programming.
Php is a server side scripting language, at server side there is php interpreter, php code converts to html. But server side is Apache HTTP server and CGI. Actually i am not expert PHP server side things.
I have developed an application XPages that work very well in a Browser (Firefox ) and in every page the browser load max 150Kb of content (html, image, js, css...etc...)
When I have deploy the application to my remote user that directly access to server with XPiNC mode the speed are very very poor!
With a tool I sniffed the traffic and I see that for every GET there are 10Mbytes of data transfered (seem to transfer XML source and other code that is compiled on the fly...)
The application inside Notes Client is not useable so...and my customer has disappointed for this feature (is not possible use in local and replicate)
I have 8.5.3FP2 (client and server) with PRELOAD option setting.... without any change of this.
Have someone any suggest for me? Is this a BUG ?
It is true that remote applications (NSFs residing on a non-local server) are slower than local client replicas or remote apps run in a web browser. This is due to the fact that a lot more network transactions are generated when running in this mode. There are various things that can be done however to remedy the problem.
First however we need to identify the cause of the problem - you are seeing a 10MB transfer for each GET request, which is very large and will obviously negatively impact performance. One or more of the XPages in your application may be using the computeWithForm feature? If an XPages document data source "computes" a Notes form (typically to execute pre-existing application logic) then the form must be copied across the net to be computed in the local client. However all children of the form will also be hauled over - subforms, shared fields etc, and this can result in large net transactions like those you are seeing.
Often the computeWithForm feature is used as a development convenience and as long as the size of the form is small then the performance impact can be negligible. However, if the aggregate form is large, then it may be worth your while replacing the computeWithForm usage with separate XPages SSJS application logic.
Before going further we would need verify that this is in fact the issue - there could be other issues. Typically this manifests only on pages that open/edit documents - so you can maybe try turning computeWithForm off in a test environment and see if there is a difference.
XPiNC is a little special. When you open a server based NSF, all the program code needs to be downloaded to the client to be executed in the server container of the Notes client. The reasonable way to use an XPiNC with data in the server is to split the application. Have one NSF that contains all the program logic (all XPages and other code) and the other with forms, views and documents.
Replicate the application NSF locally and access only the data on the server. This should give you much better performance. You could have a configuration setting to compute the data NSF, so disconnected users could use a local replica of the data.
Let us know how it goes.
P.S.: There are some more tuning ideas...
I am going to build a web application to manage notes (think of something similar to Evernote). I have decided to use Backbone.js+JQuery client side.
Server-side, I haven't decided yet: either pure PHP (that I know very well) or Node.js+Socket.io (completely new to me).
I am considering Node.js+Socket.io because I would like to have my web application being real-time (i.e: if a user updates a note, that note gets updated instantly for a collaborator who shares that note, without reloading the page).
I was also considering, as a third alternative, to use Node.js and Socket.io for the UI and PHP for the REST API (I feel more comfortable to build an API with PHP). The PHP and Javascript code will share the MongoDB database.
My question is this: if I develop the REST API for my web application with PHP and a new note for the user gets created through the API (i.e.: the Android app sends an API request to create that note), will Node.js, Socket.it and Backbone.js be able to instantly update the UI of the user and show the new note on their screen? I think that can be called "push notification".
I hope I was clear enough.
Also, is there any alternative outstanding technology to build real time web applications?
Yes Node.js + Socket.IO will do a very good job of this. Node uses an event-loop, this means upon a request it is entered into a queue. Node deals with these requests one-by-one. Traditional web servers deal with a 'Thread-per-request' approach where a thread is created to handle that requests.
The benefit of Node here is that it doesn't need to context switch so often, this means it can deal with these requests very quickly... most likely faster than your PHP server. However Node runs as a single process, on a single CPU core. If your application is CPU intensive it could be that it blocks, meaning the time for each requests will be slower.
However it sounds to me like your application isn't CPU intensive, meaning Node.js will work well.
Decision
If your time is limited, and you don't want to learn a new skill (Node), PHP will be fine. If you have the time I recommend learning Node.js, as it is very strong when it comes to I/O intensive tasks such as a REST API for creating Notes.
Updating the UI
If your intended use is through a mobile device, I recommend using WebSockets but having a fallback such as long-polling. It is possible to update the Client UI using either Node or PHP. However from my experience it is much easier to do so using Socket.IO on Node.js.
Example Updating the client using Node.js / Socket.io
Client-side
socket.on('new-note', function (data) {
placeNewNote(data);
});
Server-side
socket.emit('new-note', data);
Getting Started With Node:
How do I get started with Node.js
Please also note, if you want to build a native Android mobile app which uses WebSockets... you will need to use: Java socket.io client
Using Node.js for both web server and push server is of course the best way. Especially since if you are going to use Node.js anyway then you have to learn it, so learning how to make a web server is only natural (I advice using the most famous Express framework).
Now you can use PHP for web server and Node.js for push server. To make them communicate with each other you would probably want to add Redis to your application. Redis will allow you to push notifications to any client connected to it, like PHP server or Node.js push server (and it scales well). From that point push server will push the data further to the client's browser.
Alternative technology would be for example Twisted server. Of course you'll need to learn Python in order to use it. And I don't know whether it supports WebSockets correctly. I think you should stick with Node.js + socket.io.
I found that I am confusing between web framework and web server.
Apache is a web server.
Tornado is a web server written in Python.
Nginx is a web server written in C
Zend is a web framework in php
Flask/Bottle is a web framework in Python
RoR is a web framework written in Ruby
Express is a web framework written in JS under Node.JS
Can we say node.js is a web server??? I am so confused between web server/ framework.
If somehow node.js is kind of webserver, not webframework (Express does), why do we need to put the whole node.js on top of Nginx server in useful practice??
Question on SO
Who can help???
Kit
Web server
Web server can refer to either the hardware (the computer) or the
software (the computer application) that helps to deliver content that
can be accessed through the Internet.1
The primary function of a web server is to deliver web pages on the
request to clients. This means delivery of HTML documents and any
additional content that may be included by a document, such as images,
style sheets and scripts.
A web server is the basic to delivering requests/pagess to the clients/user on the internet
Web framework
A web application framework is a software framework that is designed
to support the development of dynamic websites, web applications and
web services. The framework aims to alleviate the overhead associated
with common activities performed in Web development. For example, many
frameworks provide libraries for database access, templating
frameworks and session management, and they often promote code reuse.
A web framework uses a webserver to deliver the requests to client, but it is not the web server.
Node.js
Node.js is a platform built on Chrome's JavaScript runtime for easily
building fast, scalable network applications. Node.js uses an
event-driven, non-blocking I/O model that makes it lightweight and
efficient, perfect for data-intensive real-time applications that run
across distributed devices.
But then again you can also create CLI apps so I think you should see it more as a platform to write javascript programs to run on your server(computer) using Javascript programming language instead of just in the browser as in the beginning. I think you could see it as Javascript++ ??
You can also write web server with node.js as you can see on the front page of node.js. In the beginning Ryan said you could put Nginx in front of node.js because of the stabilty of the project. The project was and still is pretty young. Nginx is a proven web server that will keep on running while node.js can crash. Then again a lot of user just use node.js for that.
I would say Node.js is a Runtime Environment or a Runtime Engine.
Probably the best definition I have found so far comes from an article by Rob Gravelle entitled "An Intro to Node.js":
Node.js is part runtime environment and part library for building network applications using server-side JavaScript. It uses Chrome's JavaScript runtime engine to execute JS code directly without the need for the browser sandbox.
Also the PCMAG.COM Encyclopedia provides the following definition of "runtime engine":
Software that certain applications depend on to run in the computer. The runtime engine must be running in the computer in order for the application to execute. It provides common routines and functions that the applications require, and it typically converts the program, which is in an interim, intermediate language, into machine language.
Also the Wikipedia article entitled "Run-time system" declares:
A run-time system (also called runtime system, runtime environment, or just runtime) implements the basic behavior of a computer language, whether the language is a compiled language, interpreted language, embedded domain-specific language, or is invoked via an API as is pthreads.
... A run-time system may implement behavior of tasks such as drawing text on the screen or making an Internet connection. It also typically acts as an abstraction layer that hides the complexity or variations in the services offered by the operating system.
Well, are there any runtime environments (or even software platforms) like Node.js out there? I guess JRE is a good example of such an environment. Node.js and JRE - they have many in common. They all have (a kind of) virtual machine, a class library and a framework to implement many types of applications, including CLI ones.
So, getting back to your question, can we say that Node.js is a web server? Let's change "Node.js" for "JRE" and answer if JRE is a web server. The answer is no.
All that we can say is that Node.js is a runtime environment which one may use to implement a web server. Well, that's my opinion.
Saying node is a webserver is like saying javacript can only run inside a browser, you can say that but it can also do a lot of other things.
NodeJS
[Javascript runtime enviroment(Chrome v8 engine) + Node
Library/APIs]
Can create a web server, can also be described as a
Application server
Express
Web framework (uses nodejs's webserver to serve files)
Nginx
Web server
In production most people use Nginx in front of node server as a proxy server to serve static files and other various elements like caching, routing etc.
I would classify node.js as a server framework, with packages available that can make use of it as an HTTP server, or a WebSocket server, or your own custom protocol, etc.
The reason you might put nginx in front of your node.js server is for HTTP load balancing and reverse proxying across several machines running your server application.
How I feel your pain !
Like many, I found it hard to get to the essence of Node.js because most people only write/talk about the part of Node that they find useful - and the part they find interesting is usually a secondary benefit of Node rather than its primary purpose. I must say that I think it's mad for people to say that Node is just a JavaScript runtime. Node's use of JavaScript - and its selection of the V8 runtime - are simply means to an end, the best tools for the problem that Node's developers wanted to solve.
Node's primary purpose was to make the management of user events in a web app more efficient. So Node is overwhelmingly used on the back end of a web app. Event management demands that something is listening at the server machine for these user events. So a http server must be set up to route each event to its appropriate handler script. Node provides a framework for quickly setting up a server to listen on a dedicated port for user requests. Node uses JavaScript for event handling because JavaScript allows functions to be called as objects. This allows the task to be executed immediately after an asynchronous request (e.g. to a file system, database or network) to be wrapped in a function and referenced as a parameter of the asynchronous request function call.
const mysql = require('mysql2');
const conn = mysql.createConnection(
{
host: "XXXXXXXXXXXXX",
database: "doa_statsbase",
user: "uoalabama_doas",
password: "*************"
});
. . .
. . .
const analyse_bigwheat_farmers = (err, result, fields) =>
{
. . . . .
. . . . .
return data_object;
}
. . .
. . .
let query = "SELECT * FROM us_farmers WHERE acreage > '1000' AND crop='wheat'";
mysql.query(query, (err, result, fields) =>
{
analyse_bigwheat_farmers(err, result, fields);
}
. . .
. . .
. . .
Not many other languages treat functions as objects and those that do may not have an interpreter as efficient as Google's V8 runtime. Most web developers already know JavaScript so there's no additional language learning with Node. What's more, having callback functions allows all user tasks to be put on a single thread without having explicit blocking applied to tasks demanding access to the database or file system. And this is what leads to the superior executional efficiency of Node under heavy concurrent use - the primary purpose for its development.
Today, most Node web applications use callbacks sparingly as JavaScript ES6 introduced the Promise construct in 2015 to handle asynchronous calls more easily and readably.
To help Node users quickly write back end code, Node's developers also organized both a built-in JS library for routine tasks (e.g. matters related to HTTP requests, string (de)coding, streams etc) and the NPM (Node Package Manager) repositary: this is an open source, user-maintained set of script packages for various standard and custom functions. All Node projects allow importation of NPM packages into a project via the established npm install command.
User requests handled via Node will be things needed by the web app like authentication, database querying, content management system (ApostropheCMS, Strapi CMS) updates, etc. All these will be sent to the Node port. (Where analysis of data got from a database is takes a lot of CPU time, this type of process is best put on a separate thread so it doesn't slow simpler user requests.) Other types of user request, e.g. to load another webpage, download CSS/JS/image files, etc, will continue to be sent by the browser to the default ports (typically ports 80 (HTTP) and 443 (HTTPS) on the server machine where the web server program (Apache, NGinx, etc) will handle them in the mode of a traditional website.
[A side note here on request streaming to the server. Since most server machines' firewalls only allow the default ports 80/443 open, it is not usually allowed to directly send a Node.js request with another port in the URL, e.g. https://mynodeapp.com:3001/fetch-members. If one did, the server machine's firewall would simply ignore it as it directly references an illegal port.
Instead one could apply a URL to the request that has no explicit port number but which contains a virtual folder name that identifies the Node.js app, e.g. https://mynodeapp.com/mynodeapp/fetch-members. Then append some server directive code on the .htaccess file like:
RewriteEngine On
RewriteRule ^mynodeapp/(.*) https://localhost:3001/$1 [P]
Node.js requests given URLs in this way will thus find their way to the Node.js server for that web app via the nominated ports for the Node application, i.e. 3001 in the example here.]
So, in practice, Node is principally a framework for rapid server-creation and event-handling but one that replaces only some of the functions of the web server program.
Other non-backend uses of Node simply exploit one or other of its features, e.g. the JavaScript V8 engine. For example, the frontend build tools Grunt and Gulp use a frontend Node.js app to process a build script that can be coded to convert SASS to CSS, minify CSS/JS files, optimize image size or image loading, generate page-state HTML files for refreshing page-states in a single page application site, etc. But this sort of work is really just a by-product use of Node and not its principal use which is for making efficient backend processes for modern web applications.
Web server is something that serves its clients through internet over protocols and Web Framework is something like which we call as compiler. It consists of all the required libraries, syntax rules, etc.
And node.js is a framework!!
I think the problem is that the terminology of "web server" or "web application server" is dominated by the JEE world, and products, that are not as modularized as today's Javascript world of frameworks, which in turn can be combined more or less freely.
I see no reason why a technology, that can serve complex applications over the web, should not be called a web server, or web application server!
If you combine, let's say Nuxt as a frontend, with Feathers as a backend - you'll have a backend serving a REST API and a server-side rendered UI!
Of course, you could (mis)use that to serve static content - then I'd call it a web server, or you could use it to make and serve a full application - then I'd call it a web application server.
It's the combined features or qualities that sum up to serve a purpose - right? - Features like stability, scalability and such are IMHO something that will be added to those technologies, over time. For now, they're pretty new still.
No it's a runtime environment... so it is not a web server yet it does not need one to run. So probably this is why it could be confusing. It can run standalone without needing any webserver because it is a runtime itself but again it is not a webserver.
I just used Node.js for the first time to create a Discord bot. My thought was "Wow, Node.js is a server? I thought it was a JS library!" Or perhaps I could have thought about it as a framework.
Is it a web server? No but you can make one with it.
Is it a server? As in the software that receives queries and serves the result? Yes.
In my case, I have issued the command:
node index.js
And now Node.js is waiting for requests to respond to (via my bot). It's a server, but it isn't serving web pages.
Although Nodejs is treated as a pretty cool, lightweight runtime environment and consists an awesome package manager called npm in node ecosystem. You can spin up a REST API, web application server using express framework which serves to a dedicated port. And it primarily required no web server on top of it.
whereas web server's main agenda is to serve as layer 7 loadbalancer and proxy server. According to Industry Standard most commonly used web server is nginx due to reliability. Although you can configure a http proxy server using node libraries and express framework.
I want to write very simple app, witch monitors states of some sites. I also want to make it in Couchapp style without using any environment except CouchDB.
So the question is how I can make CouchApp send sites requests using some schedule by itself?
BTW, if I fail with this CouchApp, is there some way to make it not involving demon stuff (or cron) on PHP or on even Java? I want to keep it as simple as possible, but not simpler.
rsp is correct. Since CouchDB uses web protocols and Javascript, it has become a victim of its own success.
My rule of thumb is this: CouchDB is a database. It stores your data. I do not expect MySQL to automatically monitor external web sites. Why would I expect CouchDB to do that?
However I agree; CouchDB always benefits from some persistent processing to maintain the data.
Since CouchDB is completely web-based, you could start with a simple dedicated "worker" web browser. Fetch a password-protected HTML page from CouchDB. That page has the Javascript to make the browser query servers and update CouchDB. This could work in the short-term as a quick solution. However browsers impose security restrictions on your queries; and also a browser is not a long-term computing platform.
The traditional way is to run your own client software to do these things. You can either run a dedicated computer, or use PHP, NodeJS, or any other hosting services out there.
2. The
You can't do it in CouchDB alone (CouchApps can only have pure functions without side effects so they can be guaranteed to be cacheable) but you can do it using simple scripts that talk to CouchDB. See this talk by Mikeal Rogers for details on how to do it.