Hacker News Reader

Comment by adeptima | Hacker News Reader

InboxSDK is very nice. However my personal stopper is the use of YOUR_APP_ID_HERE for broadcasting to mothership.

Didnt check the source code fully for a while.

1. hello-world example gives you a warning right into the face:

InboxSDK Developer Warning: Invalid AppId You've loaded the InboxSDK with an unregistered appId. Registration is free but necessary to load the SDK.

https://github.com/InboxSDK/hello-world

It would be great to see it truly open source without YOUR_APP_ID_HERE hustle

2. source code looks a bit old search /* @flow */

3. https://github.com/InboxSDK/InboxSDK/blob/main/package.json dev dependencies mixed with everything else

Overall it's still a very valuable project. Hacking into gmail or any other big SaaS service UI is multiyear unpleasant journey. Did it for LinkedIn myself. Lot of respect in InboxSDK team anyway.

View on HN

The fundamental motivation for the app id concept is that part of the value that InboxSDK provides is cushioning the developer from version conflicts, both from Gmail updates and from multiple extensions that all use InboxSDK. So we use app ids + a custom error reporting mechanism to aggregate anonymized error reports in order to figure out incompatibilities + reach out to the developer as appropriate.

You're welcome to make the app id opaque. Also feel free to file an issue for making a setting to disable the app id - definitely not opposed to adding it as an option given interest.

-Fred

Eng @ Streak

Fred, your comment is greatly appreciated! Will investigate more

(Streak and InboxSDK developer here)

>2. source code looks a bit old search /* @flow */

The codebase is in a hybrid setup of Flow and Typescript right now as we've been incrementally moving to Typescript. We've been opportunistically updating code to Typescript as we go. Both parts are still typechecked and we still see either system as a massive improvement over untyped Javascript. There is some awkwardness at the boundaries requiring some types to be specified again in the other system, but neither has any real concepts the other doesn't so it's not as painful as one might think. We do expect to get the codebase to pure Typescript in the future; we've recently finished a large conversion of an internal non-InboxSDK codebase of ours.

>3. https://github.com/InboxSDK/InboxSDK/blob/main/package.json dev dependencies mixed with everything else

That package.json isn't actually part of the published npm package. Only the files in packages/core/ are published in the npm package. The project wasn't originally set up to be published on npm and when we started publishing to npm, we wanted the package to have a separate readme and directory structure from the main then-private repo so we set up that separate directory for publishing it. There may be some room to streamline that setup, especially since now there's no public/private split.

Wow. This is bad in so many ways. Hasn't nobody made a truly free as in freedom fork?

No necessary bad or evil. However perception of intentions here dont give a good feeling. Better to investigate more.

See Fred's comment above - the one thing that's different about our SDK vs typical JS libraries is that Gmail is a moving target AND several extensions may be working modyifying Gmail at the same time. It's really important that developers are on the latest compatible versions of the SDK.

The app id's are used to reach out to developers who may be on too old of a version of the SDK.

All that being said, seems like we could make this opt in. Another idea might be to post warnings in the dev console (in dev mode) if the version of the SDK you are using is too old. We'll explore all of these but have other ideas?

Reply on news.ycombinator.com