Popular posts

Hey @ithinco, it is an absolutely brilliant idea, and I would be more than honoured if I am able to help you with it! :)

Let's break down the architecture of a very simple chatting application. We'll include the really basic features which are a mandate for any IM (Instant Messaging) service.

Database

Let's talk about this first, as this will be (more or less) the crux of application.

In simple terms, you will be storing a lot of data. At the top of my head, I can think of tables for the following:

• users -- a list of users
• users_info -- a table to contain the information (Name, Address, etc.) about the user

Since all of this will rarely change, and will mostly be read-only, using a persistent datastore like MySQL or MariaDB will be (at least) my weapon of choice. Personally, I'd favour MariaDB because it has Galera clustering which can help you reduce the headache of managing MYSQL_BIN and other such replications. And plus, it's a cake walk to set up! ;)

Then, you would also need the following tables for managing logins (sessions), chats (chat sessions), and chat groups (group sessions). Now, this is something which is volatile, i.e. ever-changing. The user might be adding/removing users from a group; s/he might be creating groups; s/he might be starting a new chat, and what not. For this, you'll need a really fast, transparent data store. Here, I would recommend Redis. It's a blazingly fast store for data which is ever changing. You need to realise that if your Redis store for the login_sessions goes down, people can just login again: no problem; however, if the store for chat_sessions, or group_sessions goes down, your users will be angry. So, I'd recommend you set up replication for the latter two data stores. Really simple, and really efficient. :)

Backend

I have used Node of some really huge applications, and it has proved to be a delight. It's really simple to get started. The method I follow is this:

• use the trusty old pen-and-paper to design the API endpoints;
• work out the database (UML, etc.)
• prototype the API;
• add testing, logging;
• push to staging
• make improvements related to speed, and efficiency;
• push to staging again
• repeat

It works out really well, and I would recommend you to do the same.

When it comes to the RESTful framework, I would go with Hapi.js any day.

Frontend

You want something really accessible, so AngularJS (or even ReactJS) would be awesome! Your idea to make it accessible to the visually-impaired is fantastic! :)

Chat Sessions

Now, I'd go with stream-sockets, or web sockets. They are really fast, really reliable, and super simple to set up. I can think of the following algorithm to start a new chat:

• check username/password
• grant session token
• give the session token to the backend
• the backend validates it
  • if valid, create a new web socket stream with listeners as assigned by the user
  • if invalid, return error

Scalability should not be a problem right now. I guess that should be enough to get started! And as always, if you have any question or any doubt, feel free to comment and I will try my best to solve it.

Best of luck, and I hope this helps! :D