How we migrated from InboxSDK to Gmail.js
To develop our customer support solution, we chose the Gmail service, since this is one of the most popular email clients. And to expand its capabilities - ready library InboxSDK. At the time of development, it had the functionality we needed, and this decision helped us quickly enter the market with the first version of the product and gain user base. On the other hand, InboxSDK is a closed library from a third-party developer and it had flaws that had to be solved later.
Deskun is implemented as an extension for Google Chrome and Yandex Browser . It fully operates on the basis of the Gmail mail service. For our part, it was necessary to choose a library that could expand the functionality of the mail and work with its client part. We settled on InboxSDK (ISDK).
A key feature of Gmail, for which users love it so much, is the automatic grouping of letters by dialogue. At the internal level (on Gmail servers), each letter has its own identifier and the identifier of the dialogue to which it belongs. But the problem is that in the web client the global message IDs are not contained in the page code anywhere, and the global dialogue IDs are only contained in the hash of the open dialog URL. Instead, the HTML elements of each message and dialogue are marked with local IDs like ": a5,: b6, etc.", received by the main (fairly large and obfuscated) Gmail script. Since local IDs change from page to page and from session to session, for the normal operation of extensions dealing with Gmail mail, it is necessary to quickly establish the connection between local and global IDs. This is what the InboxSDK library does, in which, besides the functions for obtaining identifiers of letters, drafts, and dialogs, the possibilities for improving the user interface are also available.
')
Despite the fact that the ISDK contains a large number of different methods for working with Gmail, this library has one unpleasant feature - Streak, which in turn, provides its own CRM system inside Gmail, is developing it. That is, is an indirect competitor of Deskun.
Developing your own closed project based on another closed project is at least wrong. Especially if these projects are similar and you can always be denied access to the API simply because you are competitors. Even if this does not happen, at least you have no control over the changes and accessibility. Library developers are not in a hurry to help in writing third-party services based on their library, and the changelogs of new revisions do not carry any useful information. Even the site InboxSDK is practically not updated since launch. And you can forget about fixing bugs at the request of users or adding features that do not relate to the needs of the Streak itself. First of all, Steak makes a library for itself.
The first problem . For the work of the library, a binding to some specific and stable (stable - which do not change when switching the view, changing the state, etc.) classes is used. For example, in some cases, keystrokes on focused elements are emulated. And any changes to the Gmail interface can disrupt the work of the library itself and third-party development based on InboxSDK.
The second problem . Since the library is connected remotely using the loader, there may be interruptions in the delivery of content over the CDN network. For some time we tried to understand what was going wrong, and then we found out that the library, on the basis of which our plugin works, simply does not load for some users. At some point, it turned out that already 10% of our clients could not work with the service. If there were problems with loading InboxSDK, then the work of all platforms built on this library was terminated. It is important to understand that the problem may have a point character, and may not always depend on the hosting. And from our side to correct the source of the problem can be completely impossible and it only remained to wait.
The third problem . InboxSDK is not an open library. The publicly declared functions include a maximum of one third of all available. This is about 400 KB of packaged code that has to be parsed literally right after parsing the main Gmail scripts. Download time for mail.google.com on slow machines is critical.
The fourth problem . Changes to the library are made not just regularly, but several times a week. Unfortunately, most of these changes do not contain bug fixes and do not add new features, but are aimed at the needs of the main developer Streak. There was a situation when due to one update there was a conflict with the code in the client part of our plugin. In December, a new minor (shadow, without changejlog) version for InboxSDK was released, in which the recipient insertion function was changed. It was implemented in such a way that after adding addressees there was a trigger for saving a draft copy. The saving itself was done in a rather interesting way - it was just a simulation of pressing a certain key across the input field. Before all changes, pressing was implemented using “Enter”, but it was in that change that they began to press the symbol with the code “190” (¾). In our case, when opening an answer form, recipients of this ticket are automatically substituted. Thus, a conflict has turned out: during the response in the ticket, the symbol was inserted in the recipient field.
Switch from InboxSDK to gmail.js
As a result, we gradually decided to switch to something more open, and the Gmail.js library (GJS) became the foundation for a future solution. Unlike InboxSDK, the Gmail.js library is fully open. Its development depends on the community and the functionality can develop at a very good pace.
During the transition, we encountered two main problems:
First , for the Gmail.js library to function, you need access to the window's window object, in which Gmail stores some technical information. The extension in its “sandbox” has access only to the DOM page, but not to its environment.
Secondly , in order to completely eliminate changes to the client part of the plug-in, you need not just a wrapper, but you also need to add functions that are not in the library itself.
For the first problem, there is no perfect solution. All of them are connected with some inconveniences - implementation by adding your own script directly to the page of the
We decided to implement a bridge that, using GJS, reports certain events directly to the plugin. In the current implementation, through the injection technology, the GJS library and our bridge are implemented in the page. Thus GJS works in the right environment. For all extensions, the Google Chrome browser provides a set of methods for working with it. Accordingly, if you do an extension through a direct injection (like the GJS library), then it will lose all the possibilities of working with API extensions, so very important and necessary functionality can be lost.
To solve the second problem, it was necessary to analyze the behavior of not only the InboxSDK, but also the work of the Gmail client side. Now in our extension there are places in the code that are tied to the attributes and classes of the inbox: in some cases they additionally expanded the capabilities of the library, and in some they corrected some inbox errors. Consequently, in order not to disrupt the client side of the plug-in, it was necessary to add the necessary classes and attributes in the same way, add them to certain elements, for certain events and under certain conditions. Earlier it was mentioned that there is no API for working with the client part of Gmail. But there is stored a lot of necessary information. For example, user settings, a list of available mail aliases, a set of included experimental features, and other important technical information.
We managed to make the transition from one library to another, without changing the logic and code in the client part of the plugin. The final solution is not just the use of the GJS library; rather, we have created our own hybrid library, ISDK and GJS. Gmail.js served as the foundation, but our development is functionally similar to InboxSDK. If the Habrahabr community is interesting, and there are many requests to share our code, then we will put it in order and post it.
Why did we choose InboxSDK?
Deskun is implemented as an extension for Google Chrome and Yandex Browser . It fully operates on the basis of the Gmail mail service. For our part, it was necessary to choose a library that could expand the functionality of the mail and work with its client part. We settled on InboxSDK (ISDK).
A key feature of Gmail, for which users love it so much, is the automatic grouping of letters by dialogue. At the internal level (on Gmail servers), each letter has its own identifier and the identifier of the dialogue to which it belongs. But the problem is that in the web client the global message IDs are not contained in the page code anywhere, and the global dialogue IDs are only contained in the hash of the open dialog URL. Instead, the HTML elements of each message and dialogue are marked with local IDs like ": a5,: b6, etc.", received by the main (fairly large and obfuscated) Gmail script. Since local IDs change from page to page and from session to session, for the normal operation of extensions dealing with Gmail mail, it is necessary to quickly establish the connection between local and global IDs. This is what the InboxSDK library does, in which, besides the functions for obtaining identifiers of letters, drafts, and dialogs, the possibilities for improving the user interface are also available.
')
Despite the fact that the ISDK contains a large number of different methods for working with Gmail, this library has one unpleasant feature - Streak, which in turn, provides its own CRM system inside Gmail, is developing it. That is, is an indirect competitor of Deskun.
InboxSDK Problems
Developing your own closed project based on another closed project is at least wrong. Especially if these projects are similar and you can always be denied access to the API simply because you are competitors. Even if this does not happen, at least you have no control over the changes and accessibility. Library developers are not in a hurry to help in writing third-party services based on their library, and the changelogs of new revisions do not carry any useful information. Even the site InboxSDK is practically not updated since launch. And you can forget about fixing bugs at the request of users or adding features that do not relate to the needs of the Streak itself. First of all, Steak makes a library for itself.
The first problem . For the work of the library, a binding to some specific and stable (stable - which do not change when switching the view, changing the state, etc.) classes is used. For example, in some cases, keystrokes on focused elements are emulated. And any changes to the Gmail interface can disrupt the work of the library itself and third-party development based on InboxSDK.
The second problem . Since the library is connected remotely using the loader, there may be interruptions in the delivery of content over the CDN network. For some time we tried to understand what was going wrong, and then we found out that the library, on the basis of which our plugin works, simply does not load for some users. At some point, it turned out that already 10% of our clients could not work with the service. If there were problems with loading InboxSDK, then the work of all platforms built on this library was terminated. It is important to understand that the problem may have a point character, and may not always depend on the hosting. And from our side to correct the source of the problem can be completely impossible and it only remained to wait.
The third problem . InboxSDK is not an open library. The publicly declared functions include a maximum of one third of all available. This is about 400 KB of packaged code that has to be parsed literally right after parsing the main Gmail scripts. Download time for mail.google.com on slow machines is critical.
The fourth problem . Changes to the library are made not just regularly, but several times a week. Unfortunately, most of these changes do not contain bug fixes and do not add new features, but are aimed at the needs of the main developer Streak. There was a situation when due to one update there was a conflict with the code in the client part of our plugin. In December, a new minor (shadow, without changejlog) version for InboxSDK was released, in which the recipient insertion function was changed. It was implemented in such a way that after adding addressees there was a trigger for saving a draft copy. The saving itself was done in a rather interesting way - it was just a simulation of pressing a certain key across the input field. Before all changes, pressing was implemented using “Enter”, but it was in that change that they began to press the symbol with the code “190” (¾). In our case, when opening an answer form, recipients of this ticket are automatically substituted. Thus, a conflict has turned out: during the response in the ticket, the symbol was inserted in the recipient field.
Switch from InboxSDK to gmail.js
As a result, we gradually decided to switch to something more open, and the Gmail.js library (GJS) became the foundation for a future solution. Unlike InboxSDK, the Gmail.js library is fully open. Its development depends on the community and the functionality can develop at a very good pace.
During the transition, we encountered two main problems:
First , for the Gmail.js library to function, you need access to the window's window object, in which Gmail stores some technical information. The extension in its “sandbox” has access only to the DOM page, but not to its environment.
Secondly , in order to completely eliminate changes to the client part of the plug-in, you need not just a wrapper, but you also need to add functions that are not in the library itself.
For the first problem, there is no perfect solution. All of them are connected with some inconveniences - implementation by adding your own script directly to the page of the
script website with postMessage, Custom Event or writing directly to the DOM.We decided to implement a bridge that, using GJS, reports certain events directly to the plugin. In the current implementation, through the injection technology, the GJS library and our bridge are implemented in the page. Thus GJS works in the right environment. For all extensions, the Google Chrome browser provides a set of methods for working with it. Accordingly, if you do an extension through a direct injection (like the GJS library), then it will lose all the possibilities of working with API extensions, so very important and necessary functionality can be lost.
To solve the second problem, it was necessary to analyze the behavior of not only the InboxSDK, but also the work of the Gmail client side. Now in our extension there are places in the code that are tied to the attributes and classes of the inbox: in some cases they additionally expanded the capabilities of the library, and in some they corrected some inbox errors. Consequently, in order not to disrupt the client side of the plug-in, it was necessary to add the necessary classes and attributes in the same way, add them to certain elements, for certain events and under certain conditions. Earlier it was mentioned that there is no API for working with the client part of Gmail. But there is stored a lot of necessary information. For example, user settings, a list of available mail aliases, a set of included experimental features, and other important technical information.
Total
We managed to make the transition from one library to another, without changing the logic and code in the client part of the plugin. The final solution is not just the use of the GJS library; rather, we have created our own hybrid library, ISDK and GJS. Gmail.js served as the foundation, but our development is functionally similar to InboxSDK. If the Habrahabr community is interesting, and there are many requests to share our code, then we will put it in order and post it.
Deskun
Source: https://habr.com/ru/post/335874/
All Articles