Why I'm looking at node.js
I have a low-traffic site with .html, .css, and .js files. For the purposes of this post, a good analogy is a high school course website for learning javascript. I need to add a tiny bit of backend. I need
1) A small db to store users and their "grades." I've used php+mysql on apache for something like this in the past
2) An ability to evaluate user-submitted javascript server-side and grade the result. Node.js has vm and sandbox, so I figure I should turn to node.js (if you have an alternative approach let me know!).
My issue
I've never used node.js before, and I'm a bit confused by the tutorials out there and how they fit into the "old fashioned" web development context. The hello world tutorials start with making a server. For the purposes of having a tiny backend, that sounded like overkill, until I read this, which explained things a little better, saying that (in simplified terms) node.js replaces apache and has added benefits, etc.
In order to have the capabilities of the tiny backend I list above, is a full node.js app necessary? At this point I don't need persistent I/O. I only need the server-side javascript evaluation. Is there a way to have an "old-fashioned server" serve my html with a php backend for a database (bullet 1 above), but then add a small node.js app evaluating the user-submitted javascript (bullet 2 above)? I'm concerned that if, as a beginner, I run an http server in node.js I would be opening security holes that other super-mature web servers smoothly deal with behind the scenes. Also, if I get a hosting plan with nodejitsu/heroku/etc, do they not serve .html automatically? You have to start from scratch with a server?
First , Its not a bad idea to use node.Js to satisfy your requirement,the uniqueness of NODE and added advantage compared to conventional technologies like Apache-PHP is clearly explained in this following video Why Node.JS is better.The notion of NODE being just used for advanced or complex applications is wrong , you can use node for building applications which are very simple to anything of huge proportion.It would be a not so comfortable task for a node beginner to code without using any frameworks , but by using this web application framework called express , you need not code from scratch and its very easy to setup html pages using its simplified html templating language called JADE and route requests,also you can even use your html pages if you are not willing to use JADE for rendering the views of your application .Here are the series of tutorials which would help you Tutorials on beginning with node.js , Basics of expressJS ,
Advanced express tutorials.
The series of videos also have tutorials on getting connected to the no-SQL database MONGO-DB , Mongo is most popular database that is used alongside NODE backend , here is the video which compares mongo and SQL Mongo V/s SQL.
Using Node would also enhance the scalability of your web application , which is very important for any web based services .
Node is not meant to be used alongSide PHP , those are completly two different backend technologies , why would you want to use PHP-Apache and node together when you can very easily build the application using express framework , i suggest go ahead with NODE-Express-Mongo .
Related
We have a web app (CRM type) working on Linux (Debian) with Apache, MariaDb and PHP for the backend, and AngularJS (1.x) for the frontend.
Thinking about a redesign, I need advices on a solution I have in mind, but I'm not sure it would be relevant...
A new website (e-commerce) will come along the CRM and use directly or not (API) the same database.
So my first take would be to put the MariaDb on a dedicated VM. It uses much ressource right now, so much more with another app using it.
Then the CRM and website could connect directly in remote (too risky?) or call an API. I guess the second solution would be better and means I could put my backend PHP part (already working as an API for AngularJS) along with the database, on that new VM.
I guess Debian + Nginx would be a good choice to go with them.
I prefere PHP to handle databases 'cause I'm used to it.
On the other hand I would still have AngularJS alone, a deprecated JS framework.
One thing that was hard to work with, about AngularJS/PHP, was that sometimes I needed to format data for Angular from PHP, and vice versa. It wasn't very clear where to put that formating, 'cause the backend was more about the database and not the frontend, and the frontend more about layout than PHP ORM ans design.
Furthermore, we'd like to keep the CRM as a SPA (Single Page Application).
My take on that would be to go on a MEAN stack, without de M (MongoDB), starting from scratch, just keeping Debian and installing NodeJS, ExpressJS and Angular or another JS framework (Vue, React...).
A hole JS stack to have the same language and gain speed and performance with many little transactions with the server (assets, calls and promises to retrieve data from database). Also to learn more on JS and NodeJS particularly.
NodeJS to create the environnement and a web server, in place of Apache.
Angular (or another) to put data into HTML, and have the less treatments possible.
ExpressJS to be that intermediate part I was talking to, the place where formating can be performed: retrieving data from the views, formating them, sending them to the API, handling the response, formating it if necessary and returning it to the view.
It means I would go from one VM with:
AngularJS (frontend) -> PHP framework (backend) -> Database
To two VM with:
Angular (app frontend) -> Express (app backend) -> PHP API (database backend) -> Database.
What do you think of my use-case and the solution?
There are several benefits to splitting up your services, but almost equally many different solutions, so you need to ask yourself what your goal is. Performance? High availability/failover? You might need a lot of VMs, geo-redundancy, load-balanced VIPs, etc.
You can also look into making containerized services with Docker.
You talk about moving the database onto a separate VM, but that it might be risky. Why? If they are both on an isolated network, it should not be an issue.
If you're looking for stack advice, since you're talking about a full remake, I would recommend something both stable and modern like Laravel + VueJS for the web/API part. You're already comfortable with PHP, and a setup with Nginx will probably be much faster. But of course, there are almost infinite combinations to choose from these days.
As for the "direct or not" DB access: Having a versioned API is always a benefit.
Serving the SPA frontend will require very few resources, so your bottleneck will be between the API backend and DB. You can make it scalable by putting the API behind a VIP and load balance with something like HAProxy/Nginx.
i want to create a website based on node js and mysql , but i've read that there is a framework called express for node js , and i'm wondering if i must to use such kind of a framework to create a decent website or it is possible without it and just work with pure node js.
No framework is required. You can write a full-blown web server using only the http module or if you really want to write everything yourself, you can even do it with only the net module.
It's really about what is the most effective use of your time and skill as a developer. Except for academic or pure learning experience reasons, if you're just trying to accomplish a task as efficiently as possible and free, pre-existing, pre-tested code exists that makes your job easier, then that's a better way to go.
For example, if I need to do a file upload from a browser to my back-end and the data is coming in as the multipart/formdata content-type from the browser, I have zero interest in reading and learning the multipart/formdata RFC then writing my own code to parse the multipart/formdata content-type. Pre-existing, already tested code exists to do that for me and I'm adding no value to the goals of my project by re-implementing and then testing it all myself. Therefore, I'd like to use a pre-built module that does all that for me. I can just configure the right library on the right route and out plops my uploaded file in only the amount of time it takes to understand the interface to the 3rd party module and how to use it properly.
This is where Express comes in. Not only does it offer a useful set of features and architecture for configuring routes, installing middleware, sending responses, using template engines, handling errors, etc... but there are also thousands of third party modules that are built to hook into Express and it is easiest to use them if you're using Express as your core framework. Some of these modules could be used outside of Express, some cannot - it really depends upon how they're designed and what Express interfaces they do or don't use.
Also, Express is fairly "un-opinionated" and fairly "lightweight" which means it doesn't force you into a particular methodology. It just offers you easier ways to do things you were already going to have to write code for yourself.
Look at it this way. When you get node.js, there are thousands of APIs that offer lots of already tested things such as a TCP library, a file I/O library, etc... Those are frameworks (in a sense) too. You don't have to use them either. You could rewrite whatever functionality you need from scratch. But, you wouldn't even think about doing that because tested code already exists that solves your problem. So, you happily build on top of things that are already done.
One of the BIG advantages of coding with node.js is getting access to the tens of thousands of pre-built modules on NPM that already solve problems that many people have. Coding in node.js with a mindset that you will never use any outside modules from NPM is throwing away one of the biggest advantages of coding with node.js.
could you tell me what are the Routes used for in frameworks?
A route is a URL that you wish for your web server to respond to. So, if you want http://myserver.com/categories to be URL that your server responds to, then you create a route for /categories so that you can write code for what should happen when that URL is requested. A framework like Express allows you to create that route very simply with just a single statement such as:
app.get('/categories', function(req, res) {
// put code here to handle that request
});
This is just the tip of the iceberg for what Express supports. It allows you to use wildcards in route definitions, identify parameters in urls, create middleware that does prep work on lots of routes (such as check if the user is logged in), etc...
You don't have to use a framework but it is recommended to use one of them since frameworks like Express make your life easier in many ways. Check this: What is Express.js?
Yes you CAN write a Node.js-based backend without any back end implementation framework such as Express. And if you are using Node.js for the first time without any previous experience of asynchronous coding, I'd advise against using Express, KOA or other Node implementation frameworks for your simple learner apps (e.g. those needing things like register/login form processing, logout button, user preference updates to database, etc) because:
(1) Node.js is a core skill for JavaScript back ends.
Stupid analogies between server tasking and restaurant waiters are no use to a real web engineer. You must first know what exactly Node can/cannot do in the server CPU that makes it different to most other back end technologies. Then you have to see how the Node process actually does this. Using Express/KOA/Hapi/etc you are sometimes effectively removing the mental challenges that come with a Node back end. Any time-saving is achieved at the expense of gaining a proper working understanding of what Node is and how it really operates.
(2) Learning Node.js and its asynchronous coding is hard enough without the added complication of coding with an unknown framework like Express/KOA that assumes users' familiarity with JavaScript constructs like callback functions and Promises. It's always better to learn something in isolation so you get the essence of its individual effects, rather than the overall effects if used with other packages/frameworks. So many of these Node.js Express tutorials are the software equivalent of learning to make a cake by watching Momma do it. We can copy it but we don't know how or why it's working. Professional coders can't just be good copycats.
(3) Available learning tutorials using Express often drag in other technologies like MongoDB, Mongoose, Mustache, Handlebars, etc that make learning Node.js even more awkward still.
(4) A share of basic web apps can be written more efficiently with Node.js, custom JS and existing JS modules imported off the npm repository rather than with Express.
(5) Once asynchronous coding and the JavaScript constructs available to assist with it are understood clearly, pure Node.js apps for basic tasks aren't that hard.
(5) After you do get your head around Node.js and can get basic web app functionalities working using server-side JavaScript constructs, you can then judiciously start to explore Express/Hapi/KOA/etc and see what an implementation framework can do for your workflow when doing larger projects needing numerous functionalities. At this point you know what Express code should be doing and why it is done the way it is.
Node.js has become the back-end technology of choice for most small to medium scale web applications over the last 10 years. It is also the major reason why the JavaScript language has evolved from a mere front-end scripting tool with a limited set of Java-aping constructs to the innovative and comprehensive language that it is today. It is also the most popular language in use today. Investing time in understanding the Node server framework, and the latest JavaScript constructs used in Node, is time well spent. Implementation frameworks such as Express, KOA, Hapi, Sails, etc have great benefit when writing more elaborate back ends on the Node.js platform. But all these implementation frameworks are predicated on the behaviour patterns of Node.js. So unless Node itself is understood first, the full utility of Express/KOA/Sails/etc will never be enjoyed.
Try here for the pure Node.js.
I'm new to the full stack javascript application development, have read a lot of posts and documentation to all sorts of things but am a bit stuck on the following issue:
There are two frameworks that seem to offer quite similar functionality but are never contrasted against one another on the internet (as far as I could tell)
SailsJS - server side MVC framework built on Express
BreezeJS (+AngularJS) - client side MVC
Apparently I can combine Sails with Angular, there are a few attempt in NPM but none using Breeze in addition, is that due to redundancy or is it just a stupid idea?
I was thinking of developing a SPA that has computation intensive backend processes ( e.g. machine learning on large data sets ~ millions of mongo documents ) on something like
Mongo - Node : { Express - Sails } - Breeze - Angular
I'm looking for feedback on whether this kind of stack (particularly the Breeze / Sails part) is a bad idea or not. Also I'm really thankful for any advice / links to advice on javascript full stack architecture design decisions.
Thanks!
Basically, all the software you have mentioned can be used in one product. It's the important though to understand the purpose/strength of each component:
1. MongoDB
This one is pretty clear: database engine.
2. Node.js
This one too: server-side Javascript which will power your API.
3. Express.js
Now it's getting more interesting. Express is a server-side web-application framework for Node.js, but a very minimalistic one, which means it provides some basic functionality, no hidden magic and other fancy stuff.
4. Sails.js
On the contrary, Sails provides a lot of magic, starting with the API out of the box and ending with sockets. Even though it's built on top of Express, Sails is a server-side Javascript framework which follows a completely different approach, with convenience over simplicity. If we talking about a SPA, then the most useful thing Sails has to offer is, definitely, API out of the box: you'll be able to get it up and running in less then 5 minutes.
5. Angular.js
Here we are getting onto the client side. Angular helps you better organize your client-side Javascript and easily perform some pretty complex tasks in the browser. And, of course, Angular (or a similar framework, like Backbone, Ember, Knockout, etc.) is a must-have nowadays if we are talking about rich client applications.
6. Breeze.js
Finally, Breeze provides you with a way to organize / access data from your thick client Web application. Whether you are using Angular, Backbone or Knockout, Breeze will help you manage your data in a way similar to ORM / ActiveRecord concepts.
So, all these components can easily work together, no doubts (sometimes people are talking about MEAN, MEANS, BMEAN stacks, where every letter is a first letter in the name of a framework / component). But ultimately, it's up to you to decide how many of them you should use in your product. As an example of approach, you can start with Mongo / Node base, and then choose necessary frameworks by asking yourself for the each one, whether it simplifies your life (especially, long-term-wise) or complicates it.
I have just began working with node.js and have gotten the hang of the basics.
Right now I'm trying to see if I can create my very first real-time web application using node, during my research I have seen modules like "express.js" and "socket.io' pop up very often as frameworks used for node web apps.
My question is; do I really need to learn these two in order to make real-time production level node.js applications?
Also, what other things should I look at? I heard about tempting engines being an asset, but 'm not sure of their use.
You don't need to use any modules but you give up a lot when you don't. Express.js is a great place to start. It has good documentation and makes the whole process much easier. I use jade and stylus for my css and templates.
Socket.io is again optional but if you are doing real-time updates it sure makes things a lot simpler. Socket.io deals with all of the browser differences with one api and the client will always connect using the fastest technology.
Socket.IO is mandatory for real-time applications. If you have to implement a chat, a broker, a server status tool or something like that and other natural real app, you must consider use this Node package. If your site do not require something real-time bi-directional message handler you just avoid the usage of this tool.
In case of all application needs to be made in real-time situation, you can see a more appropriate framework to approach it, like Meteor
I've build several websites using PHP and mySQL as backend, and believe that I'm fairly familiar with both. However during research for my new website I've come across node.js and mongodb (and socket.io, since the site is gonna contain a chat).
I've decided to use node.js and mongodb to run the chat - but don't know if I should just do the entire site with those two things?
Since I'm gonna run a node server anyway should I just run another (seperate) one hosting the website? Or is that an bad idea? - is it stable?
I could do the programming in PHP and still be using mongodb - but wouldn't node be way faster?
And another question:
I've planned to use ajax to handle all the posts to the page - but since I'm allready using socket.io to the chat - should I do all my post request using that?
For the ajax I've planned to use jQuery (also for all frontend effects).
don't know if I should just do the
entire site with those two things?
If you want to learn node.js then there is nothing better than coding it.
Since I'm gonna run a node server
anyway should I just run another
(seperate) one hosting the website?
You can use existing server and run your node.js app on other free port(o). I think for learning node you don't need to have dedicated machine.
is it stable?
Even versions of node.js are stable releases, however until there is 1.0 with feature freeze there could be breaking changes to its API.
I could do the programming in PHP and
still be using mongodb - but wouldn't
node be way faster?
It most probably (and definitely) would.
I've planned to use ajax to handle all
the posts to the page - but since I'm
allready using socket.io to the chat -
should I do all my post request using
that?
I would recommend stick to MVC model and use express since you can get into lot of time consuming troubles if you would use socket.io for classic stuff. Socket.io is namely for real-time functionality and things related to that.
There are already some solid web frameworks for node.js, in particular check out Express. Here's a really good article outlining some lessons and experiences from building a node.js website:
What it’s like building a real website in Node.js
Regarding your second question, it's probably still best to use AJAX handlers and HTTP with jQuery. I'm not sure that jQuery supports callbacks over raw TCP sockets.
node.js + express + jade + stylus + jQuery is my preferred environment.
Using forever to auto restart the server I've never had any real up-time issues even when I have bugs crashing the server on a regular basis.
As for socket.io + jQuery, they do get along fine, but it's just not as natural as the express + jQuery combo. I'd stick to making ajax calls for most things.
Node.JS can still be a little wild west like, but its improving. It is a very different model from coding in php, but it is very well suited for a lot of websites. You'll probably want to do the thin server (expose a REST API and your websocket endpoints) with a fatter client using something like BackBone.js to keep interactions clean.
The big win from doing the whole thing in node is that you will not have duplication of code between php and js for dealing with the DB or any other services required by both. Node.JS is also fantastic at handling tons and tons of concurrent requests.
Good Luck