In our anti-hakatone, a team of students of the Higher School of Economics won with a decision to accept donations for streaming. But Maxim Dyakov , the founder of the Yastrim service, will tell about the project the best - I give the microphone to the author.

Under the cut there are a few throwings between ChromeApps and Electron, the impressions of the Yandex SpeechKit test and generally about the development in the anti-hacking format .

One rainy summer evening, my friends and I decided to take part in the anti-hacking engine Yandex . Money . And the reason was suitable, because I had long wanted to create an application related to stream services and the process of sending donations. Our team consisted of four people: Alexander Naumov, responsible for the mobile application Javid Khalilov, the main PC client Alexander Kobrin and me, as a backend developer and ideological inspirer.
It turned out cheerfully - in two weeks a minimally viable product “Yastrim” appeared.

Why would anyone pay for stream

For a general understanding, I’ll talk a little about how the donation is sent and, more importantly, why it is needed at all.

Streaming in this article means gaming streaming. That is, when someone broadcasts to the network his gameplay and at the same time all this comments. Popular streamers have their own audience of viewers who follow the release of new “episodes” and sometimes send comments, messages or money. Of course, everything on a voluntary basis and without any practical purpose for the audience is purely just for fun.

Since streaming for the viewer is just a way to have fun, there is no obvious reason to pay someone even 50 rubles (this is not a movie, and they do not ask for tickets when they are connected). However, the online streaming industry is gaining momentum almost faster than blogging, which means it cannot do without a good cash flow. In general, there is no clear answer as such. Throwing a coin to young musicians in the subway, we do not receive any kind of service or product, but only thank the performer for his work - and here too.

As for the technical side of streaming, there have long been known products for capturing and broadcasting video from the screen, but there is no sensible system for collecting donations. Sensible is that:

1. allows the user with a minimum of effort to transfer a certain amount of streamer;
2. supports message transfer (text or voice) from a user to a streamer in the process of money transfer;
3. shows streamer message and alerts about receiving money from specific users;
4. can read user messages out loud live and contains settings for “sticking” the mat and other words not suitable for streamer;
5. can work with any streaming software, so as not to force the tape drive to abandon the usual environment.

At least, there is no product that would satisfy these requirements and did not take its own commission. In addition, for the transfer of money in most products is their own development that adds doubt to the consumer. And if there is no sensible product, then there is a reason for a startup.

Building only one donation product is pointless - it will limit its capabilities and reduce the development potential to almost zero. Therefore, we decided to make a comprehensive solution “ Yastrim ”, the alpha version of which you can watch in the video:

So the streamer sees the Yastrim interface.

The main advantage of our project over competitors is that Yastrim does not require any integration with the usual streamer application for screen capture and broadcast. Instead, it simply imposes the necessary interface and user messages on the screen, which is captured by the streaming application.

Building happiness for streamer

Since we wanted to cover a bigger market, and at the same time learn something new on the anti-hackone, the solution had to be cross-platform - with the support of all streaming platforms and related software. Chrome Apps was originally chosen as the basis, which seemed almost an ideal tool for debugging and API development (I especially liked the debugging of applications in Postman, which was also written under Chrome). Then desktop clients could be written on Chrome Apps immediately under a variety of platforms.

Inspired by the best, in my opinion, tool for developing Web API - Postman in the version for Chrome - I decided to use Google Chrome Apps as the basis. Applications written for this platform work in Google Chrome and in other browsers on the chromium engine, which would make an easy cross-platform solution.

Here are some motivating factors:

• Google Chrome and other browsers on the Chromium engine make up most of the market, so the solution would be "omnivorous";

  
  
• development on this platform is a typical web frontend with some nuances that were placed in the book Marc Rochkind on 240 pages.

As for the backend, the choice is clear for me - ASP.NET. After some experience configuring the server on Ubuntu, it’s worth once to get acquainted with the pleasant Azure UI, and there’s no going back. The last nail in our doubts was driven into Azure's free monthly subscription for a month, that in the conditions of anti-hackathon it is the most.

Of course, in all of this kingdom of convenience and free of charge was not without hell of a moment.

I would like to share the fact that all this time I have been under the impression of the book “The mental hospital in the hands of patients” by Alan Cooper. The book is devoted to the theory of interaction design, so when it came to the second component - the audience - I really wanted to try out techniques like character making in battle.

When we decided on the main components of the product (desktop app, web form, and mobile app), our front developer suddenly found out that Google is stopping support for Chrome Apps on Windows, Mac and Linux. An awkward pause, disappointment, resentment, acceptance.

The king is dead, long live the king of Electron

Alternatively, the open source Electron framework was a great fit. Of course, the novelty of the platform was alarmed, but the growing popularity offset the fears. As for the mobile application, let's say this: I only had an Android developer on my mobile team. The client-server architecture was chosen for YAS Strima, with Microsoft SQL as the backend database.

I think it makes no sense to disassemble architecture in detail, draw flowcharts, etc. - it's boring and specific to a particular project. Better share tips on my own experience of trial and error:

• As an identifier, it is better to choose something globally unique, for the future. For example, for the ID of the online broadcasts, I chose the URL, which allowed us to solve a million problems in one fell swoop (uniqueness, quick access, the ability to continue working with the streaming platform API).
• Study in detail the platform of your future service - it will save a lot of time at higher levels of implementation. It is better to spend a couple of days on the platform than in the final stages to find that everything needs to be rewritten in half.
• Unless we are talking about the hackathon and the project without further prospects, immediately document all entities, logic, interaction, and so on. The further all this is postponed, the more information you have to keep in your head. It’s not easy to remember everything on a big project, so it’s best to do it right away.

Then came the development stage of the WEB API of our service, where the main task was to ensure the safety of streamers: that if someone changes the donation settings, changes the logo or starts something else unkind.

So the following security tools appeared on the platform:

• With each transfer, a special label is entered in the label field, and the operation identifier (if it can be obtained) is included in the donate data. This was necessary for convenient work with the Yandex.Money API on the side of the streamer and checking the existence of a transfer in the payment system.
• When YAStrim receives data about the donate produced, the user client requests Yandex.Money operation with the same ID or all operations with a match on the label field. Donat will appear in the stream only if the transaction is found.
• All communication between the user client and the streaming platform takes place using the special YAS Strim token, which is issued at the authorization stage in the payment system.
• Separately, we had to tinker with uploading photos, as there was no experience, and for the simplicity of working with the API, it was necessary to make a small photo hosting site.

The result of all these studies could be described as “backend works”, which, in my opinion, perfectly characterizes the early prototype. Next, there was still to be refactoring, refactoring, and once again exciting refactoring.

Exciting assembly stage

When it came time to create a working build, we didn’t have to connect React in any way - as a result, the application produced wild errors at startup.

An example of what we caught when trying to build.

Our team dug up the length and breadth of Stackoverflow and GitHub Issues, so it only remains to open a new topic and look for knowledgeable people. So we met the developer Electron and @akashnimare , who has the right experience and was willing to share it. In addition, we have discovered the Russian Electron community , where it is worth going to anyone who is going to use this platform.

With the storage of files, too, a hitch came out, from which the council was born to pay more attention to the foundations of the application. It was necessary for us not to be lazy, but from the very beginning to connect the electron-storage or electron-storage-json library, so as not to rewrite the code when it turns out that local-storage from main is not available.

A ray of light in the dark realm of unfamiliar frameworks was Yandex SpeechKit , which not only produced an excellent result, but also required a minimum of time to study the documentation. In fact, the necessary option to voice the message from the user's donate turned out after three lines of code:

const tts = new ya.speechkit.Tts({ apikey: 'ffffffff-2222-4444-0000-1111111111', emotion: 'good', speed: 1.2 }) ... tts.speak(donate.text_data, { speaker: 'zahar' }) 

It is enough to specify the API private key, choose a voice (zahar), speed, emotional color (good) - and that's it.

Behind shoulders liters of power engineering specialists and 3 weeks of dense development

To summarize, I want to say that as a startup, we are not even at the first stage. But from the point of view of the original goal, we achieved the main thing: we managed to implement almost all features (except voice messages, which still have roughness), which is not often possible for young developers on a real project. In this case, no one has quarreled, all four in the boat and continue to believe in success. Therefore, achievement unlocked, but there is still a long way to go.

If our experience seemed interesting to you, I would be happy to answer questions in the comments.

Page of the project "YStream" .