My question is rather straightforward. I started developing quite a large project and realized that node.js COULD be a viable solution. Since I am still new to node and therefore not in the position to determine if it's the right thing for me, I decided to ask here.
The project: It's basically an administration solution for gameserver providers. It includes both a web administration panel as well as server components to control everything.
My doubts are if I should use node for the panel.
It will require life updating of data (where sockets could come in handy) and we plan on developing it as a "one-page" kind of app.
Having it node means it would be able to perform tasks asynchronously and on it's own (instead of, say, php and cronjobs)
It will be distributed. Making it node would make this easy. No dependencies besides node, and a simple "npm install".
It will have multiple people connecting to it and using it at the same time.
Will node be able to handle these multiple connections well? Performance wise, will it be a good choice?
Will node (and maybe Derby) suffice to build a good web panel?
Am I right about any of the points I made, or did I miss something?
Thanks for the help!
Sincerely
-Antariano
Well you did answer yourself for some of the questions. Thanks to the asynchronous tasks node can take quite a load of connections so it should handle your app. I don't know Derby, but express is also good for your task.
Also when one node server will be insufficient you can always deploy next one and just create some communication between them. Since node is lightweight it can do the job.
Will node be able to handle these multiple connections well?
Yes.
Performance wise, will it be a good choice?
Yes.
Will node (and maybe Derby) suffice to build a good web panel?
Yes.
Am I right about any of the points
You are right with all of them.
I think node will be sufficient for this job.
Related
I am relatively new to node js servers.
I have an Nginx server with multiple node js scripts running (Reverse Proxy).
Since all the scripts are very different currently I am running multiple node js scripts.
eg
https://page.com/stuff1 -> stuff1.js (node js server running on port 81)
https://page.com/stuff2 -> stuff2.js (node js server running on port 80)
I like how the code in each file is simpler and how if I wanted to I can turn off one page without affecting the other.
My question is if it is better to concentrate all the node js scripts into one or if I should stick to what I am doing now.
I have done some research and the questions I come across seem to be about jquery and plug-ins and not the server itself. They also seem to focus on sending the files to the client.
Thank you for reading.
Your question is valid, and this scenario may serve in some situations :)
About this part:
My question is if it is better to concentrate all the node js scripts
into one or if I should stick to what I am doing now.
Might be more complex to answer, as it really depends on your use case, and where and how you want to use your applications.
In some cases, it's just better to write a clean, and maintainable code using some design and architectural patterns like the "clean architecture", or the "hexagonal architecture". And with this, you may have your application running behind one Node.js server, in one code base but it can scale and serve multiple users while keeping the code easy to maintain and debug. And if you want to turn off a page, you can just "unregister" the routes from your Node application.
In other cases, your approach might be better, so you would split your application into smaller applications and put them behind a reverse proxy, this allows you to maintain them separately which might be beneficial, especially if you would work in a bigger team. Also, now you may have the applications running on the same server, it's much easier to move them to different servers, for more scalability and better fault tolerance, and you only do the necessary changes on your Nginx configuration and possibly your server's firewall configs.
And of course, both approaches have cons: You may not want to handle a big code base if the application is too complex, and you don't want to scale a whole application just to serve more traffic on coming to an isolated module of your application.
On the other hand, you may not want to deal with the issues that come with making your application distributed. You would have (in this case) two applications sharing resources on the same server which may cause challenges when you scale.
Edit:
You may want to have a look at pm2's process management as it should help you manage multiple Node.js processes.
I'm coming from a java background, And I recently needed an app with realtime data and push. So i'm thinking of using meteor since it seems as an easier way to use node.js.
My question is do I need to learn node.js before starting with meteor ?
and is meteor suitable now for a production application (I know it haven't reached 1.0, but from your experiences what do you think)
Thank you.
Meteor does not require knowing node.js in order to effectively build applications, as long as you stay within the boundaries of what Meteor abstracts away for you.
Meteor is very young, but "production-ready" depends on what exactly the application is. Would I write a real-time banking application with it right now? No. Is it ready for MVPs, demos, and straightforward consumer applications? Sure, as long as you understand its limitations.
I have been recently quite seduced by the 12Factor app as it is strong guidelines I should force myself to follow.
So on a project I'm working on currently I have decided to use them.
Though I am having a doubt about my code structure:
I have a website that will just create new jobs and people can consult the results of the jobs there. The jobs are queued into a distributed queue (ftm Redis) and workers take each job and execute them.
I decided to split the codebase in 2:
the actual site which will queue jobs and users will access the result.
the workers that are totally autonomous.
There is a node package in the middle which encapsulate the communication (queueing etc) and the only communication between nodes is through Redis.
So I just wanted to be sure that this was still coherent with 12factor as I am building a distributed system.
If not should I build everything in one codebase with a launch script which either launch one or the other?
Thx for your help
Keep it simple, but no simpler then makes sense. If it is simpler for you to keep it all in one codebase start out that way. Development is an iterative process, assume you are doing it wrong and be prepared to change things when they start to get unwieldy.
Premature optimization (or abstraction) of your code (or workflow) is always unwise.
I decided to split the codebase in 2
Well, the first item on the 12 factors website says "One codebase tracked in revision control, many deploys"
From your description, I don't think it's possible to tell how well you followed the guidelines.
I'm writing a piece to a project that's responsible for processing tasks outside of the main application facing data server, which is written in javascript using Node.js. It needs to handle tasks which are scheduled in the future and potentially handle tasks that are "right now". The "right now" just means the next time a worker becomes available it will operate on that task, so that bit might not matter. The workers are going to all talk to external resources, an example job would be to send an email. We are a small shop and we don't have a ton of resources so one thing I don't want to do is start mixing languages at this point in the process, and I already see that Node can do this for us pretty easily, so that's what we're going to go with unless I see a compelling reason not to before I start coding, which is soon.
All that said, I can't tell if there is a compelling reason to use an AMQP based server, like OpenAMQ or RabbitMQ over something like Kue or Beanstalkd with a node client. So, here we go:
Is there a compelling reason to use an AMQP based server over something like beanstalkd or redis with Kue? If yes, which AMPQ based server would fit best with the architecture that I laid out? If no, which nosql solution (beanstalkd, redis/Kue) would be easiest to set up and fastest to deploy?
FWIW, I'm not accepting my answer yet, I'm going to explain what I've decided and why. If I don't get any answers that appear to be better than what I've decided, I'll accept my own later.
I decided on Kue. It supports multiple workers running asynchronously, and with cluster it can take advantage of multicore systems. It is easily extended to provide security. It's backed with Redis, which is used all over for this exact thing, so I know I'm not backing my job process server with unproven software (that's not to say that any of the others are unproven.)
The most compelling reasons that I picked Kue is that it provides a JSON api so that the client applications (The first client is going to be a web based application, but we're planning on making smartphone apps also) can add jobs easily without going through the main application facing node instance, so I can be totally out of the way of the rest of my team as I write this. I don't need a route, I don't need anything, and it's all provided for me so I don't need to write anything to support this. This has another advantage, with an extention to provide l/p security only authorized clients can add jobs, so I don;t have to expose my redis server to client applications directly. It also has a built in web console and the API allows the client to pull back lists of jobs associated with a given user very easily, so we can show the user all of their scheduled tasks in a nifty calendar view with 0 effort on my part.
The other compelling reason is the lack of steep learning curve associated with getting redis and Kue going for me. I've set up redis before, and Kue is simple and effective.
Yes, I'm a lazy developer, but I'm the good kind of lazy developer.
UPDATE:
I have it working and doing jobs, the throughput is amazing. I split out the task marshaling logic into it's own node instance, basically all I have to do is deploy my repo to a new machine and run node task-server.js to scale out my workers. I may need to add in some more job searching calls to Kue, because of how I implimented a few things, but that will be easy.
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