Live data from Hacker News

We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2

blog.railway.com

121–130 of 230 posts

Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2

#121

Earlier quoted context omitted.

2 mins for a production deploy of an app with millions of users? Seems fine to me! How fast would you expect it to be?

How does an apps user base affect its build time?

Not the op and I get your point, however...

One way to think about it might be that the site supports lots of users who use it for various things. So, everyone uses 80% of the site, but everyone also uses a different portion of the final 20%. So, if you have lots of users, you might also have lots of smaller features that a significant minority use.

I don't know, just an interesting way of thinking about it.

Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2

#122
post #80
post #36

I just tried their domains page it took 10.8MB of data and took 2s for the DOM to be ready. page actually took 17s to fully render with multiple shift changes. all to render a domain search bar similar to google home page. https://railway.com/domains

The 3.57MB background PNG is hilarious [0] [0] https://railway.com/dots-oxipng.png

I got it down to 1.03MB by just switching the png to palette encoding mode.

Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2

#124
post #94
post #89

Earlier quoted context omitted.

It means you take responsibility of maintaining the server forever, i.e. dealing with TLS certificates, SSH keys, security updates, OS/package updates, monitoring, reboots when stuck, redeploy when VPS retired, etc. Usually things work fine for a year or two and then stuff starts to get old and need attention and eat your time.

This is extremely easy with tools like dokploy tho... I use dokploy locally to manage all my VPSs + home server. Truly good stuff and I don't believe your quip at the end, it feels like poisoning the open source waters for consolidated anti democratic cloud platforms. It's way way way way easier managing a basic VPS that can be highly performant for your needs. If this was 2010, I'd agree with you but tooling and pra…

Agreed, Dokploy is great, not sure why you got downvoted for the suggestion.

Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2

#125
post #89

Earlier quoted context omitted.

Why is everyone so afraid to get a $5/mo Ubuntu/Debian VPS, install nginx and call it a day? Then you can even run multiple projects off the same server.

It means you take responsibility of maintaining the server forever, i.e. dealing with TLS certificates, SSH keys, security updates, OS/package updates, monitoring, reboots when stuck, redeploy when VPS retired, etc. Usually things work fine for a year or two and then stuff starts to get old and need attention and eat your time.

vs. trusting someone else to do all that for you, and do you then verify that it gets done properly?

Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2

#126

I migrated the landing pages for my app[1] from Nextjs to Astrojs mainly because I was paying Vercel $20 per month for serving static pages(it’s 4 times more than I pay Railway for the Postgres database for the actual app and also 4 times more than I pay Cloudflare for hosting all my apps). I used AI for migrating and it took a few days only as the existing repo was used as “instructions” and it included some upgrade…

Why is everyone so afraid to get a $5/mo Ubuntu/Debian VPS, install nginx and call it a day? Then you can even run multiple projects off the same server.

Or a homelab using Proxmox or Unraid.

Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2

#127

Earlier quoted context omitted.

2 mins for a production deploy of an app with millions of users? Seems fine to me! How fast would you expect it to be?

How does an apps user base affect its build time?

It's a proxy for complexity.

Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2

#128
post #3

It’s absolutely mind boggling to me that we have gotten to a point that building a web frontend takes longer than compiling the Linux kernel..

It's mostly because a lot of the web tooling is written in JavaScript. The build times for the "next generation" tools written in Rust/Go are dramatically faster.

Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2

#129
post #114

Earlier quoted context omitted.

Maybe you're right - I've never tried dokploy, but from documentation it sounds like mostly a deployment, monitoring and alerting tool. For me the problem has always been that once you get the alert (or something just stops working), a human needs to react to it and make things work again. In cloud services you mostly pay for them providing the human, and in self-hosting you're the human. I can see though that today'…

I must be using the wrong cloud services. Whenever a part of our app goes down someone on the team still needs to respond to it.

You might be right. I've been mostly using serverless / managed cloud services such as AWS Lambda, API Gateway, S3, DynamoDB for the past 10+ years. When I've needed to respond, it's been because I myself deployed a bad update and needed to roll it back, or a third party integration broke. The cloud platform itself has been very stable, and during the couple of bigger incidents that have happened, I've just waited for AWS to fix it and for things to start working again.

Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2

#130
post #89

Earlier quoted context omitted.

Why is everyone so afraid to get a $5/mo Ubuntu/Debian VPS, install nginx and call it a day? Then you can even run multiple projects off the same server.

It means you take responsibility of maintaining the server forever, i.e. dealing with TLS certificates, SSH keys, security updates, OS/package updates, monitoring, reboots when stuck, redeploy when VPS retired, etc. Usually things work fine for a year or two and then stuff starts to get old and need attention and eat your time.

Oh no! Issuing SSL certificates! The horror!

I really doubt that people who can’t install an ssh key should be able to practice software engineering. Sometimes, I think that software engineering should be a protected profession like other types of engineering. At least it will filter out the people who can’t keep their OS up to date.

Post reply on HN