メールボックスで先送りしないでください：b2c-messenger 2GIS

9月、2gis.ruに新しい機能が登場しました。これは、組織と通信するためのb2cメッセンジャーです。 製品またはサービスを検索する場合、チャットは非常に便利です。一度に複数の会社に書き込むことができ、ロボットの留守番電話の声を聞いたり、オペレーターが目的の製品の価格や残高を決定するまで待機したりする必要はありません。 会社を選択し、会社カードのメッセージアイコンをクリックすると、チャットが開きます。



メッセンジャーを作るには、チャットがどのように機能するか、WhatsAppやTelegramのような「兄貴」が内部で何を持っているかを少し把握する必要がありました。 結局のところ、すべてがそれほど怖いわけではありません。

なぜ2GISメッセンジャーなのか

おそらく、メッセンジャーからではなく、どのようにしてこのアイデアに到達したのかから始める価値があります。 以前はディレクトリに会社のメールを表示していました。 次に、ディレクトリから直接会社との連絡フォームを追加しました。 書くよりも少ないですが、文字のチェーンの長さは平均2〜10メッセージです。 つまり、メッセンジャーは、会社に手紙を送る既存の能力の論理的な発展です。

今どのように機能しますか

さらに良いことに、質問をしてみてください 。 ノボシビルスクにいます。モスクワの18:00には、すでに22:00になっています。

クイックレビュー：自転車を選択する

まず、quickblox.com、backendless.com、sendbird.comなどのBaaS（サービスとしてのバックエンド）に注目しました。 それらはすべて、標準のチャット機能をモバイルまたはWebアプリケーションに追加するためのツールを提供します。



既存のBaaSソリューションに基づくメイン（会社への電子メール通知の送信）およびより高度なシナリオの実装には、Webhookを介した統合のための独自のバックエンドの開発と、ベンダーAPIとの統合のための特別な努力が必要です。 そのため、BaaSは私たちに適していませんでした。 さらに、機能を完全に制御すること、つまり、サードパーティのソリューションに依存しないことを望んでいました。 最終的に、私たちはエンジニアであり、新しい経験を得るために実験することにしました。

そして、メッセージを配信する方法は？

メッセンジャーのバックエンドを作成するには、最初に一連の質問に対処する必要があります。メッセージをクライアントからサーバーに転送して戻す方法、メッセージを保存する場所、多数の同時接続に対処する方法、サービスをスケーリングする方法です。 Googleは、比較のためにメッセージをタブレットに配信する方法を集めて考えました。





最新のチャットアプリケーションのほとんどは、ロングポーリングまたはWebソケットの2つの方法のいずれかを使用します。 Websocketには、長いポーリング（全二重接続、再接続時の不要なトラフィックの欠如）よりも多くの利点があり、ブラウザーおよびオープンソースライブラリで広くサポートされているため、タスクに最適な選択肢のようです。 また、短所もあります。ブラウザごとの実装の違い、サーバー上のより複雑なロジック。



データを送信するための最も一般的なオープン汎用プロトコルはXMPPです。

プラス側	マイナス面
IETFオープンスタンダード	送信された情報の冗長性
多数のオープンソース実装	XML
カスタマイズの幅広い可能性	それは私たちのタスクの詳細を洗練する必要があります。

ただし、さまざまな「大」メッセンジャーのソリューションを検討した結果、XMPPを使用した単一の重要なサクセスストーリーは、その後の改良とカスタマイズなしでは見つかりませんでした。 熟考した上で、タスクの詳細を最初に考慮する単純なJSONベースのプロトコルを開発することにしました。

技術スタック

歴史的に、主なバックエンドサービスであるAPI 2GISはPHP5で記述されていました。 2年前、私たちはPHPを離れ、Scala and Goに移行することにしました。 Goを使用すると、かなり複雑な並行プログラムを非常に簡単に作成できます。 これは、メッセンジャーを実装するための主要なテクノロジーとして選択する際に決定的な要因になりました。 そして、Goでの開発経験はすでにありました。



したがって、バックエンドはGoで記述され、フロントエンドはReact + Reduxで記述されます。 メッセージングシステムとしてRabbitMQを選択しました。 データストレージには、RedisとPostgeSQLを使用します。 アプリケーションをDockerコンテナーにパックし、Gitlab-CIを介してDeisプラットフォームにデプロイします。



上で言ったように、Webソケットを使用したかったのですが、実装に関しては、ソリューションを少し考え直しました。 実際、仮説（悪名高いMVP）をテストするために、できるだけ早く機能をリリースしたかったのです。 高速化するために、ロジックをWebソケットを使用してクライアントからサーバーに送信することと、最も単純なREST APIを反対方向に送信することに分割しました。

通知はどうですか？

突然、通知は実装が最も困難であることが判明しました。 すべてが単純であるように思われます。電話にプッシュを送信し、メールに手紙を送り、ブラウザに通知を表示します。 しかし、私たちのタスクは、すべての通知ができるだけ早く読まれ、同時にスパムストリームにならないようにすることでした。



カスケード通知システムと呼ばれるソリューションがあります。 たとえば、3つの主なチャネルがあります。2gis.ruの通知、手紙、電話へのプッシュです。



この場合、通知システムは次の形式を取ります。



-ユーザーがオンラインであるかどうかを確認します→そうである場合、ブラウザで通知を送信します。

-ユーザーがオンラインでない場合は、電話が接続されているかどうかを確認します→接続されている場合は、携帯電話にプッシュを送信し、ブラウザーのダイアログに通知を表示し、手紙を送信しません。

-これがうまくいかなかった場合、私たちは手紙を送ります。

-通知が会社に関するものである場合は、しばらくの間反応を観察し、ブラウザーで通知してプッシュした後に応答がない場合は、とにかく電子メールを送信します。



実際、このシナリオからプッシュ通知を送信しているわけではありませんが、すぐにその方法を学習します。

計画

近い将来-メッセンジャー機能を2GISモバイルアプリケーションに追加し、主な機能（メッセージに添付ファイルを添付する機能、ブラウザープッシュ）を完了し、高度な通信シナリオ（たとえば、複数の企業への要求など）を実装します。



これまでのところ、企業はメッセンジャーに慣れておらず、全員がメッセージにすばやく応答するわけではありません。 しかし、テキストを介した人と企業の相互作用には大きな未来があると信じています。