Live data from Hacker News

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

blog.hartleybrody.com

41–50 of 111 posts

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

#41
post #33
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?

fly.io is a solution but I don't know what the problem is. I can think of it like more dynamic CDN that can have more compute capacity (deploy whatever backed by SQLite/Postgres) to serve customers right way far more instantly. Most applications and bigger chunk of them, are transactional and enterprise software is all about consistency and accuracy. Nevertheless, I think its a great engineering fiat in and of itself…

The usecase I had for my startup (a few years ago, before fly.io) was "I have an Elixir/Phoenix application - stuff working in the background plus web frontend". I would like to host it with as little thinking about individual servers, load balancers etc. I went with GAE at the time and it was fine.

Fly.io seems like a much more streamlined version of the same thing, with the addition of "global load balancing" stuff on top, if I got to the point of caring about international customers.

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

#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 LiveView JS). Then when something changes on the server, some new HTML generated and then the parts that have changed are sent down the websocket to the client to insert into the page. LiveView is part of Phoenix, leverages Elixir's concurrency, is very performant and a joy to use.

HTMX is a way of getting similar functionality but for a conventional server rendered framework like Django which doesn't have any of this stuff built in. It would be challenging to build it in anyway because the concurrency isn't as powerful. Simplistically, Phoenix exists because Chris McCord was trying to do a LiveView equivalent in Ruby, had issues, went on a search discovered Elixir.

So either use:

Elixir + Phoenix + Phoenix LiveView

Or:

Python + Django + HTMX (Python and Django can be substituted for other frameworks like Rails)

In both cases, Alpine can then be useful to sprinkle in some clientside only UI features.

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

#43

I think some things need to be built out some more, like their postgres and adding more storage after creation, but in general it's really enjoyable to use. The pricing seems fair, and their blog is intersting and fun to read.

Completely agree. Their offering for running containers is great, but nobody wants to maintain a database. They should add DBaaS on their architecture with automatic backups etc.

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

#44
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?

I agree but in a wider sense as well.

There are an awful lot of programming languages and methods that receive no hype. I have wondered about this, the most likely reason

Is that the majority of the crowd at the site come from a shared sphere, and to some agree the same type of priorities.

Personally, I like to stay away from the bleeding edge technology.

That does not constitute much of a problem for a lot of companies.

The annoying part is that recruiters often cram all sorts of technology into requirements for a CV and a job, even if the client has no need for those things, at least not yet.

There are millions or at least 100,000 of "enterprise" software projects out there.

I do admit it is not as sexy as the latest and greatest and start ups but it is a field where there are a whole lot of devs working in.

They do perhaps not spend as much time on HN, or they are quiet

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

#45
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).…

HN: one of the last remaining Great Good Places of the Internet, a lone tavern in an iconic gateway town to the now not-so-wild west.

Beyond the western borders of this little town, the tech gold rush has both expanded to epic proportions, affecting all the economies in the world, and also gone through enough booms and busts that the phrase "gold rush" seems somehow off.

As more and more young'uns join and jaded veterans return to throng the tavern alike, it often seems to be on the brink of either exploding with the largest gun fight in history, or jumping the shark.

And yet, against all odds, it retains its original magnetism - drawing throngs that grow in number and diversity while seers like [https://news.ycombinator.com/user?id=patio11](https://news.y... and [https://news.ycombinator.com/threads?id=tptacek](https://new... continue to return - dispensing worldly wisdom worth its weight in gold from corner tables.

The secret is the man at the corner of the bar @dang, always around with a friendly smile and a towel on his shoulder. The only sheriff in the west who still doubles as the friendly bartender: always polite, always willing to break up a fight with kind words and clean up messes himself.

Yes a cold-hard look from him is all it takes to get most outlaws to back down, yes, his Colt-45 "moderator" edition is feared by all men, but the real secret to his success: his earnest passion (some call it an obsession) for the seemingly sisyphean task of sustaining good conflict - letting it simmer but keeping it all times below the boiling point based on "the code":

"Conflict is essential to human life, whether between different aspects of oneself, between oneself and the environment, between different individuals or between different groups. It follows that the aim of healthy living is not the direct elimination of conflict, which is possible only by forcible suppression of one or other of its antagonistic components, but the toleration of it—the capacity to bear the tensions of doubt and of unsatisfied need and the willingness to hold judgement in suspense until finer and finer solutions can be discovered which integrate more and more the claims of both sides. It is the psychologist's job to make possible the acceptance of such an idea so that the richness of the varieties of experience, whether within the unit of the single personality or in the wider unit of the group, can come to expression."

May the last great tavern in the West and it's friendly bartender-sheriff live long and prosper.

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

#46
Flyio does promote a pattern for avoiding the distributed write database complexity: request replay, a single main write database, and replicated read dbs.\1

When a request comes in to write on a read server that attempt a db write, the request is aborted and replayed on the main write server.

With some clever assumptions such as “get requests rarely write to the db” and “post request usually do”, much of the write traffic can skip the read vms.

They created a ruby rack middleware\2 to standardize this pattern for Ruby on Rails.

\1 https://fly.io/blog/run-ordinary-rails-apps-globally/

2\ https://github.com/superfly/fly-ruby

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

#48
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…

Not even sure Alpine is needed anymore as they have Phoenix.LiveView.JS now https://fly.io/phoenix-files/sdeb-toggling-element/

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

#49

Flyio does promote a pattern for avoiding the distributed write database complexity: request replay, a single main write database, and replicated read dbs.\1 When a request comes in to write on a read server that attempt a db write, the request is aborted and replayed on the main write server. With some clever assumptions such as “get requests rarely write to the db” and “post request usually do”, much of the write t…

>Flyio does promote a pattern for avoiding the distributed write database complexity

I think the author is talking about the complexity of dealing with read after write situations.

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

#50

Do many companies actually need databases geolocated near users? I'm working on big and small projects/companies and that has never been any concern of ours. I always imagined it to be something only the very very big players care about. And as a big player I would usually bet on a big partner like AWS, GCP, Azure. Or am I missing something?

Have your projects had customers all over the globe and have you measured the user experience for those that are furthest from your database?

If so, locality jumps up to the top of the performance bottlenecks pretty quick and there is no amount of performance optimization you can do to fix it.

Post reply on HN