@alexey.lunin @zdravko hey guys.
This discussion is a follow-up of the https://community.vereign.com/t/a-time-to-consider-publishing-our-javascript-libs-to-the-outer-world/283/10?u=markin.io.
Let me start directly from the painful points in the current situation with iframe, @vereign/vframe, and @vereign/light-utils
Drawbacks of the current libraries architecture
-
@vereign/light-utilsis heavy and 95% of it’s functionality used byiframeandweb-verification-apponly. -
@vereign/vframeandiframeneeds to use shared code of public API errors (MimeVerificationError,SealAPIError,StatusAPIError). That’s the reason of having them sticked in a single repo. - There’s certainly confusion between
iframeand@vereign/vframeduring the discussions. - If a third-party integrator wants to read seals from emails and load iframes, he/she needs to install both
@vereign/light-utilsand@vereign/vframewhich is really inconvenient.
Proposed solution
So, after some thinking I came up with the idea of aggregating existing functionality into a lightweight integration library called @vereign/lib-seal which is going to expose:
-
IframeService- to load iframe APIs -
SealService- to extract seals from MIME - List of public API errors
With this optimization, Integrators (Chrome Extension and Outlook Add-in) will be able to sufficiently cover the verification routine at their side using only a single library. And pretty much the same goes for the signing routine.
What’s going to happen to the old libs
-
@vereign/vframe- gets removed -
@vereign/light-utils- preferably it should be used only by Web Verification App and Iframe. Chrome Extension and Outlook Add-In will be able to work without it.
List of dependents for @vereign/lib-seal
-
Chrome ExtensionandOutlook Add-in. Using the whole API of the library. -
iframe- uses Public API errors only -
@vereign/mime-normalizer- needs onlySealServicein tests