Architecture: How will you design the architecture of a service like slack?

I personally vision-impaired(very badly). However, I think I can use more advanced technologies to make vision-impaired people's life better.

Here is my idea:

Build a SPA for vision-impaired people. In this application, vision-impaired people can:

subscribe from many content resources(like Slack), and listen them on the computer or through another device(like Amazon Tap)
contact with other people through voice commands or keyboard
interact with the service through voice commands or keyboard
can play MUD game through voice commands or keyboard

Right now I think nodejs+react would fit for this purpose. Though I'm still learning to keep up with the latest trends of the JS community.(ES6, Typescript, Webpack, React etc)

I also considered to use Meteor, but Meteor is in transition. Rocket.Chat and "platform" are too big for me.

So what do you think of this idea? And how would you design the architecture of such a service?

Many thanks.

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

Thank you for your answer. I'll definitely look for your suggestion if I encounter some problems.:-)

I was the front-end engineer at http://jianliao.com which is like Slack flavored by Teambition. So I may talk about the React part here and hope it helps. Jianliao was built with Node.js and React. We used Node.js to deliver messages(HTTP for sending and WebSockets for pushing) and grab resources from the Web and React for the UI part.

In a Chat app, there are lots of UI components on messages, users, and topics, which mostly same models but several different views. React fit into this pattern very well thanks to its templating language nature. Also there were many reasons to compose components, so heavy UI framework like React(also Angular, Vue, Ember...) is required. And hot module replacement is very necessary for webapps at this scale, you may find that in Webpack, Browserify, JSPM, etc. Since React not at making forms I would not say it's a perfect choice to use it due to the heavy use of forms in configurations of integrations.

Also the data layer had something important. It includes lots of boring code to sync data from server and to send data to the server. It's just you have two copies of data to update, one on the server, one in the JavaScript runtime. I fought against that problem for long but I don't have a good solution for it.

I'm going to use wilddog for message syncing.

Thread

Architecture: How will you design the architecture of a service like slack?

Responses(3)

Database

Backend

Frontend

Chat Sessions

Recent threads

Search Hashnode

Architecture: How will you design the architecture of a service like slack?

Responses(3)

Database

Backend

Frontend

Chat Sessions

Recent threads