frew

I don't believe so, but we target everything in the Webkit ecosystem (Chrome, Edge, Safari), so Firefox would be the only odd browser out.

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

It does! That was actually one of the motivations for open-sourcing.

Cost was definitely a consideration (although not the only one) in deciding whether to store all created links vs. just a blocklist.

Once we got to a mode where we were only doing computation per request, the raw cost is pretty minimal since there's not much CPU time either way.

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.

Except it is: https://mail.gnome.org/archives/desktop-devel-list/2019-May/...

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.

More details from when I was working through it: https://twitter.com/fredwulff/status/1204861220165017600

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 

Interested? Visit and apply at https://www.streak.com/teams/engineering

(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

(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

(I'm the author of the post - just woke up and saw this discussion. Hi!)

Definitely wasn't meaning this post's title to be clickbait-y. 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

I'm the post author and happy to answer any questions people might have!

Does this runtime have access to the Standard APIs? It doesn't seem like the docs have any mention of Task Queue/Memcache/etc.

We (Streak) are based on a browser extension, but we're actually really excited about this launch since it works on the native Gmail mobile apps and it lets you install addons once and have them work across all your devices.

The graph itself is d3: https://bost.ocks.org/mike/sankey/

Based on random use over the past few years.

Redshift: Pros: Has the most adoption, so most integrations from SaaS services etc. are built with Redshift as their sink. Relatively fast and battle-tested.

Cons: In an awkward middle ground where you're responsible for a lot of operations (e.g. capacity planning, setting up indexes), but don't have a lot of visibility. Some weirdness as a result of taking PostgreSQL and making it distributed.

BigQuery: Pros: Rich feature set. Pay-per-TB pricing. Recently released standard-ish SQL dialect. Very fast.

Cons: JDBC driver is recent and doesn't have support for e.g. CREATE TABLE AS SELECT (as of a couple of months ago) so harder to integrate with existing systems. There are ways to run out of resources (e.g. large ORDER BY results) without a good path to throw more money at the problem.

Athena: Pros: Built off of the open-source Presto database so can use the documentation there. Pay-per-TB pricing.

Cons: Slower than the other options listed here. Very early product so lacking some in documentation and some cryptic errors. Not a lot of extensibility, but you could theoretically move to just using open-source Presto.

Haven't had a chance to evaluate Snowflake.

Used to work at Dropbox. Existing knowledge of new hires was 90% of the challenge with Mercurial with the other 10% being weird edge cases (e.g. very large/numerous repositories) that hadn't seen as much attention due to the smaller community.

Added a clarification to the relevant section. Apologies again for the confusion!

Apologies if I misrepresented Kafka's replication. So the system described in the blog post is the new 0.8.2+ stuff with min.insync.replicas taking over required.acks? Will review.

The cert on https://signed.bad.horse/ is also amazing.

corylouie is on Dropbox's security team.

(I work for Dropbox but don't speak for it in this capacity)

Returning accurate search result counts (i.e. "give me an exhaustive list of all pages that match this query") is at cross purposes to the main search problem (i.e. "give me the best ten pages for this query"). For the former, you want to be exhaustive, for the latter, you want to cut every corner you can to get results back as quickly as possible. Google optimizes for the latter at the expense of the former. Basically, don't put too much stock in any of the numbers you get back from Google.

Really great article and neat product!

One question: on the throughput graphs, I understand why you normalized them per graph, but were there any differences between graphs (particularly in terms of EBS vs. ephemeral) that would be sufficient to drown out the variability within the throughput graphs?

Hey Sean,

We looked into a lot of logging solutions and couldn't find a solution that fit our requirements. In particular, 1) at the moment we don't run any servers (even virtualized) ourselves, and we're loving not having to worry about that level of infrastructure. Splunk and most other logging solutions would have required running a VM just for the daemon (either proprietary or syslog). 2) the total cost of developing Mache was significantly less than even a single 500 MB Splunk license. 3) most other solutions that we looked at really want to treat logs as lines of text data. App Engine logs provide more metadata, and we didn't want to lose and have to reconstruct that data.

What product are you working on that it's possibly worth your time to test with FF 1? It's got like 0.01% marketshare at most. People mention IE 6-8 because large numbers of people are still on it due to corporate IT policies.