Platform and runtime for the web application server

[debloper]

This issue is a follow up of #7.

If we are to use a dynamic web server, we will have to choose a runtime environment on which the server will run.

There are several platform/framework options off the shelf which are popular, shiny and feature rich (whether based on php, ruby, python or js, or some other language); each one having their own ugh & aha factors and fan-base. And for that reason, trying to discuss which one would be best suited for the purpose generally results in a crusade - the same way "which superhero is the best?" if has ever been asked in a comic book store.

The Frontend team most feels comfortable using Node.js for our purpose, for following reasons:

• Familiarity of language, and not having to learn a new language
• Homogeneity of the tool stack, using single scripting language
• Node.js has a huge community & growing faster than others
• Node.js is a platform, whereas alternatives are frameworks
• Asynchronous streaming I/O, real-time features are easy
• Graceful to system resources, close to static web server
• npm makes using, updating, publishing modules easy
• Can be deployed in wide(st) arrays of environments
• No lack of key features, offered by the alternatives

To propose alternatives, please use comments with relevant data that out-weighs the overall usefulness of Node.js, in favor of the alternative.

[nthomas-redhat]

1. The proposed solutions adds one more layer into the server side processing(UX->Node.js->Rest APIserver) , hence adding additional runtime.
2. I understand that there is a full featured web framework at the REST server layer(Tendrl App documentation#13). What are the additional benefits node.js bring s on to the table which this framework won't provide?
3. Can you list the pros and cons of both approach(with and without node.js)? Its will be great to see few items which can be done only with node.js and not with the other approach

[debloper]

@nthomas-redhat please follow #7 for detailed discussion of pros and cons of using static vs dynamic app server. Skipping the overhead benchmark for the time being (explanation as follows).

As discussed in #7, due to packaging restrictions and being unable to use npm runtime modules in the deployment server, we cannot go with dynamic webapp. Hence, we're sticking with static app & Node.js is out of question at least for the time being.

[mbukatov]

I don't think that the proposal of using node.js considers it's impact on the rest of the project, as I have posted in the tendrl-devel list:

Let's consider the use case for tendrl first.

Tendrl is a storage management tool, with web ui and rest api.
This means that the main user group are storage administrators,
who will install it on either virtual or hw management machine
in their data center. The machine tendrl will be installed on
will run some stable linux distribution, such as RHEL/CentOS,
Debian stable or Ubuntu LTS.

From the upstream community perspective, most contributors would
come from the people which deals with storage technologies in some
way. Their main concern would be implementation of storage
management tasks.

We should evaluate the technologies we use in tendrl with this
in mind. Which means we should ask questions like:

• Are technologies we are going to build tendrl with
  commonly available in stable linux distributions?
• Are technologies we are going to build tendrl with already
  well established in the group of expected contributors?
• Would a particular technology increase cost of tendrl machine
  installation or maintenance?

We are not talking about some simple CRUD web app running in
a cloud environment, which could easily use the latest
technology without any problems, as it doesn't have to integrate
with anything else and doesn't need to be much stable (from the
technology point of view), as it can be easily updated on the fly.

We are talking about the stable storage management system, which
will be deployed in a data center.

So for these reasons, I don't agree with statements like:

• The "adding yet another language" argument doesn't hold here
• a python framework for serving front end would actually be
  "yet another language" scenario

While technology like node.js would be great for a regular web
project, in our case I'm not that sure because of the points I
listed above. We can't propose a technology without a clear
understanding of the cost of maintenance and increased complexity
related to this decision (we can't expect that node.js is already
installed on storage management machine). While you may be
thinking that it's a best choice for your group, you need to
consider impact of this decision to the other people of the
project.

For the same reason, I would suggest to keep the number of languages
and technologies used in tendrl project low.

[gnehapk]

With the reference #7, we are going ahead with static web app and using nodejs only for developer dependency.