ianstormtaylor

I love this concept.

For anyone who’s interested in doing this, but doesn’t want to manage the infrastructure you should check out Supabase. (I’m not affiliated, just a fan.)

Absolutely love the idea of combining regular note taking with the power of an infinite canvas. Congrats on the launch!

Just read “LaserWriter II” and it was a surprisingly fun read. All about the characters in an old Apple repair shop in the ‘90s. The writing style is really unique, and the nostalgia was high. Discovered it while eavesdropping on someone recommending books in a bookstore.

https://www.goodreads.com/en/book/show/56269270

Wow, it's really refreshing to see authorization explained in a way that dives into the fine details. Most articles I've seen introduce global role-based restrictions and leave it at that which is super frustrating.

Oso looks really well considered. Wish I had this in the past. Well done!

Extremely good idea. I've had to implement webhooks in the past and it was a huge pain (and my implementation likely had tons of bugs anyways). Turning into a well architected service seems like a perfect fit.

Congrats on the launch and good luck!

Wow, this is really well put together! Anyone know an equally good guide for Python?

It depends on what type of accounting is being used. If it’s a production-based accounting then they’ll be attributed to China. But if it’s a bottom-up, consumption-based accounting then they’ll be attributed to the consumer in the United States.

It’s great that both approaches exist, because they surface different conclusions. If you want to see where the actual emissions are being emitted, or what “industry” they’re from, then the production-based accounting will give you that. If you instead want to see what different consumer-level behaviors are responsible for most emissions then you’ll need a consumption-based accounting.

That duality is what makes it hard for people to grok carbon accounting estimates sometimes.

It's not hard to think of examples...

1. HTTPS everywhere has zero impact on the usability of a website, but makes visiting those sites much more secure.

2. Apple's App Store model for installing applications improves security and is also easier to use for the average user.

3. 1Password with Touch/Face ID can actually be easier these days than entering emails and passwords manually.

4. And more…

Security doesn't always have an immediate effect on usability, and even when it does it isn't always negative.

Not exactly.

I'm not sure where you're getting the 3% number from. If you read the New York Times maps page data[1] and just divide the total deaths by total cases you get 3.7%, but that isn't the death rate because it doesn't take in to account a lot of factors.

Instead, there's a good article[2] about how bad the virus will get, that says estimates put it in the range of 0.1% to 3%. (With the seasonal flu being somewhere around 0.1%, but the Spanish Flu of 1918 being somewhere around 3%.)

That said, the general intuition that less reporting of cases means that some part of the death rate is over-inflated makes sense. But also consider that there are factors that go in the other direction. Anyone who currently has the virus but has not recovered or died can be under-inflating that rate. And there are likely lots of other factors, which is why articles often mention that the "true" death rate cannot yet be calculated.

(Also the death rate varies a lot with age, and isn't the only factor in determining the "badness" of a virus. Which that second article goes into more depth on—things like how contagious it is, and how early a vaccine can be developed. So the average rate being half of the current numbers doesn't necessarily mean the concern is over-inflated as well.)

[1]: https://www.nytimes.com/interactive/2020/world/coronavirus-m...

[2]: https://www.nytimes.com/interactive/2020/world/asia/china-co...

> Finix has told TechCrunch before that, unlike Stripe, it doesn’t think of itself as a payments company but rather a payment infrastructure company. Most notably, it likes to note that it doesn’t take a percentage of transaction fees but instead charges customers a monthly software fee, along with a sliding fee associated with the number of payments they process. Yet Stripe has a product, Stripe Connect, that operates much the same way and has since its debut in 2013.

Ehhh... sounds (and looks) very much like a clone of Stripe to me. And saying, "we're different because we are infrastructure", is just icing on the dishonesty cake. Not sure why Sequoia would ever have invested in a copycat to Stripe in first place.

Not sure if you’re joking or not, but that is not how it works at all.

https://ensia.com/features/methane-landfills/

Prepare for it to not work in Edge in ~1 month when they switch to being Chromium-based.

In case anyone's interested, here's the Chromium bug(s) that's one of the main reasons the WYSIWYG editor has such issues in Chrome(/Electron):

- https://bugs.chromium.org/p/chromium/issues/detail?id=102937...

- https://bugs.chromium.org/p/chromium/issues/detail?id=608393

- https://bugs.chromium.org/p/chromium/issues/detail?id=608162

The gist of it is that they "canonicalize" the DOM selection when you have two adjacent inline elements, so that it can only ever be at the ending edge of the first inline element. Which makes certain selection states impossible. And on top of that, they don't draw the cursor in the right spot when doing the canonicalization. So for instance, it might look like your cursor is here:

    <b>one</b>|two

But it's actually here:

    <b>one|</b>two

Drawn in the wrong place. And impossible to put it at the beginning of "two" at all! It's crazy!

I don't know how much the take "starring" into account, but it can't hurt to star them in the hopes they're fixed sooner.

---

Edit: If you want to see the craziness in action, check out this sandbox:

https://codesandbox.io/s/amazing-breeze-6elsy

1. Try to put your cursor at the end of the word "one"

2. Try to type a character at the start of the word "two"

"In many of the descriptions below, two communicating parties will be referred to as Alice and Bob; this is the common nomenclature in the crypto field and literature to make it easier to identify the communicating parties. If there is a third and fourth party to the communication, they will be referred to as Carol and Dave, respectively. A malicious party is referred to as Mallory, an eavesdropper as Eve, and a trusted third party as Trent."

I really love this naming system.

If anyone is interested, I think part of the issue with why inline code formatting is so hard is related to these two Chromium bugs:

- https://bugs.chromium.org/p/chromium/issues/detail?id=608393

- https://bugs.chromium.org/p/chromium/issues/detail?id=608162

If you star/comment on them to increase the understanding for Chrome's team that they are incredibly frustrating that would be amazing!

Great article! I always love hearing Stripe talking about their internals.

I've been using this practice and I agree that it's incredibly useful. I think because people tend to think in terms of "logs", they end up overlooking the much more useful construct of "canonical logs". Many fine-grained logs themselves are almost always less useful than the fewer fully-described canonical logs. Other observability tools often call these "events" instead of "logs" for that reason.

There's a tool call Honeycomb [1] that gives you exactly what this article's talking about in a really nicely designed package out of the box. And since it handles all of the ingestion and visualization, you don't have to worry about setting up Kafka, or the performance of logplexes, or teaching everyone SQL, or how to get nice graphs. I was a little skeptical at first, but after using it for over a year now I'm completely converted.

If you record fully-described "events" for each request, and you use sub-spans for the smaller segments of requests, you also get a waterfall-style trace visualization. Which eliminates the last need for fine-grained logs completely.

If this article seems interesting to you, I'd highly, highly recommend Honeycomb. (Completely unaffiliated, I just think it's a great product.)

[1]: https://www.honeycomb.io/

When I see things like this:

    setcfg({'framework': 'React'})

I immediately think to myself that the designer of the API either (a) values tiny function names over understandable ones, or (b) hasn't given naming enough thought to be consistent. Either way, it's not a good sign and turns me off from investigating further.

The most useful thing Cloudflare could do is allow us to disable the `__cfduid` cookie. That's one of the big reasons I stopped using Cloudflare on a public-facing API/CDN.

Fun article to read, and has some interesting ideas!

In case anyone else is interested I wrote a similar style of article about refactoring GitHub’s interface a few years ago too:

https://ianstormtaylor.com/refactoring-githubs-design/

Are there any big differences to this compared to Heroku’s Postgres? (Not that there need to be, just curious if there’s reason to prefer one.)

I’m still waiting for one of these providers to crack infinite scaling (similar to Aurora). Seamless patching is a good step though.

Thank you for the detailed answer! That makes sense. Although I still find it strange... Now markets itself as preventing lock-in because it can deploy to any cloud, but to realistically use any database with it you have to lock yourself in to one of the cloud providers?

So to use serverless, you need to setup an extra non-serverless instance in front of your database?

Potentially noob question... but how does having a lambda function per route work with connection pooling for something like Postgres?

Also, does ZEIT have any plans to offer hosted databases like Heroku and others do? That's one the biggest blockers in my mind to trying it out.

How do you keep track of the nodes in the "graveyard"? Does that mean that each node has to have some sort of UUID across clients?

If you look at the career trajectory of frontend developers, I'd bet that more of them learned HTML, CSS or JS before they learned many (if not all) of the things listed under "General Development Skills". Not that those skills aren't important, but they're not entry points for learning.

Thanks for the response!

I agree, having queries live in the client is a great goal for DX on the frontend. The ideal being to have them co-located right with the components that need the data. But the issue is that these kinds of solutions are often presented without discussing their tradeoffs. From the article:

> Because persisted queries are static by definition, they also give you the possibility of optimizing execution on the server for specific queries, for example by hand-crafting a highly efficient database query.

Well, that's a bit harder when the client controls the queries and they're automatically "recompiled" on each new deploy, because now you're optimizing a moving target that could change dramatically with little notice. It's not really a benefit, since it's such a fragile situation to be relying on in the first place.

Persisted queries also kind of make co-location of queries with components a non-starter. Maybe Apollo doesn't want to allow co-located queries, which could be an okay decision, but isn't really discussed much as a tradeoff.

And then it doesn't solve the larger issue that these solutions don't work for public-facing APIs. So you end up having to solve the same issues (eg. bandwidth, security, caching) again in an entirely new way.

I think it's something the community will need to address if public-facing GraphQL APIs are going to flourish.

+1 to this. These kinds of benchmarks of the actual execution of a server are almost never useful for actual production loads—it's always going to be the database or external services.

It's the same kind of thing as Express.js competitors showing that their routing logic handles 50k requests per second instead of Express's 25k, but only for "simple" use cases—AKA ones that don't involve a database. You should almost never be evaluating a server on these parameters.

Quiver looks interesting, congrats on launching! It seems like it will be very useful for internal GraphQL APIs.

It does bring up something that I think the GraphQL community hasn't really addressed well yet though... Part of the way Quiver works is that it only allows pre-defined queries which can then be compiled ahead of time.

> Only allow certain queries from a document store.

This is becoming a common response for how to make GraphQL performant and "secure". [1]

But this solution only works for internal APIs. If you're trying to expose a public GraphQL API it isn't viable.

Not only that, but to sync these "persisted" queries from the client to the server, lots of the persisted query tools require you to hard-code GraphQL queries as `.graphql` files in your repository... effectively re-inventing hard-coded REST responses. Except with an extra build process between the client and the server for each new deploy. You no longer really have each component requesting exactly what it needs.

The more research I do into GraphQL, the more it seems like the promise of "query anything" that libraries are selling is often discarded when you get to actual implementation. And you end up with a situation that is much more similar to REST/HTTP than originally intended.

[1]: https://dev-blog.apollodata.com/persisted-graphql-queries-wi...

Your own comment equates the level of protection PGP provides to that of plaintext. Which sounds to me like another way of saying, “PGP is broken”.

It's mentioned quickly in passing, in a kind of "cover our bases" way. The article doesn't once mention Amazon Prime, which is crazy considering it's the obvious success story. But that's because the whole article is framed from a storage point of view, with a few meandering paragraphs tacked on about the future.

Case in point, the Hacker News title was renamed to be "more clear" to "Google is rebranding storage plans as 'Google One'", totally missing the point.