|
|
|
|
|
|
by aaanotherhnfolk
2292 days ago
|
|
|
We also decided not to use InboxSDK because it has to dynamically load from Streak's servers. If you are open source hobby project this is probably okay, but for a real business this is a potentially business-ending risk. 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.