I was making a thinking exercise about how could I deploy a chat service like WhatsApp or Slack (just wondering), so people could really use it. You need two main parts, the client software (e.g. the app running on the smartphones), and the server software. So how would you develop the server-side code and make it work?
The first idea that came to me was the classic hosting service, but it cannot be the simple "web hosting service", probably because something like this should be programmed at a lower level and not working with HTTP requests and responses. Maybe using specific server-side technology like Node.js (any other suggestion?) to manage different type of requests at lower level, let's say at the layer where TCP lives, would be a better solution.
So I heard about the Amazon Web Services (AWS), which is not classic hosting, it's a cloud computing service. The problem is that I don't know exactly how this works. Could I deploy a server-side application that works at that low level of networking and also makes requests to databases? Would it be difficult to offer this kinf of service using AWS?.
I would like to hear all your opinions about any aspect of this. Would you use other kinf of technology on the server? What do you think about AWS, and if you would think it's a good option, where can I get some info to learn how to use it?
Server Side Code
You can create a chat service backend using NodeJS + express(or Hapi) to cater input Http Requests.
For Hosting: Cloud servers are pretty available these days and allow you to scale if your app grows with time.
Database:
if you already have your DB available (cool) just use ORMs ( like (Sequelize) which provides easy interaction of Nodejs service with your DB. (I have used MySQL + Sql Server + Oracle)
If not, you can create a new DB (MySql- free on your hosting server (cloud?)
I used Microsoft Azure to host a Nodejs(+ Hapi.js) Backend Service ,to be consumed by my mobile application, over the internet.
Azure gives you $200 free credit which is sufficient for you to try and make your hands dirty with them. There are numerous tutorials available for MS-Azure Api App hosting which will guide you to a successful deployment.
I have not yet explored AWS as of now, but i trust that they will be similar in their learning curves.
Related
I make a swift osx app with a Firebase-server. They can't communicate directly with each other so I made a node js web server (that is running on localhost at the moment). It seems like I need either an own server or the one of a cloud service. Do I still need Firebase and are the cloud services something else or can I replace the Firebase server with the one of the cloud service?
Firebase is good place to store plain data like text etc, becomes quite expensive if you start uploading images or any other media data.
Amazon is good for everything, but became quite confusing and crowded with their services over the years. The good stuff from there are elastic components for web deployment, load balancing, and cheap data storage, maybe ec2 if u are a bit more advanced and know how to make the required remote OS for your web service.
Bluehost, seems like they are targeting wordpress developers mainly and domain registration, i would think of this as the tip of the iceberg when you nearly finished developing and require some decorations on the top. They might have some services like Amazon and Firebase but quite unlikely to beat amazon or firebase prices.
I'm just starting to learn more about the Node.js paradigm and finding it hard to grasp basic concepts. I'm familiar with front-end tools (HTML, CSS, JS) and have been using PHP with Apache server and mySQL db to deploy websites until now.
It seems to be that node is it's own server, and I would then need a SaaS platform like Heroku, or AWS (I'm not even sure if i'm understanding the purpose of these) if someone could explain the difference?
Is the database managed inside this service?
Is the website being hosted there?
In steps how would you get the node app to be served onto your domain name?
For Scalability purposes I understand how having dedicated big infrastructure can help, but if building a low traffic website with small number of members is there even a point in using node?
normal hosting services cost between $4-20 usd. per month and AWS or Heroku seem to start at a MUCH higher price. Is Node only to be used for large scale scaling business model?
Thank you for any answers or good recent external resources (websites or books) you could point me to.
You could easily host a low traffic website built with node.js absolutely for free on Heroku.
To see how easy that is, just go through the Getting Started With Node.js Heroku tutorial, in which you will do just that.
When you build your website with node.js, your own code that your write is the web server. You have no separate web server to configure and interact with (such as Apache). So what you see (or code...) is exactly what you get.
You will probably want to use a framework such as Express to build your web server functionality in your node.js app.
As for NoSQL databases, the way to do this on Heroku is to use an appropriate "add-on" from the Heroku Elements Marketplace. For example, you could easily add Heroku Redis or MongoLab. These are just some of the NoSQL "Database as a Service" options. That means that the Database is itself hosted somewhere in the cloud, and your app simply interacts with it. You don't need to worry about database maintenance, security upgrades etc. You just need to concentrate on your app's interaction with the DB.
Almost all add-ons in the Heroku Elements Marketplace feature a free-tier, that may suffice for your needs, at least initially. So you might be able to get your low-traffic website (including the DB) up and running completely for free, at least initially.
One thing you will need to understand is how Heroku free dyno hours work.
If you need your website to be continuously available 24/7, you may need to verify your Heroku account with a credit card (even though no charges would be incurred as long as you deploy only 1 free web dyno and are on a free-tier plan of your NoSQL DB as a Service). For further details, see this answer.
You also need to consider whether you can tolerate dyno sleeping in your low-traffic app. If not, you would need to prevent your web app from sleeping, which can also be done completely for free. For tips on how to do that see here.
As for serving your Heroku node.js app website from your own domain name, see here. Note that for this too you will need to verify your Heroku account with a credit card, although this too does not incur any charges.
Node.js is supported by many web hosting already, especially for those who use Plesk or cPanel as their web hosting control panel. Here is guide about how to setup a Node.js website via Plesk control, https://www.bisend.com/blog/how-to-set-up-a-node-js-site-in-plesk. As you said, it's very easy to host your website with a cheap shared web hosting.
I have written a real-time multiplayer game and currently writing its server in NodeJS. I want my game to have login, level up etc, so I need to have a database. This is the first time I am deploying something and I am mostly self taught, so please correct me if I am mixing things up. Since this is my first trial, I do not want to make much commitment right away so I am looking for free options only. And since this should be a real-time game, I need a relatively fast server response. That is why I am looking for the easiest database and server provider that would do and I am aware that with those restrictions I have limited choices and functionality.
As far as I have read online, Heroku seems to be my simplest option for a server (that is why I started writing in NodeJS). However it seems like there is no free database service since all options on https://devcenter.heroku.com/articles/heroku-postgres-plans has monthly fee. I did not want to use Google App Engine since I am new (it certainly is not mentioned as beginner friendly).
So I have found AWS following Free Cloud Database Service for home development post, it seems like I could use Amazon Web Services as a server and database. However most posts I have encountered suggests Google App Engine or Heroku with little mention of AWS. Is this because I am mixing concepts up, or does AWS have drawbacks that I am not aware of? Do you think it is a good idea to use AWS for both as server and database, is it possible to use Heroku as server while using AWS as database or do you have any other suggestion?
Note: Sorry for the question bombardment but those are all related and I am sort of lost in this topic so I had to ask...
Use AWS EC2 for the server and RDS for the database. The reason why people use heroku is that it deploys to a custom url very quickly (it's easy to set up). Setting up AWS requires some knowledge of how servers work, but it's not that complicated (and it's free for small apps). Best of luck!
Am I correct in the assumption that without access to the MongoDB server, there is not much point developing with Meteor?
Meteor is a great framework for building, packaging and deploy apps and sites. From a development POV, the templating and responsive DB work make prototyping so much easier than most MVC's.
I understand that underneath the hood, websockets and DDP provide the realtime sync'ing magic which means that you need access to the MongoDB server, something you don't have with PaaS solutions like GoogleAppEngine, Parse or Kinvey.
So, for the backend developer, they don't derive much benefit from Meteor since they need to maintain the server stack and scalability issues.
Is there a path to create and deploy products with Meteor without having to build and maintain the backend infrastructure? Heroku is still pretty close to the bone when it comes to managing infrastructure.
Wondering if there's a way to have CRUD operations through a REST driver that maps out to whatever PaaS you want and have the PaaS post log changes to a server that strictly handles websocket connections. Basically, pass the CRUD operation to a PaaS and maintain your own websocket server/s.
MeteorPedia has a page on deploying to PaaS: http://www.meteorpedia.com/read/Category:PaaS_providers
Recently, Google AppEngine has added support for custom VMs.
You can also use MongoHQ or similar for the database.
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.