Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.hartleybrody.com

Post reply on HN
Print view View original

91–100 of 111 posts

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

#91

Post by hartleybrody »

rkangel wrote: post #42

I think his stack is a little confused. He's got HTMX and Phoenix in there. If you are using Phoenix then LiveView is the obvious approach to dynamically updating a page based on server stuff. It's a similar-ish architecture to HTMX, but integrated into the framework. The page is rendered on the server as normal, then when it loads on the client a web-socket is opened to a task on the server (page includes the LiveVi…

OP here, thanks for making that distinction more clear. I had listed them all as new tech that I am starting to use, but you're correct that I wouldn't intend to use them all _together_.

The HTMX and alpine libs were intended to be sprinkled onto existing web apps (my usual python/flask stack), whereas Phoenix would be for building all new projects.

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

#92

Post by hartleybrody »

nicoburns wrote: post #31

> But despite how much I want to learn the fly.io platform – it has been a bit tricky for me wrap my head around a good use-case for this type of distributed hosting service. Worth noting that you don't have to use the distributed aspect. I have my site hosted on a single one of a fly.io's smallest instances (which one can get 3 of for free), and even like this the performance is excellent (50ms response times), and…

This is an excellent point. While their main value prop seems to be "servers closer to your users" you could also just use them as a drop-in replacement for something like heroku and just use one region to simplify the mental model, pricing and orchestration.

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

#93

Post by tlarkworthy »

bobnamob wrote: post #15
tlarkworthy wrote: post #2

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?

No cloud Run instance supports 1000 concurrent users and stays active for 15 min after no traffic, so only a small subset of users should ever hit a cold start.

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

#94

Post by simonw »

simonw wrote: post #73
simonw wrote: post #66

Earlier quoted context omitted.

There's another, more sophisticated trick that works for some databases: tracking a global transaction counter of some sort, persisting that in a cookie when a user makes a write and redirecting the user to the lead database if the replica they are talking to hasn't made it to that point yet. Chris McCord describes how Elixir does that with PostgreSQL here: https://news.ycombinator.com/item?id=31434094 Wikipedia impl…

Actually the way Wikipedia works is slightly different: they don't redirect to a lead database, they instead call this MySQL function to wait on the replica for it to catch up: SELECT WAIT_FOR_EXECUTED_GTID_SET($gtidArg, $timeout) https://github.com/wikimedia/mediawiki/blob/434c333d9b2be817... I wonder if there's a PostgreSQL equivalent of this?

Looks like someone proposed a WAIT FOR feature for PostgreSQL a couple of years ago: https://www.postgresql.org/message-id/flat/69a363498b76cd079...

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

#95

Post by tptacek »

Mo3 wrote: post #77

Fly.io, as sorry as I am to say, does not come close to the functionality Heroku offers yet. Redis instances are single-region single-replica, for example. On another note, as soon as they offer serverless functions and solid redundant Redis + SQL I'll be thinking about moving some of our production services over there for a test run.

Just so we're clear: our take right now is that if you want Redis, you should run Redis as an app. The Redis we provide "built in" to the platform is an artifact of an earlier iteration of Fly.io.

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

#96

Post by treis »

tptacek wrote: post #82
treis wrote: post #75

Earlier quoted context omitted.

This is a ton of effort to save the RTT of sending all the requests to a central server. And it all goes out the window the second you need to call an external API in the processing of your requests. And to get what benefit there may be you need to, more or less, pay for a server in every big city. IMHO, outside of gaming there's no real need for what fly.io does. For something like this to be useful I think the code…

If you're getting 80ms response times for user requests, consistently, then it doesn't change much.

80ms is the network latency not response times. That's the number fly.io can change and realistic best case is going from 10-15ish ms staying within a city vs 80ms going to a server on the other side of the US.

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

#97

Post by tptacek »

treis wrote: post #96
tptacek wrote: post #82

Earlier quoted context omitted.

If you're getting 80ms response times for user requests, consistently, then it doesn't change much.

80ms is the network latency not response times. That's the number fly.io can change and realistic best case is going from 10-15ish ms staying within a city vs 80ms going to a server on the other side of the US.

I'm just saying, if your application is already fast for your users --- anything in the ballpark of 80ms is fast enough --- geographically distributing it might not make a big difference. I'm agreeing with the comment (or at least, its subtext).

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

#98

Post by randito »

simonw wrote: post #66
simonw wrote: post #61

> It seems like this would add a whole new class of bugs, like “I just submitted a form to change a setting and when the page reloaded, it still showed my previous value in the form” – since the write hadn’t propagated to the local read replica yet. There's a very solid solution to this that isn't as widely known as it should be. Read after write consistency is extremely important. If a user makes an edit to their co…

There's another, more sophisticated trick that works for some databases: tracking a global transaction counter of some sort, persisting that in a cookie when a user makes a write and redirecting the user to the lead database if the replica they are talking to hasn't made it to that point yet. Chris McCord describes how Elixir does that with PostgreSQL here: https://news.ycombinator.com/item?id=31434094 Wikipedia impl…

(Disclaimer: Not an expert.. just sharing something I read somewhere)

I think FoundationDB does something really interesting with this problem. When you make changes, you do it via a transaction. But all the client reads are using the previous version, until the transaction changes have propagated across the nodes, then the new value is returned.

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

#99

Post by dang »

moritonal wrote: post #13
ghoomketu wrote: post #6

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.

We don't do that - it's important that the interest in these things be community-organic. We're interested in tracking what the community is interested in, and we never try to gin up interest in anything (ok, except APL). It wouldn't work anyhow; that's not how a technology becomes influential, at least not in this community.

I put the OP in the second-chance pool (https://news.ycombinator.com/pool, explained at https://news.ycombinator.com/item?id=26998308), but that was according to the usual 5-second standard of "I think the community might like this one". I didn't look closely enough to tell whether the article was positive or negative towards Fly.io, nor is it our job to care about that. What we care about is intellectual curiosity (see https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...).

There's one big exception to the above, which is the official Launch HN posts we do for YC startups - those are described at https://news.ycombinator.com/newsfaq.html - they get official placement on HN's front page, as explained there. But they're always clearly indicated by "Launch HN".

I personally find it super interesting which startups end up achieving HN darling status - the classic examples of this are Stripe and Cloudflare - I'd add Hashicorp - and it would be fun to make a list of others. But from a moderation point of view it doesn't matter whether such a startup is YC-funded or not and we try to be as neutral as we can that way. I'm not saying we don't have unconscious biases or conflicts of interest (such a claim is impossible!) but we're strict about how we approach this consciously, and we have quite a lot of practice with that.

It's a natural concern of course, and I'm always happy to answer questions.

p.s. Incidentally, there's at least one HN user who has made a long series of accounts angrily accusing us of secretly favoring a non-YC startup (the one mentioned in the GP comment). We haven't, but because that startup is well-loved by the community, it's easy to see how it could come across that way, with threads appearing frequently and filling up quickly with comments.

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

#100

Post by dang »

CJefferson wrote: post #14
csmpltn wrote: 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 w…

If there's significant, good, on-topic technical content that isn't getting posted to HN, for god's sake someone please let me know.

If it's getting posted to HN but not getting traction, for god's sake someone please let me know that too.

Literally the only thing we're trying to do is have HN be as interesting as possible. Missing out on the best content is disastrous for that goal—sort of like missing out on the best startups is disastrous for an investor.

Post reply on HN