We don't officially support it but some folks have had success.
From a user perspective, we used to get asked all the time to support Firefox for Streak. Those requests have mostly disappeared more recently - seems like our user base is predominantly Chrome and Edge.
> Those requests have mostly disappeared more recently
Could it be because Firefox users have given up? I wonder what percentage of your user base would be Firefox users if it were supported. Of course I don't have an answer to that, but I don't think lack of requests necessarily translates to lack of interest.
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.
This is impressive! For folks who are worried about what this says about App Engine's security - historically the JVM level sandboxing was one part of an overall sandboxing story (not surprisingly, very similar to Chrome's setup) and my understanding, although haven't been on the team for a decade at this point, is that the JVM-level restrictions have been effectively replaced by a gVisor-based solution.
That is hearsay at best, an intentional strawman at worst. The fact that bitkeeper uses master and slave repositories has no relationship on the meaning of master for git branches.
It looks like the play here is to get a bunch of small, committed workloads that GCE can move around where they've got spare capacity. On-demand pricing is very similar to the existing n1 type, but 1yr committed discounts are 30%+ cheaper.
I wish it was simply flat 30% cheaper. It is very misleading that 0.99% of month will be 30% cheaper than a full month, considering that Google Cloud is advertising sustained usage discounts everywhere.
Streak | YC S11 | Engineering Manager | Vancouver, BC & San Francisco, CA | Full Time | Onsite
Streak is hiring our first dedicated engineering manager who will be directly responsible for some or all of our engineering team (currently ~15 engineers, distributed between product, infrastructure, and mobile).
* Problem: Make Gmail powerful for all businesses
* Product: We build a sales/hiring/fundraising/dealflow tool all inside Gmail. We believe these workflows belong entirely in your inbox because thats where people spend their entire day.
* Traction: Product market fit, hundreds of thousands of users, tens of thousands of paying users
* Funding: $2M seed, profitable and growing ever since
* Stack: Java, Kotlin, Golang, React, all the modern JS tooling - built on GCP, largest user of Google Cloud Spanner
(I'm the author of the post - just woke up and saw this discussion. Hi!)
Will put together a follow-up with some more information, but in summary:
* yeah, no built-ins for graph operations in Spanner other than relational SQL for standard joins
* the key thing that make this work are the ability to easily construct global indexes that aren't sharded by the primary key and reasonably fast joins between them
* it's also helpful that Spanner does a reasonable job of parallelizing queries (e.g. a lot of times we'll get a 15x increase in speed vs. a sequential plan)
* we then do the fan-out across the graph in our Java Spanner client - each distributed SQL index read takes ~10 ms so we can do multiple round trips of graph traversal in the client
Would love to know more details about the graph traversal/fanout part. This is the stuff that most of us go to spark for, so would love to know how spanner makes this easier.
(I'm the author of the post - just woke up and saw this discussion. Hi!)
The intention wasn't to hold out Spanner as a purpose-built graph database, but rather to talk about using it for a graph-y database use case. Will put together a follow-up with some more information, but in summary:
* yeah, no built-ins other than relational SQL for graphs
* the key thing that make this work are the ability to easily construct global indexes that aren't sharded by the primary key and reasonably fast joins between them
* it's also helpful that Spanner does a reasonable job of parallelizing queries (e.g. a lot of times we'll get a 15x increase in speed vs. a sequential plan)
* we then do the fan-out across the graph in our Java client
