Live data from Hacker News

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

blog.railway.com

171–180 of 230 posts

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

#171

Earlier quoted context omitted.

Yes, good times! With http2/3 they don't really matter anymore though, you get similar benefits from request pipelining.

Spriting is actually harmful for performance except in specific HTTP-1 scenarios.

Doesn't McMaster Carr still use sprites? Is that like the one optimization they managed to get wrong?

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

#172
post #168

Earlier quoted context omitted.

This is all trivial, and can and should be automated. Furthermore, all of your arguments can easily be applied to NodeJS version deprecations, React realizing they shipped a massive CVE, etc. I will die on this hill: parent is correct - the ability to manage a Linux server should be a requirement to work in the industry, even if it has fuck-all to do with your job. It proves some basic level of competence and knowled…

I keep reading posts like this, but the people who say this never actually seem to enlighten the rest of us troglodytes by, say, writing a comprehensive, all inclusive, guide to doing this. If it's so easy, surely it's no big undertaking to explain how one self hosts a fully secured server. No shortcuts, no "just use the usual setup" (we don't know what it is!), no skipped or missed bits. Debian to Caddy to Postgres,…

The parent I responded to was discussing issuing certs, configuring SSH keys, and updating an OS. Those are all in fact trivial and easily automated.

What you have stated requires more knowledge (especially Postgres). You’re not going to get it from a blog post, and will need to read actual source docs and man pages.

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

#173
post #169

Earlier quoted context omitted.

This is all trivial, and can and should be automated. Furthermore, all of your arguments can easily be applied to NodeJS version deprecations, React realizing they shipped a massive CVE, etc. I will die on this hill: parent is correct - the ability to manage a Linux server should be a requirement to work in the industry, even if it has fuck-all to do with your job. It proves some basic level of competence and knowled…

I'm curious about this trivial automation. Let's say the new OS LTS version no longer includes nginx, because it was replaced by a new product with different config. How does the automation figure out what the new server package is and migrate your old Nginx config to the new format? I agree with Node.js version deprecations being a huge problem and personally advocate for an evergreen WebAssembly platform for runnin…

If an LTS of an OS replaced nginx with something else, a. it would be announced with great fanfare months in advance b. if you don’t want to do that, add apt / yum / zypper install nginx to your Ansible task, or whatever you’re using.

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

#174
post #132

Earlier quoted context omitted.

Time is a precious (and really expensive for SWEs) resource, why should one spend it on updating certs and instances?

You don’t, you automate it. This has been a solved problem for literally years.

Now you have to maintain the automation. There is nothing wrong with that. There is nothing wrong with building your own server. There is nothing wrong with colocation. There is nothing wrong with driving to the colo to investigate an outage. There is nothing wrong with licensing arm and having TSMC fab your chip. There is nothing wrong with choosing which level of abstraction you prefer!

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

#175
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.

As someone who runs a such a VPS this is all a non-issue. Running HTTP service is so trivial that once I set it up I don’t even spend an hour in a year maintaining it. Especially with Caddy which takes care of all the certs for you.

And this is also bearing in mind that I complicate my setup a bit by running the different sites in docker containers with Caddy acting as a proxy.

With storage volumes for data and a few Bash scripts the whole server becomes throw-away that can be rebuilt in minutes if I really need to go there.

And for sure any difficulty and ops overhead pales in comparison to having to manage tooling and dependencies for a typical simple JS web-app. :)

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

#177
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.

Agreed. My frontend/react builds use esbuild, and rebuild fast enough that it feels like hot module reloading

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

#178
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.

This is the kind of stuff a software develop should have absolutely no problem managing. It's crazy to me that so many software developers hate the idea of maintaing a computer.

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

#179
post #106

Earlier quoted context omitted.

As in, htmx is better? I haven't used it but last I looked into it I was extremely confused as to whether it was a meme, an actual framework, or both.

HTMX is great when your web interface is just a representation of a server state. If web interface is an application backed by a remote state HTMX falls apart.

> If web interface is an application backed by a remote state

What does that mean?

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

#180

Earlier quoted context omitted.

I hadn't heard of TanStack but a quick look at their website doesn't inspire confidence tbh. I mean, just take "TanStack Pacer". It provides such things as: ``` import { Debouncer } from '@tanstack/pacer' // class const debouncer = new Debouncer(fn, options) debouncer.maybeExecute(args) // execute the debounced function debouncer.cancel() // cancel the debounced function debouncer.flush() // flush the debounced funct…

Obviously it's more than just debouncing. https://tanstack.com/pacer/latest/docs/overview

That's putting it mildly!
Post reply on HN