Show HN: Open-Sourcing InboxSDK (YC S11) – Build Apps in Gmail https://ift.tt/KOLz3Ah

Show HN: Open-Sourcing InboxSDK (YC S11) – Build Apps in Gmail Hi HN! We’re Aleem, Chris, Borys, Meichen and Zach from Streak (YC S11) and today we’re open sourcing our InboxSDK https://ift.tt/TWrn62h , which makes it easy to build apps for Gmail. Over 1.8B users spend their days in Gmail! Having your app built into the Gmail workflow is a better user experience and gives you great user retention. InboxSDK gives you a high-level, declarative API to insert your UI into Gmail without having to directly manipulate the DOM yourself. End users install a browser extension to use your app. The SDK can add UI to multiple areas of Gmail. For example, adding a button is as simple as: composeView.addButton({ title: "My Nifty Button!", iconUrl: 'https://ift.tt/J37Hb1d', onClick: function(event) { event.composeView.insertTextIntoBodyAtCursor('Hello World!'); }, }); InboxSDK enables you to add info to the sidebar on threads, add items in the left navigation tree, insert results into the search box, navigate to full page routes, add toolbar buttons to the compose window, add label indicators to thread list views and many more. You can see some examples in my comment posted below. Hubspot, Dropbox, Giphy, Clickup, Loom, Todoist, Clearbit and our own Streak have all built apps using the InboxSDK. The InboxSDK is open source dual-licensed under the MIT and Apache 2.0 licenses for maximum flexibility. Why use the InboxSDK over rolling it yourself? Several reasons: (1) it’s hard to do DOM manipulation in a performant way; (2) you need to handle all the different configurations of Gmail—there are a lot, and they change often: e.g. conversation view on/off, multiple inboxes, chat left/right, personal vs Workspace accounts; (3) You have to maintain compatibility with tons of other Gmail extensions so you don’t stomp over each other. On a technical level, the InboxSDK handles all the DOM watching and manipulation, XHR interception, multiple extension coordination, and exposes a high level API to developers. We make use of page-parser-tree, another package we open sourced that helps detect elements on the page performantly. The trickiest bit we handle is intercepting and modifying network requests that Gmail makes in order to support several of the APIs we expose. We’ve been building this SDK for years - it’s what powers Streak (www.streak.com), an 8 figure ARR SaaS business. We built the InboxSDK for ourselves because we wanted to separate our logic for wrangling Gmail from that of our app. Several years ago we let developers use a hosted version of our SDK. We didn’t want anyone else to go through the same pain to integrate deeply with Gmail. There were two unexpected benefits: It vastly increased the number of end users (20M+) using apps built on our SDK. This gave us significant leverage with Google. They are super supportive of the SDK and give us early access to several builds to ensure the SDK doesn’t break when they make updates to Gmail. We spent an ungodly amount of time maintaining compatibility with other Gmail extensions. Once the InboxSDK became a defacto standard, all the apps (currently >1000) that used it were instantly compatible (the InboxSDK operates under the model that there will be several extensions running at the same time and it elects a leader to route all modification through). Why open source it now? First, several companies were nervous about us hosting the SDK. We mainly did this so that every extension was running the same version of the SDK, but with the recent Chrome manifest V3 changes, remote code execution is no longer supported. Not hosting the SDK removed the primary reason why the project needed to be closed source. We do need to figure out a new way of keeping all developers relatively up to date on the latest version of the SDK, any ideas? We’d love feedback! The repo is https://ift.tt/h1rVNp2 , and the docs are: https://ift.tt/r9u847F October 11, 2022 at 05:55AM