How we were looking for a chat for students and mentors and found one

In December 2018 we launched our own chat for students, mentors, partners and interns. It was a huge step for us. Before that the choice of communication method was entirely up to a particular student and a mentor without any interference from the mkdev team.

Why did we come to a decision to make our own chat?

1. The quality of the services provided won’t comply with some third-party service

As some other services, mkdev fell prey to the Roskomnadzor’s efforts to ban Telegram. We did our best to interfere and were quick to find the solution and restore mkdev services in Russia.

However, our students who used Telegram to communicate with mentors weren’t so lucky. Some of the Roskomnadzor’s attempts were successful and many of our clients were not able to communicate with their mentors. For those who paid for a personal interaction with a mentor it seemed obnoxious. Moreover, it also increased the workload for our support team. Any non-mkdev service can undergo similar problems. Gitter.im might suffer from Roskomnadzor’s blocks, Slack free plan deletes old messages with the info, files, and links important for the user, whereas Google might make an impulsive decision to get rid of Hangouts.

When we choose to personally work on communication infrastructure for students and mentors, we obviously take huge responsibility, but we also keep total control over the quality and availability of the service.

2. All the clients will be provided with unified seamless experience

How it was then:

1. the client pays and gets an email that asks them to join Gitter;

2. there is a link on the mkdev mentor’s profile that leads to the mentor’s profile on Gitter;

3. the student and the mentor have their first contact on Gitter and after that decide where they’re going to continue communication ;

4. they start communicating using some other service.

Thus, the client isn’t emotionally attached to mkdev, as the whole studying process is conducted using some third-party service.

How it is now:

1. the client pays and can join a private chat with the mentor right away. Our friendly bot named Gabriel has already instructed the student on what to do next and the mentor is available and ready to answer any questions immediately.

There is no need for the client to make any extra steps and, as a result, there are fewer situations when the client doesn’t know where to look for a mentor and the mentor doesn’t know how to contact the student. All communication is carried out within the mkdev infrastructure.

3. We’ll have an opportunity to integrate the chat into the study process

Up until now everything connected with the study process (subscription management, study plan, quests) was conducted through mkdev.me while student-mentor communication was a separate thing. Having taken full control over the chat system, we’ve got an opportunity to integrate it into the main mkdev platform. It includes not only simple chat notifications, but also some more complicated things we’re working on right now.

A simple example: now we’re able to notify our mentors about which students got lazy and need to be motivated. A not so simple example: we’ll be able to integrate audio- and videocalls into the chat in the future.

4. We’ll be able to finally get all the students together

In addition to a separate space where mentors can communicate with all their students, we’ve launched Mkdev Club, which is a community for all students, mentors and interns of the project. We always had an opportunity to do the same in Slack, but we didn’t like the idea of a limited number of stored messages. The fact that we could lose our club due to some third party actions seemed risky, too.

Any huge changes like that obviously have disadvantages. Some of our long-term mentors were not happy to move all the contacts from their favorite services to the new system. Moreover, mkdev now is responsible for any bugs in the system that might put an end to all the communications and this is certainly a high risk.

How we were choosing technologies for our chat

We had loads of requirements for our future chat. Here are some of them:

• integration using API with other services;
• markdown, file uploading and syntax highlighting support;
• convenient app for mobile devices;
• easy maintenance;
• low price.

We’ve searched through lots of different options keeping in mind the requirements above. That was a hard choice, so we hope that our experience might come in handy for someone struggling with the same choice.

Option 1: SaaS product

The easiest way was to find a ready-made product and use it. Unfortunately, we couldn’t afford it. Slack’s minimum price per user is €6.25 while similar SaaS products have almost the same price. Having the amount of students and mentors that we have, the solution wouldn’t have been beneficial for us in terms of money.

That’s not a surprise, as services like Slack are aimed mostly at corporate communications. This platform isn’t even trying to be a general purpose chat, which leads to such price per user.

Option 2: create our own chat from scratch

We were thinking about creating our own chat system from scratch and without any help for quite some time. Since Ruby on Rails lets you create chats during a single evening, you can make one with some basic features in relatively short time.

But basic features are not enough for us.

Right after we’d implemented the main features (an ability to send messages), we would have been in need of formatting and file uploading. And after that notifications, information about unread messages, mentioning other users in the chat and, finally, emojis. Mobile version and a smartphone app, perfectly working on all devices and in all browsers, would have been crucial, too.

Before we knew it, 100% of our development time would have been spent on refining this chat and bug-fixing. This wasn’t something what mkdev team was ready to spend their resources on.

Option 3: use Chat API as a Service

There are many third-party companies that offer chat services through API. This is how it works: some third party provides all chat primitives through an API as well as an SDK to work with. The only thing you need to do is to write all the client code (such as code for mobile apps) to work with the API.

This idea seemed very tempting at first. All the complicated backend parts will be implemented already, Chat API services will be way cheaper than SaaS ones and at the same time we can still control how the final version looks and works.

Let’s talk about the two of several services we looked at:

Twilio Programmable Chat

Twilio is a huge platform providing infrastructure for messages and phone calls. You might not know it, but you probably use it every day. For instance, if you use Twitch, you use Twilio. Twilio has a bunch of different XaaS products for different needs, including Programmable Chat, which has been launched recently.

But there’s also one serious problem. Twilio doesn’t have out-of-the-box solutions for clients. The company focuses on the backend, which means that the frontend is something that you should work on. In our case it means that we would need to create mobile- and web-apps, formatting and whatnot by ourselves.

Pusher Chatkit

Pusher also provides all sorts of APIs and is used by a crazy number of companies. In 2018 Chatkit came out of beta and we gave it a try. Unfortunately for us, the result was basically the same as with Twilio. It’s a set of awesome convenient APIs, stable backend, but there are no ready-made client apps, which makes it unsuitable for us.

What’s important about Pusher Chatkit is that there are the examples of use of its API, similar to the real chat environment. You can have a look at Pusher Slack Clone React Demo. It felt like we might use it after all, but for our purposes we still needed a bunch of important features that weren’t there.

Kudos to Pusher for having such examples. Too bad that we use VueJS and aren’t ready to implement all the necessary features by ourselves.

It’s the same for Twilio and Pusher rivals. They all have highly convenient APIs but require you to write all the frontend parts by yourself. We recommend you to chose some of them if you need your own one-of-a-kind chat (e.g. if you want to create the next Telegram). But it didn’t work out for us.

Option 4: ready-made Open Source solution

And finally let’s talk about the option which we thought of as the main one and which we chose in the end. In 2019 there are always Open Source alternatives to any large SaaS product. However, there are many aspects that you need to keep in mind, so we’d had to try out different products before we made our decision.

Zulip

A chat service by Dropbox developers which went open source.

It looked good at first sight, but in the long run appeared to be inconvenient in terms of messages, channels and chats management.

Rocket.Chat

It’s new, trendy, has dozens of different features and seemed close to perfect for us. The only problematic thing was the fact that this chat stores all the messages in MongoDB. Being the fans of simple and reliable solutions, we just couldn’t put up with it, because we don’t have much experience working with this database as well as a desire to deploy several dedicated servers for database only.

Apart from that, we didn’t face any other issues and would have probably chosen Rocket.Chat. It looks awesome and good for work. But it turned out that its closest competitor, Mattermost, made us absolutely fascinated, so we chose it in the end.

It’s great both on the outside and inside.

Mattermost Team Edition

The Mattermost developers don’t really hide the fact that they are working on a Slack clone. Since Slack has all the necessary for mkdev team features, an Open Source Slack is exactly what we need.

Besides all the features, there are ready-made mobile apps you can use out-of-the-box along with the Mattermost server. We were also mesmerized by how easy Mattermost is to use. The whole app is just a single binary file and the database used is PostgreSQL which we are familiar with (it’s running in our AWS RDS). Having an ability to connect file storage on AWS s3 and send emails from AWS SES with a couple of clicks appeared to be a lifesaver for us concerning the maintenance of the service.

Mattermost is written using Golang, the language we’ve dealt with before, which means that we can extend the product if we want. Plugins support is in beta for now, but looks promising. Moreover, just look at how widely Mattermost is used at Uber. This gives us hope that we’ll be able to use it for everything we’ve planned, too.

Are we happy with the result?

Even though the Mattermost chat can be implemented relatively easy, we were still worried about the launch. We tested and prepared everything thoroughly, but, despite that were still wary that we might have not delivered what our clients expected and if something’s wrong, that is going to be 100% our responsibility.

But it went well. November beta revealed several integration problems which we were able to solve really quickly. Our mentors and students have exchanged thousands of messages within the subscription as well as mkdev club since the chat was launched.

Only time will tell how it turns out. For now we are happy with our choice and have been working hard on how to facilitate communication between our mentors and students even more.

P.S. How to access mkdev club

There are several ways to get access to mkdev club:

1. pay for mentorship at least once and thus become a student;

2. become our mentor;

3. become an mkdev intern;

4. be a recruiter who wants to have access to a huge list of well-trained job-seekers.

Message us at team@mkdev.me if you are such a recruiter. So far we give recruiters access to our club free of charge.