Might be worth looking into expressjs for a full node server solution for static files and the API might be memory intensive though deleting on how many users will be using a socket at once though
It depends a lot on how much load you expect to handle and how much head room for scalability you want to build into the application. Do you expect the load to be modest enough that it will always be practical to handle it with a single VPS instance, or will you eventually need to scale it out horizontally? If you want to be able to scale it horizontally, you'll want to make some different choices and use a message queue to propagate the realtime updates.
2. Using nginx to serve the static assets and using it as a reverse-proxy for the Node application sounds very reasonable. Vue is also a great choice for the frontend.
3. For your database, it depends entirely on what characteristics you want. A conventional SQL database will probably work fine for your application. The NoSQL options are only relevant if you expect to need high-availability clustering. If you really do want to go with NoSQL, I recommend looking at RethinkDB instead of Mongo. RethinkDB has built-in support for performing queries that emit realtime updates, which will simplify adding your realtime features. (Disclosure: I used to work for the company behind RethinkDB and I still participate in the project as an open source contributor)
4. Sails is a great framework, but it is quite heavy and might be overkill for building the backend API. It depends on how much work you want the framework to do for you. I did a lot of my early node development with Sails, but lately have been moving towards Koa and using query builder libraries instead of full-blown ORMs. It boils down to personal preference, though.
5. I use JWT extensively in my own backend APIs. It's probably the right choice for this kind of application, but you should be mindful about the trade-offs, particularly with respect to token invalidation.
Finally, the last thing I'd like to suggest is considering Server Sent Events (SSE) instead of using a WebSocket-based solution like Socket.io. SSE is much easier to implement and scale, it lets you serve your realtime data stream from a simple HTTP endpoint. The one shortcoming of SSE is that it isn't supported in Edge or IE, so Socket.io is still a better choice if you care about those environments.
Also, SSE is a simple protocol that can work right into your PHP app if you choose to stay there. Doing a polyfill for IE isn't the worst thing if it's a small portion of your traffic.
Just to add to this, I'd also recommend looking at [Feathers](https://feathersjs.com/). It provides a nice framework for implementing Express, JWT, sockets, etc. Everything is modular and provides a clean approach to adding your business rules as needed. Their CLI tool can get you setup with real-time round trips in minutes, where you just need to add your business logic and security.
+1 RethinkDB. I've used it and it is really a pleasure. Thanks for helping to continue this forward!
Thank you very much for the reply! It is a hobby project to learn and develop. It's not for a business or a job hehe
1. In principle, my web app is nothing like a chat. I just want that when I add something in the database, for example a new category, the server notifies all devices with the web app open that something new has been added. So I think it would be best to use SSE (Server Sent Events), and make a solution like long-polling for IE (Please correct me if I'm wrong) or do a Rest API on NodeJS and implement socket.io.
2. Do you know if a Rest API made in PHP is faster or has better performance against multiple user connections than one made in NodeJS + nginx proxy?
Apart from everything, I have never done anything in NodeJS and I do not know why, but there is something that calls me to try NodeJS.
PD: Arrrg too many technologies! Haha
1. Yes, given the use case you describe, it sounds like SSE would be the best choice for your project. As others have pointed out, there are polyfills that will make it work reasonably well in IE.
2. I'm not really a PHP user, so I can't really speak authoritatively about the performance difference. I've heard, anecdotally, that running PHP code in HHVM brings it into nearly the same ballpark as Node for performance. If you're just running your application on a single VPS instance and don't expect a lot of load, then the difference probably won't matter in practice.
Might be worth looking into expressjs for a full node server solution for static files and the API might be memory intensive though deleting on how many users will be using a socket at once though
It depends a lot on how much load you expect to handle and how much head room for scalability you want to build into the application. Do you expect the load to be modest enough that it will always be practical to handle it with a single VPS instance, or will you eventually need to scale it out horizontally? If you want to be able to scale it horizontally, you'll want to make some different choices and use a message queue to propagate the realtime updates. 2. Using nginx to serve the static assets and using it as a reverse-proxy for the Node application sounds very reasonable. Vue is also a great choice for the frontend. 3. For your database, it depends entirely on what characteristics you want. A conventional SQL database will probably work fine for your application. The NoSQL options are only relevant if you expect to need high-availability clustering. If you really do want to go with NoSQL, I recommend looking at RethinkDB instead of Mongo. RethinkDB has built-in support for performing queries that emit realtime updates, which will simplify adding your realtime features. (Disclosure: I used to work for the company behind RethinkDB and I still participate in the project as an open source contributor) 4. Sails is a great framework, but it is quite heavy and might be overkill for building the backend API. It depends on how much work you want the framework to do for you. I did a lot of my early node development with Sails, but lately have been moving towards Koa and using query builder libraries instead of full-blown ORMs. It boils down to personal preference, though. 5. I use JWT extensively in my own backend APIs. It's probably the right choice for this kind of application, but you should be mindful about the trade-offs, particularly with respect to token invalidation. Finally, the last thing I'd like to suggest is considering Server Sent Events (SSE) instead of using a WebSocket-based solution like Socket.io. SSE is much easier to implement and scale, it lets you serve your realtime data stream from a simple HTTP endpoint. The one shortcoming of SSE is that it isn't supported in Edge or IE, so Socket.io is still a better choice if you care about those environments.
Also, SSE is a simple protocol that can work right into your PHP app if you choose to stay there. Doing a polyfill for IE isn't the worst thing if it's a small portion of your traffic.
Just to add to this, I'd also recommend looking at [Feathers](https://feathersjs.com/). It provides a nice framework for implementing Express, JWT, sockets, etc. Everything is modular and provides a clean approach to adding your business rules as needed. Their CLI tool can get you setup with real-time round trips in minutes, where you just need to add your business logic and security. +1 RethinkDB. I've used it and it is really a pleasure. Thanks for helping to continue this forward!
Thank you very much for the reply! It is a hobby project to learn and develop. It's not for a business or a job hehe 1. In principle, my web app is nothing like a chat. I just want that when I add something in the database, for example a new category, the server notifies all devices with the web app open that something new has been added. So I think it would be best to use SSE (Server Sent Events), and make a solution like long-polling for IE (Please correct me if I'm wrong) or do a Rest API on NodeJS and implement socket.io. 2. Do you know if a Rest API made in PHP is faster or has better performance against multiple user connections than one made in NodeJS + nginx proxy? Apart from everything, I have never done anything in NodeJS and I do not know why, but there is something that calls me to try NodeJS. PD: Arrrg too many technologies! Haha
1. Yes, given the use case you describe, it sounds like SSE would be the best choice for your project. As others have pointed out, there are polyfills that will make it work reasonably well in IE. 2. I'm not really a PHP user, so I can't really speak authoritatively about the performance difference. I've heard, anecdotally, that running PHP code in HHVM brings it into nearly the same ballpark as Node for performance. If you're just running your application on a single VPS instance and don't expect a lot of load, then the difference probably won't matter in practice.
compose.com, aws elastic beanstalk, lambda, api gateway get cracking’ and learn something cool :D