I am relatively new to mobile development and would like to know further information about this specific topic.
I am working on a React Native based mobile application and am now getting around to implementing the back-end for this application. I will need to send data back and forth from the client (the mobile application) to the server (a cloud server). I am aware I can accomplish this with technologies such as a MongoDB database or a Firebase database, however, I would like to try to implement this on a personal cloud server.
How would I go about establishing a connection to a server in node.js so that I may send and receive data?
Thus far, I have looked the node library Express.js, but I am unsure if this is of any relevance as to what I am looking for in terms of a solution to what I am trying to achieve.
First of all, I think you need to have a backend project for making your backend you choose Nodejs
Node JS is a fast JavaScript runtime environment that we use to build server-side applications, but it does not know how to perform serving files, handling requests, and handling HTTP methods, so this is where express js comes in.
Express JS is a Node.js framework designed to build API's web applications cross-platform mobile apps quickly and make node js easy.
Why Express JS?
Express was created to make APIs and web applications with ease
It saves a lot of coding time almost by half and still makes web and
mobile applications are efficient.
The reason behind creating an express framework for node js is:
Time-efficient
Fast
Economical
Easy to learn
Asynchronous
After completing your backend project with either postgres or mongodb database connection and node js you can deploy it to your cloud server and access it from the apis form the front end mobile or web applications.
Another thing I want to mention you can also create some web pages using node handlebars as well.
I currently manage a cluster of VMs on a number of dedicated hosts to provide apache, nginx and node live and development servers. This of course requires constant and time consuming maintenance to ensure security and reliability. I've found more time is spent looking after this platform then coding new and exciting projects. So I've been looking into the Google App Engine to remove the need of managing any VMs but I'm struggling to work out how to get it to function for me!
Currently I find myself developing mostly in Angular (v4-5) for my frontend and nodejs for backend. My development nginx server powers my angular apps and routing to ng-serve and to a separate vm that runs my node apps. I use PM2 to manage the apps on both servers.
This works great! I can code locally push my changes via an rsync script to the servers, the app restarts and changes updated. More importantly, I can affectively code between the front and backend! When ready I can comfortably switch the code to the live servers with little effort - nice!
This is where I am struggling...
I can't seem to work how I would develop and publish versions of both the front and backend code in one App Engine project.
Is this possible? How would I go about deploying/publishing both aspects?
Would I be better having two projects such as example.com & api.example.com? If so, can I get the two projects to talk to one another when developing?
I have and can create a angular/nodejs app in the App Engine but I can't work the basics of front and backend development in this managed service.
I'd like to use the great features of the App Engine such as versioning, easy scaling and importantly deployment of apps and updates. Also, to move all my websites including some older ones in PHP to the App Engine.
Any help surrounding this would be much appreciated. Thanks!
As #Yandrak3 suggested, a microservices architecture is what you need. But keep in mind that that document relates to the App Engine Standard environment which does not support Node.js as a runtime environment. But keep the microservices architecture in mind when deploying to App Engine Flexible.
On backend and frontend
Frontend and backend are no longer used to describe the presentation layer and the data access layer of an App Engine application. The only reference in the documentation is here. The (VM) instances managing a service of your app which are configured with automatic scaling are considered part of the frontend infrastructure, while the ones configured with manual scaling are considered backend infrastructure.
The reason for this is that automatic scaling is one of App Engine's
great features [...] easy scaling,
automatically presenting your app's frontend in a manner scaled with the number of external requests incoming to your app.
Manual scaling is more suited for backend operations, where you might want to run operations dependant on the state of the memory over time, or other scenarios. You can find some more information on scaling types here. Keep in mind that this latter document is under App Engine Standard documentation and it includes basic scaling, a feature not available in the App Engine Flexible environment.
On services and versioning
In your case, your frontend and backend modules of your application will become two separate services in App Engine Flex. For each service you can deploy multiple versions. More, explained here.
Communication between services, in this case between your frontend and backend, can be done through HTTP requests between them.
If the next question is how HTTP requests from users reach the appropriate version of a service (or a service), check this document.
To deploy multiple services, you will use the same commands and you will separate each deployment and service through their afferent configuration file, app.yaml.
Your question requires a response with a pretty wide (and deep) spectrum of concepts. Hopefully, this answer is good to start with.
I have recently started the development of an App that was intended for the web, using Express.js + MongoDB to define a RESTFull Interface, all this is coupled with an HTML5 frontend that uses AJAX to receive and write data.
The first couple of beta-testers reported that they'd not be ok with the app being a web-application and would much rather have everything on their own computer for security reasons (personal data is handled).
Now, I know that there are a couple of ways to make a Node.js application appear like a native app see Packaging a node.js webapp as a normal desktop app [closed]. I already tried NW.js but I can't seem to find an option to actually run the express.js part of the application within the limits of NW.js.
To my questions:
Is there a way to run a restful api programmed with node & express
within NW.js?
Is it possible to run MongoDB inside that container?
If both or either one are not true, is there a framework that supports
running express & mongodb as a desktop application with my app?
I would focus the effort you would put into porting your app into making those same customers feel comfortable with your security measures for protection their data in the existing web-application format.
But if you really want them to run it locally then they probably need their own Mongo installed. Instead of a full blown mongo install I found NeDB. It implements the same Mongo api's so you should be able to port easily.
https://github.com/louischatriot/nedb
Embedded persistent or in memory database for Node.js, nw.js, Electron
and browsers, 100% Javascript, no binary dependency.
I'm making an app that will have:
iOS and Android apps
A web-based "dashboard" to display data gathered from the mobile apps
The app requires that end-users create an account with us (we mostly likely will NOT use Facebook/Twitter logins).
Everything is/will be hosted on AWS using EC2/RDS/S3 (All encapsulated in Elastic Beanstalk)
| Web Browser | <----> | sails.js app | <-------> |actionhero.js API|
⬆︎
⬆︎
| Mobile app(s) | <-------------------------------------/
So far, I've built most of the backing API in actionhero.js, hosted on AWS.
It made sense to me to separate the API and the web app, because there web app is only for a small subset of users -- I'd expect 50x the traffic from our mobile apps over the web app.. We could scale the API to server the mobile users without unnecessarily scaling the sails.js app.
My questions are:
(biuggest unknown) How should I handle authentication? The sails.js app needs to be able to make requests to the API, and so do the mobile applications.
I was looking at the oauth2orize node module for creating our own Auth server, but it is designed for Connect/Express, so I don't think I could leverage it in the actionhero.js-based API.
If the solution is to create an OAuth server, am I supposed to host that on its own EC2 instance?
(AWS-specific question) I don't fully understand the use case for creating what AWS describes as a "worker tier" enviornment. Would there be a reason that the API would fall into that category?
If I want to run a data querying and aggregation task, I would create a separate node process for that, correct? If so, would that background worker have to exist on its own EC2 instance?
Sails.js and Actionhero.js both provide heavy support for socket.io. Should communication between the Sails app and my API happen over a persistent WebSocket connection? Will that scale if I need to create new instances in the future?
This seems like a fairly typical pattern; I'd like to hear if there are any big red flags in this design, before I paint myself into a corner. :-) THANKS!
Bonus question (specific to AWS Elastic Beanstalk)
Will I create separate "Applications" for the sails.js server and the API server? It looks like that's the only way to set it up, anyhow, but I want to make sure.
We have used node and beanstalk for a couple of applications now. For authentication, you can create an account for the user when they first access the app, and store the account id on the device. If you want them to be able to log in from multiple devices, you'll need to provide some kind of way of them identifying themselves, which is either id/password, or using Facebook. It's not that tough to set that up. Use session to allow them to log in and stay logged in. We generally just store the user id in the session.
A worker tier is for something you want to decouple from your app, something that you want to do that you don't need to know whether it succeeded/failed. A notification server is a prime example. You send the info for the notification into an SQS queue, that then gets sent to the worker tier, that does the work. We are just trying to figure this out now.
A big aggregation process, yes, I'd take it elsewhere, so it's not eating up your production server(s). You might want to create some data aggregation ongoing, as transactions are saved, so it accumulates. Big rollups after the fact can be time consuming and fragile.
Sounds like yes, they would be seperate applications.
A good tip. We use grunt to create the zip files for the app. It's a node batch tool. We check the latest info out of SVN, clean it up by doing things like removing .svn directories, apply our configuration into the config files by doing simple string replacement, then zip up resulting output. This then gets loaded into beanstalk. This takes all the guess work and time out of actually doing a new deployment. We can get a new build up in minutes that way.
Beanstalk can be very frustrating. When it fails, it's not very good at telling you why.
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.