InboxSDKからGmail.jsに切り替えた方法

カスタマーサポートソリューションを開発するために、最も人気のあるメールクライアントの1つであるGmailサービスを選択しました。 そしてその機能を拡張するために-完成したライブラリInboxSDK。 開発時には、必要な機能を備えていたため、このようなソリューションにより、製品の最初のバージョンで迅速に市場に参入し、ユーザーベースを獲得することができました。 一方、InboxSDKはサードパーティの開発者によるクローズドライブラリであり、将来解決しなければならない欠点がありました。

なぜInboxSDKを選んだのですか？

Deskunは 、Google ChromeおよびYandex.Browserの拡張機能として実装されています。 Gmailメールサービスに基づいて完全に動作します。 私たちの側では、メールの機能を拡張し、クライアント側で動作するライブラリを選択する必要がありました。 InboxSDK（ISDK）に決めました。

ユーザーが非常に気に入っているGmailの主要な機能は、ダイアログごとに文字を自動的にグループ化することです。 内部レベル（Gmailサーバー）では、各文字には独自の識別子と、それが属するダイアログの識別子があります。 しかし、問題は、Webクライアントでは、グローバルメッセージIDはページコードのどこにも含まれておらず、グローバルダイアログIDは開いているダイアログのURLハッシュにのみ含まれているということです。 代わりに、各メッセージとダイアログのHTML要素には、メインの（かなり大きくて難読化された）Gmailスクリプトが受信した「：a5 ,: b6など」という形式のローカルIDが付けられます。 ローカルIDはページごと、セッションごとに異なるため、Gmailを扱う拡張機能の通常の操作では、ローカルIDとグローバルID間の接続をすばやく確立する必要があります。 これがInboxSDKライブラリの機能です。ここでは、文字、下書き、およびダイアログの識別子を取得する機能に加えて、ユーザーインターフェイスを改善する機会も利用できます。

ISDKにはGmailを操作するための多数の異なる方法が含まれているという事実にもかかわらず、このライブラリには1つの不快な機能があります。これは、Gmail内に独自のCRMシステムを提供するStreakによって開発されます。 つまり、Deskunの間接的な競合相手です。

InboxSDKの問題

別の閉じたプロジェクトに基づいて独自の閉じたプロジェクトを開発することは、少なくとも間違っています。 特に、これらのプロジェクトが類似しており、競合他社であるという理由だけでAPIへのアクセスが常に拒否される場合があります。 これが行われない場合でも、少なくとも変更と可用性を制御することはできません。 ライブラリの開発者は、ライブラリに基づいてサードパーティのサービスを書くのを急ぐことはなく、新しいリビジョンの変更ログには有用な情報が含まれていません。 InboxSDK Webサイトでさえ、発売以来ほとんど更新されていません。 また、ユーザーの要求に応じてバグを修正したり、Streak自体のニーズに関連しない機能を追加したりすることを忘れることができます。 まず第一に、ステーキは彼自身のために図書館を作ります。

最初の問題 。 ライブラリが機能するためには、特定の安定した（安定した-ビューの切り替え、状態の変更などで変化しない）クラスへのバインドが使用されます。 たとえば、場合によっては、フォーカスされた要素のキー入力がエミュレートされます。 また、Gmailインターフェースの変更は、ライブラリ自体とInboxSDKに基づくサードパーティの開発を混乱させる可能性があります。

2番目の問題 。 ライブラリはブートローダーを使用してリモートで接続されるため、CDNネットワークを介したコンテンツの配信が中断する場合があります。 しばらくの間、何が間違っていたのかを理解しようとしましたが、プラグインが機能するライブラリは、一部のユーザーにはロードされないことがわかりました。 ある時点で、すでに顧客の10％がサービスを利用できなかったことが判明しました。 InboxSDKのダウンロードで問題が発生した場合、このライブラリに基づいて構築されたすべてのプラットフォームが機能しなくなりました。 問題は点のような性質のものであり、ホスティングに常に依存するとは限らないことを理解することが重要です。 そして、私たちにとって、問題の原因を修正することは完全に不可能であり、残っていたのは待つことだけでした。

3番目の問題 。 InboxSDKはオープンライブラリではありません。 公に宣言された関数には、使用可能なすべての関数の最大3分の1が含まれます。 これは約400 Kbのパックされたコードであり、メインのGmailスクリプトを解析した直後に文字通り解析されます。 遅いマシンでのMail.google.comの読み込み時間は重要です。

4番目の問題 。 ライブラリの変更は定期的に行われるだけでなく、週に数回行われます。 残念ながら、これらの変更のほとんどにはバグ修正が含まれておらず、新機能は追加されていませんが、主なStreak開発者のニーズを対象としています。 1つの更新により、プラグインのクライアント部分のコードと競合する状況がありました。 12月、InboxSDKの新しいマイナー（シャドウ、変更ログなし）バージョンがリリースされ、受信者を挿入する機能が変更されました。 受信者を追加した後、ドラフトを保存するトリガーがあるように実装されました。 保存自体はかなりおもしろい方法で行われました-入力フィールドで特定のキーを押すだけのシミュレーションでした。 すべての変更の前に、押すことは「Enter」によって実装されましたが、コードが「190」（¾）の記号を押すようになったのはその変更でした。 この場合、チケットで応答フォームを開くと、このチケットの受信者が自動的に置換されます。 したがって、競合が判明しました。チケットの応答中に、シンボル¾が受信者のフィールドで置換されました。

InboxSDKからgmail.jsへの切り替え

その結果、徐々にオープンなものに切り替えることにし、Gmail.jsライブラリ（GJS）が将来のソリューションの基盤となりました。 InboxSDKとは異なり、Gmail.jsライブラリは完全に開いています。 その開発はコミュニティに依存しており、機能は非常に良いペースで開発できます。

移行中に、2つの主な問題が発生しました。

まず 、Gmail.jsライブラリが機能するためには、ページのウィンドウオブジェクトへのアクセスが必要です。Gmailにはいくつかの技術情報が保存されています。 「サンドボックス」内の拡張機能は、ページのDOMのみにアクセスできますが、その環境にはアクセスできません。

次に 、プラグインのクライアント部分への変更を完全に除外するには、ラッパーだけでなく、ライブラリ自体にない関数を追加する必要もあります。

最初の問題に対する完璧な解決策はありません。 それらはすべて、何らかの不便に関連付けられています-postMessage、カスタムイベントを使用してスクリプトを直接scriptサイトページに追加するか、DOMに直接書き込むことによる実装。

GJSを使用して、特定のイベントをプラグインに直接報告するブリッジを実装することにしました。 現在の実装では、インジェクションテクノロジーを通じて、GJSライブラリとブリッジがページに導入されています。 したがって、GJSは適切な環境で動作します。 すべての拡張機能について、Google Chromeブラウザーはそれを操作するための一連のメソッドを提供します。 したがって、直接インジェクション（GJSライブラリなど）を介して拡張機能を作成すると、API拡張機能を操作するすべての可能性が失われるため、非常に重要で必要な機能が失われる可能性があります。

2番目の問題を解決するには、InboxSDKの動作だけでなく、Gmailクライアント側の動作も分析する必要がありました。 拡張機能には、コード内にインボックスの属性とクラスに関連付けられた場所があります。ライブラリの機能をさらに拡張したり、一部のインボックスエラーを修正したりする場合があります。 したがって、プラグインのクライアント部分の操作を中断させないために、必要なクラスと属性を同じ方法で追加し、特定のイベントおよび特定の条件下で特定の要素に追加する必要がありました。 Gmailのクライアント部分を操作するためのAPIがないことは既に述べました。 ただし、そこには多くの必要な情報が保存されています。 たとえば、ユーザー設定、利用可能なメールエイリアスのリスト、含まれている一連の実験的な機能、その他の重要な技術情報などです。

まとめ

プラグインのクライアント部分のロジックとコードを変更せずに、あるライブラリから別のライブラリに移行することができました。 最終的なソリューションは、GJSライブラリを使用するだけではなく、独自のハイブリッドライブラリISDKとGJSを作成しました。 Gmail.jsが基盤となりましたが、機能的には開発はInboxSDKに似ています。 Habrahabrコミュニティに興味があり、コードを共有するためのリクエストが多数ある場合は、コードを整理して公開します。

デスクン