Live data from Hacker News

My thoughts about Fly.io (so far) and other newish technology I'm getting into

blog.hartleybrody.com

11–20 of 111 posts

Re: My thoughts about Fly.io (so far) and other newish technology I'm getting into

#11
post #9

A little note about read replicas and problems I've discovered. It's often the case in code that you write a value to the DB then immediately read it back often in the form of a different query somewhere else. If you are setup to do some kind of a round robin read from the read replicas you can often get a different read from what you wrote as the value hasn't replicated to your read replicas yet. The solution is to…

This depends on the database and consistency level it’s enforcing. You can often configure databases to require an ack from the replicas before it returns, so that you’ll be able to read your writes. This obviously has a trade off with speed.

Some databases are cleverer about this. Things like Spanner and FoundationDB work differently so as to be fast to both read and write, but they’re much more complex to operate and use.

There is another quick trick though… if a client performs a write, set a bit in their session that causes all of their reads to come from the primary database for a short period, maybe a few seconds, just enough to cover the replication latency. This is a hack. It’s got a lot of downsides, but it’s a quick way to patch the problem if truly necessary.

Re: My thoughts about Fly.io (so far) and other newish technology I'm getting into

#12
post #3

An unrelated, yet honest question. There have been many posts hitting the HN frontpage regarding fly.io recently. Is it healthy to have so much content about a single PAAS platform showing up here so often now?

A big competitor of theirs, tailscale, also does well here.

I think the lesson is partly that the typical somewhat-deranged writing style/topics are popular. More companies should try to write engaging blog posts and be more open if they want to be successful.

It seems to have paid off for them as I would guess at least some of the people trying it out are learning about fly.io from HN.

Re: My thoughts about Fly.io (so far) and other newish technology I'm getting into

#13
post #3

An unrelated, yet honest question. There have been many posts hitting the HN frontpage regarding fly.io recently. Is it healthy to have so much content about a single PAAS platform showing up here so often now?

As per dang's comment a few days back(1) > I wish more startups would achieve this, YC or not. Whenever I run across one that's trying to succeed on HN, I try to help them do so (YC or not)—why? because it makes HN better if the community finds things it loves here. Among the startups of today, I can think of only two offhand who are showing signs of maybe reaching darling status—fly.io (YC), and Tailscale (not YC).…

Interesting to consider the power the mods have here to nudge certain companies into the lime-light of influential technologists.

Re: My thoughts about Fly.io (so far) and other newish technology I'm getting into

#14
post #3

An unrelated, yet honest question. There have been many posts hitting the HN frontpage regarding fly.io recently. Is it healthy to have so much content about a single PAAS platform showing up here so often now?

My personal feeling (based on what I upvote) is that ycombinator isn't getting enough quality writing about tech issues to fill the front page, so if it's "full of fly.io", that just means there isn't enough stuff about other systems at the moment.

Same reason for a while the world seemed full of Rust articles -- at that point in time there wasn't (speaking as a C++ programmer) a pile of quality C++ articles around which the Rust was pushing out.

Re: My thoughts about Fly.io (so far) and other newish technology I'm getting into

#15

Cloud Run is an alternative to fly.io that scales to zero so it can be much cheaper but with added cold starts.

Isn’t the whole appeal of fly that they’re geolocated near your users, reducing latency so you can use fancy serverside rendering stacks like Phoenix?

Cold start latency kinda ruins that no?

Re: My thoughts about Fly.io (so far) and other newish technology I'm getting into

#17
post #9

A little note about read replicas and problems I've discovered. It's often the case in code that you write a value to the DB then immediately read it back often in the form of a different query somewhere else. If you are setup to do some kind of a round robin read from the read replicas you can often get a different read from what you wrote as the value hasn't replicated to your read replicas yet. The solution is to…

This depends on the database and consistency level it’s enforcing. You can often configure databases to require an ack from the replicas before it returns, so that you’ll be able to read your writes. This obviously has a trade off with speed. Some databases are cleverer about this. Things like Spanner and FoundationDB work differently so as to be fast to both read and write, but they’re much more complex to operate a…

I think that's an interesting idea.

Here's a post that benchmarked multi-region Postgres (Elixir/Phoenix on fly.io): https://nathanwillson.com/blog/posts/2021-09-25-fly-multi-db...

According to the post, for some users (residing in Japan, and the primary instance being located in Amsterdam), a query could take ~200ms (median). If multiple queries are performed for each request, that could mean 1 second or more per API call - not so great if that's the case for multiple seconds after each write. I think this would eventually lead to putting more code in stored procedures, begging the question: why not use a distributed DB like Fauna in the first place?

Alternatively, the replication problem could be accounted for in the app itself. E.g. the SPA or the edge instance could retry reads following a write until the change from the primary instance has propagated, and up until then pretend that everything went fine. In case a write isn't replicated within 10 seconds or so, show an error to the user and let them retry the write action. This could lead to duplicate entries, but I'd estimate the chance for that to be quite low.

Re: My thoughts about Fly.io (so far) and other newish technology I'm getting into

#19

Earlier quoted context omitted.

As per dang's comment a few days back(1) > I wish more startups would achieve this, YC or not. Whenever I run across one that's trying to succeed on HN, I try to help them do so (YC or not)—why? because it makes HN better if the community finds things it loves here. Among the startups of today, I can think of only two offhand who are showing signs of maybe reaching darling status—fly.io (YC), and Tailscale (not YC).…

Interesting to consider the power the mods have here to nudge certain companies into the lime-light of influential technologists.

There's certainly power, that's at least inherent in modding a popular platform. But as a _very_ casual observer mainly lurking around, I'm satisfied with interpreting dangs stance as anything with any traction gets boosted, yc or not.

To the examples, fly.io caught my attention primarily by offering a useful free tier DB, and tailscale has my attention as a "beat this" offering for some homelab access stuff (meaning some stuff could but I at least have a benchmark). Until this post I didn't actually know one was YC and another wasn't. I'm interested in both purely because of HN posts.

Re: My thoughts about Fly.io (so far) and other newish technology I'm getting into

#20
The end of this article raises the issue of whether Fly.io’s USP, deploying app servers close to your users, is useful for run of the mill web apps. And as much as I like Fly.io and the people associated with it, I’ve wondered this myself. It just seems like serving to US customers from any major US data center is generally fast enough. And I think this might even be true for the world of HTML-over-the-wire web stuff, which Fly.io seems to investing heavily in.

No doubts there are plenty of more niche uses (if I were serving users internationally, I’d probably use Fly.io), but the use case just doesn’t seem as broad as the Heroku/PaaS comparisons make it out to be.

Post reply on HN