Live data from Hacker News

The appeal of serving your web pages with a single process

utcc.utoronto.ca

51–60 of 63 posts

Re: The appeal of serving your web pages with a single process

#51
post #24

Earlier quoted context omitted.

We define worth. I mention Heroku as a great way to make web applications at various scales. Reliable, and easy to use.

Heroku was / is like a mainframe. You get provisioning, scaling, configuration, etc all sorted out for you, as long as you pay through the nose.

I kind of think Railway and Fly.io is taking that spirit forward? Although I would love if Salesforce would just sell Heroku to somebody else and take it forward.

Re: The appeal of serving your web pages with a single process

#52
post #24

Earlier quoted context omitted.

We define worth. I mention Heroku as a great way to make web applications at various scales. Reliable, and easy to use.

Heroku was / is like a mainframe. You get provisioning, scaling, configuration, etc all sorted out for you, as long as you pay through the nose.

So, it's a price issue? My confusion / out-of-the-loop is thus: I hear that Heroku has gone downhill, is no longer recommended etc, yet I've noticed no degradation personally. Works well, is stable, has all the benefits I initially liked it for.

Re: The appeal of serving your web pages with a single process

#54
post #47
post #38

Earlier quoted context omitted.

You can migrate to the heavier infra later. I am serving hundreds of concurrent users from a single Rust binary backed by Sqlite. So far it hasn't shown the slightest problems and migration can happen if the service grows an order of magnitude (or two) from here.

Migration/upgrades need to happen no matter the size of the service, so I'm not sure what you mean.

Sorry, I mean porting to more flexible infra, not DB migrations. For these I use downtime right now... it's not a big deal.

Re: The appeal of serving your web pages with a single process

#55
post #32

Earlier quoted context omitted.

> no downtime except when it restarts for updates. This sounds a little like saying "all of North America except the U.S." I don't think people are worried about random breakdowns on a single VPS, but scheduled updates are still downtime, and downtime causes revenue loss regardless of why it happened. Any time a service is important enough I ask for two servers and a load balancer specifically to handle deployments a…

> upgrade windows Ok, that explains this and the above comment. The last time I had to restart anything to apply an OS update was when I moved to a new RHEL LTS version, the lifespan of which is about 10 years. And there are many ways to do similar GNU/Linux upgrades without a restart at all. Does Windows Server really need to restart for updates like normal Windows? If so, that's hilariously crap and I'm glad I've n…

Most people have to apply patches and if they don't install kpatch, there is generally a restart required to make sure everything is using new versions.

Yes, you can restart all the services that probably slightly less downtime to full reboot on most VPS these days.

Re: The appeal of serving your web pages with a single process

#56

I was shat on multiple times by throbbing-brain architecture guys for this, but what I've done multiple times that worked in prod, was to start with a single monolith with dependency injection, and run all services in the same process. Once the compute and robustness demands mandated we should scale the thing across multiple machines, both horizontally and vertically, I would replace most DI services with proxies tha…

In what programming language did you do this? Sounds like a nice mostly future-proof architecture.

Re: The appeal of serving your web pages with a single process

#57
post #37

I do this for my personal projects. Rust. Axum. Single compiled binary. Even html/js/css is baked into it via RustEmbed. Sqlite + litestream to S2. Cloudflare in front. Works extremely well.

Do you have a link to such a complete app? Would love to take a look and learn.

Re: The appeal of serving your web pages with a single process

#58
post #24

Earlier quoted context omitted.

Heroku was / is like a mainframe. You get provisioning, scaling, configuration, etc all sorted out for you, as long as you pay through the nose.

So, it's a price issue? My confusion / out-of-the-loop is thus: I hear that Heroku has gone downhill, is no longer recommended etc, yet I've noticed no degradation personally. Works well, is stable, has all the benefits I initially liked it for.

I mean their prices have never been great, but the sadness is because they should have WON - Heroku should have been the standard for deploying and managing hosting instances and databases and stuff on any cloud.

Re: The appeal of serving your web pages with a single process

#59

I was shat on multiple times by throbbing-brain architecture guys for this, but what I've done multiple times that worked in prod, was to start with a single monolith with dependency injection, and run all services in the same process. Once the compute and robustness demands mandated we should scale the thing across multiple machines, both horizontally and vertically, I would replace most DI services with proxies tha…

In what programming language did you do this? Sounds like a nice mostly future-proof architecture.

It was C# with ASP.NET containers. Not the sexiest tech stack in existence, but it's really versatile. I kind of simplified the architecture in my post, there were like almost a dozen different 'roles', and not all of them ran off the same executable (since some roles had specialist requirements, with some running off of Windows, the others off Linux, so there was some real world messiness to account for), but the Standalone 'god' mode was there and pretty much worked well on dev machines.

Re: The appeal of serving your web pages with a single process

#60
>>>> The simple great thing about doing everything through a single process (with threads, goroutines, or whatever inside it for concurrency) is that you have all the shared state you could ever want, and that shared state makes it so easy to do so many things.

If you like the sound of this, check out Elixir/Phoenix

Post reply on HN