Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
mattrobenolt
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
9 ms
·
31.
▲
by
mattrobenolt
4y ago
Yeah.
32.
▲
by
mattrobenolt
4y ago
I would not consider myself a member of the JavaScript or TypeScript communities. I just build the infrastructure and platforms to support these kinds of things. :)
33.
▲
by
mattrobenolt
4y ago
I'm going to use a big notice here: None of this is inherently safe to use as a client. This is similar security profile as a database driver. This API has no row level auth or anything like that. Unless this is explicitly what your pr
34.
▲
by
mattrobenolt
4y ago
:see_no_evil: This is an obvious next step for us.
35.
▲
by
mattrobenolt
4y ago
I went down the Prisma path investigating JavaScript ORMs, and... I have opinions. :) I feel that what we have would be useful within a Prisma context, but given their complexity and how Prisma works, it's likely not very practical wit
36.
▲
by
mattrobenolt
4y ago
Netlify uses Deno as it's runtime. :) https://github.com/planetscale/f1-championship-stats/blob/ma... So we work there just fine.
37.
▲
by
mattrobenolt
4y ago
We didn't talk much about this yet, but the underlying tech for this will help you within Lambda too reduce latency even over normal MySQL. This specifically is targeting environments where a MySQL client isn't able to run.
38.
▲
by
mattrobenolt
4y ago
There are, in my opinion, a few other concrete benefits outside of performance too that I didn't touch on. I plan on touching on them more in my follow up blog post though. A lot of this for me/us at this point is still theoretica
39.
▲
by
mattrobenolt
4y ago
Our beta for this is pretty stable. The only real instabilities are around the underlying APIs we use, which is part of why we're not ready to document it just yet. But the underlying tech is exactly the same as we use for handling tra
40.
▲
by
mattrobenolt
4y ago
Great question! Author of a lot of the infrastructure surrounding this here. I plan on following up with a more technical deep dive on some of these aspects, but it's quite a bit hard to do a 1:1 comparison. While, obviously, HTTP also
41.
▲
by
mattrobenolt
8y ago
Hey, developer of Sentry here. We're submitting a patch that prevents showing any settings on this DEBUG page. I'd like to mention that we never suggest running Sentry in DEBUG mode, nor do we document how to do this. Sentry does
42.
▲
by
mattrobenolt
9y ago
Why would you want to lazy load it?
43.
▲
by
mattrobenolt
9y ago
What kind of couch do you have that can fit 6 people? Looking for a new couch.
44.
▲
by
mattrobenolt
10y ago
This is equivalent to shipping bad application code that takes everything down. Except the config is only a handful of lines of code and will very likely never change again. Also, we don't blindly roll out changes cluster wide for thin
45.
▲
by
mattrobenolt
10y ago
SoftLayer. All internal bandwidth is free. Public network is a fixed allocation of bytes per server, then overages.
46.
▲
by
mattrobenolt
10y ago
This is bad for stuff like this because nginx doesn't re-resolve DNS records after process startup. So if an IP address behind the hostname changes, things will just hard stop working. Using it explicitly as a variable coerces nginx in
47.
▲
by
mattrobenolt
10y ago
Is paragraph 2 of the post not upfront enough? I clearly stated our goals of the project, and the fact that this also saves us through the incident was a great side effect. But I never set out to mitigate S3 failures like this.
48.
▲
by
mattrobenolt
10y ago
Also, should note, it's about a 98% savings in bandwidth, but cost savings explicitly was 70% since we have to factor in the cost of running this new server.
49.
▲
by
mattrobenolt
10y ago
Thank you. <3
50.
▲
by
mattrobenolt
10y ago
This doesn't solve our performance issues that I originally set out to address.
51.
▲
by
mattrobenolt
10y ago
Ah, I can't comment about that since we obviously don't use it, but in theory, yes.
52.
▲
by
mattrobenolt
10y ago
We do this automatically already with HAProxy. So we don't even have to change our application.
53.
▲
by
mattrobenolt
10y ago
I'm afraid to know how much that costs.
54.
▲
by
mattrobenolt
10y ago
Disagree. Considering the original goal had nothing to do with expecting S3 to go down, it just happened to be super useful during this incident. We get more more benefits even without S3 breaking.
55.
▲
by
mattrobenolt
10y ago
We even go a step further, and our blobs are 100% content addressable. :) So caching is super easy for us.
56.
▲
by
mattrobenolt
10y ago
It's running on localhost, so it's not it's own machine. It's local to the servers running the application code.
57.
▲
by
mattrobenolt
10y ago
Yes. That was, in fact, the entire point of the blog post.
58.
▲
by
mattrobenolt
10y ago
To be more clear, there are other things we could do here if we didn't inherently trust our network and the things running there.
59.
▲
by
mattrobenolt
10y ago
Good question. Authorization is passed along upstream to S3, but we don't re-check authorization when serving a cache hit. In our case, this is a fine tradeoff since our network is private and trusted.
60.
▲
by
mattrobenolt
10y ago
You should actually read the blog post. We are strictly increasing availability in addition to S3's already amazing availability. Not adding another point of failure and assuming we're better. In fact, I literally assume I'm
More ›