InboxSDK – Build apps inside Gmail
inboxsdk.com
inboxsdk.com
I then tried to use Gmail.js for a while, but it seems not that stable, the extension got a lot of complaints of not working from time to time (Gmail.js cannot load email data correctly, but not every time).
After a few months, I finally decided to parse the DOM data myself, it's actually not THAT difficult, if you are not trying to build an extremely powerful extension.Gmail.com did change the UI from time to time, but it's not that huge actually. For the latest big UI change on Gmail, I remember it took me about 1MD to finish all the required code changes.
Unlike InboxSDK, Gmail.js is open source. You actually do have the power to fix things if you like.
I think that’s an important difference. I’ve fixed things in Gmail.js when I needed them fixed.
Have you?
1. I remember it greatly depend on hijack of a global variable in Gmail.com, but occasionally the value is not available (depend on where the user refreshed the page and network speed of the user)
2. it try to send network requests to Gmail.com directly (on behalf of logged in Gmail user) and get the query result, but those API are supposed to be used only by Gmail.com internally. So once the API format changes, some data could not be collected.
In general I think this approach raised too much dependency on misc aspects of Gmail.com. Now customized DOM parsing also depend on Gmail UI, but that should be the ONLY thing that would break the system.
What do you do if Streak's servers go down? You pay them nothing and have no priority support.
What do you do if Streak pushes a breaking change and brings down your app in real time?
What about if Chrome Web Store continues to lock down the ecosystem and restricts all dynamic script loading from cross origins?
We only needed a fraction of InboxSDK's API footprint so we just built our own adapter layer similar to theirs covering what we need. Now we control our own destiny.
I think their SDK had a better value prop when Google was maintaining both Gmail and Inbox. But now that they've merged there's only one DOM to worry about. And let me just say from experience that Google alters the Gmail DOM very rarely. I think they know there are a ton of extensions leaning on it, which is why they communicated the new UI so far in advance.
Will try to address some of your questions:
> What do you do if Streak's servers go down? You pay them nothing and have no priority support.
It's a fair concern, we don't charge for the SDK. But we do charge for Streak and have built an 8 figure business. We care a lot about the dependability of the SDK because we care a lot about our own business. Streak loads the SDK in the exact same way as other extension developers do and we use the exact same APIs. We also have large organizations that depend on our uptime (Dropbox, Hubspot, etc)
> What do you do if Streak pushes a breaking change and brings down your app in real time?
We are the most advanced user of the SDK (we use almost all the APIs) so we'd be breaking ourselves too.
> What about if Chrome Web Store continues to lock down the ecosystem and restricts all dynamic script loading from cross origins?
Great question. It is true that they are locking down the remote loading. InboxSDK currently has an exemption to this rule (as do some other popular and similar libraries). However, over the long term (think years) we will move away from remote loading. We're currently working with Google on a solution that should retain some of the benefits of remote loading, while allowing Google to statically analyze the SDK for security. It hasn't been finalized but the SDK will be allowed to continue remote loading until that is in place. Remember, we have every incentive to make this work for everyone including ourselves.
There's probably a segment of small mid-sized businesses to prey upon making apps with this; but outside of that this has got to be the most terrifying platform to ever build upon.
1. It's based on a specific email provider.
2. That provider is google.
3. Google has zero incentive to give a shit about about anyone or anything using its platform.
4. Average SDK releases per week: 12 (screw the fact GMail hasn't been responsible for breaking changes)
Focusing on a tool that does this shit, on any platform, or one that integrates into any email provider... that'd be neat. This I am afraid of...
> probably a segment of small mid-sized businesses to prey upon making apps with this
There's a bunch of poorly run, but funded start ups, and mid sized businesses, that are literally powered by excuses. Very likely anything built with this is powering the train of excuses, not solutions. I'd go so far as to point out that Streak made it... Meaning they're obviously trying to branch out because their market isn't shit; which means, your potential market, is a segment of shit... (well as far as this site's scaling model is concerned).
If you want a lifestyle business (which I think is perfectly freakin' awesome)... sure, maybe (read: not) this is for you. But even then... it's a lot of risk for something you could probably do with one or two people. Just look at the fucking SDK changes; yeah GMail doesn't necessarily break shit, but... they (streak) do. How is that any better than your own set of brittle scripts which you have to maintain multiple times a week?
I think this is a gimmick at best, and at worst it'll completely waste someone's time and money.
Just to clarify a few things, our market is actually great, the CRM industry is huge and we do very well in it - we're profitable!
As for why we made the SDK, we're not "branching" out - we made this for ourselves because we needed it. We built a bunch of tech to wrangle Gmail and the way we engineered it is we separated it from our main business logic. We didn't want others to have to go through what we did (reverse engineering a lot of gmail) so we made it available for anyone to use. We don't charge for it and we maintain it for free.
Several large companies (Dropbox, HubSpot, etc) depend on this SDK to power their Gmail integrations so it's not just small and medium sized companies.
Your comment was a bit harsh, but I guess that means we need to address this stuff better on our website.
So glad you guys brought your solution to the world as freeware so scrappy startups like mine could avoid having to chase all those updates.
I've read this sentence a couple times and have no clue what you're trying to say. By this logic anyone who uses AWS is working in a "shit" market, which is not the case.
"it's a lot of risk for something you could probably do with one or two people"
Have you ever tried to do this? It is harder than you might think. In addition, one or two people will cost ~300k/year which is a lot.
Your comment is ridiculously dismissive and poorly argued.
Companies who want to be integrated everywhere often have to write a lot of product-specific integrations.
Outlook, Office365 etc... And Gmail because Gmail is big.
> screw the fact GMail hasn't been responsible for breaking changes
As someone contributing to Gmail.js, allow me to absolutely counter this claim.
The change to “new” Gmail took months of effort to properly reverse-engineer, and there’s been small changes in behaviour since launch which breaks stuff some of the time.
You realize it's mostly for enterprise companies building internal tools, right?
Gmail is known to have been locking down actual front-door server-side API access for 3rd party applications for years. Perhaps this is the natural result. Chrome extensions that add hacks to the Gmail frontend instead.
Same user-data harvesting but with less reliability! Fun times.
This goes for everything from your pop-up blocker, to your password manager, to that silly user script doing <fun effect>. They all watch you browse in a way that circumvents good security hygiene.
It's extremely common for extensions with successful userbases (>10k installs) to get approached by folks asking to integrate a mining SDK for revenue share, or sell the extension outright so they can monetize it themselves.
Consider yourself lucky if all the extension does is steal cpu cycles. It could just as easily be exfiltrating your email bodies or watching all password input fields.
The browser extension model is broken. Expect it to slowly die. Manifest v3 is just the beginning. Soon Google will wonder why they're paying a team of manual reviewers to study every extension on the Web Store when the marketplace monetizes so poorly and doesn't contribute to the moat around Chrome.
The true question is: when is GMail changing its CSS class names ;)
How could anyone trust a company to do a good job working with really complicated web technologies, when they can't even do a simple website to advertise their product?
Also, we don't officially support Firefox yet.
Since Google's fans ironically can't Google, docs below:
https://docs.microsoft.com/en-us/office/dev/add-ins/
is the modern typescript/web API. It's not totally feature-complete (yet), so you may need to develop a VSTO add-in in C# or VB, which will unfortunately not work with the web client. Docs for that:
https://docs.microsoft.com/en-us/visualstudio/vsto/create-vs...
https://docs.microsoft.com/en-us/office/dev/add-ins/overview...
The way we ensure this is by remote loading most of the SDK from our servers to ensure users are on the latest version of the SDK.
One thing we wanted to prevent was developers including the stock SDK directly in the extension or even forking their own version and including it in their extension because then we can't guarantee it will always be compatible with other extensions or Gmail. We'd have to rely on developers constantly upgrading their dependency on us and submitting an extension update to the chrome store.
There are ways where we can still host the SDK but open source it so people can contribute/inspect the code - we just haven't gotten there yet but it is part of our plans.
> one thing we wanted to prevent was developers including the stock SDK directly in the extension
(and I feel for Streak, having worked on a Gmail extension (Mixmax) until recently), but this seems to be exactly what manifest v3 will require. Curious if you have another strategy, @alooPotato.
It is true that they are locking down the remote loading. InboxSDK currently has an exemption to this rule (as do some other popular and similar libraries). However, over the long term (think years) we will move away from remote loading. We're currently working with Google on a solution that should retain some of the benefits of remote loading, while allowing Google to statically analyze the SDK for security. It hasn't been finalized but the SDK will be allowed to continue remote loading until that is in place. Remember, we have every incentive to make this work for everyone including ourselves.
Also this InboxSDK is for integrating in the Gmail webapp UI which many people use and want to stay within when adding functionality to their email service.