Comment by solardev | Hacker News Reader

Comment by solardev | Hacker News Reader

Parent Full thread

This sounds really interesting and is a problem we were trying to solve just this week with Vercel!

However, I am having a hard time following what it's actually doing under the hood. Aside from a single video, might you be willing to share some more details on the product page about how it works? I can't tell what it's doing, and I'm not inclined to randomly sign up for something without even having a high-level understanding...

Like when I push to Github, I understand that Vercel pulls the repo and does a yarn install and yarn build or whatever -- the same buildchain I use locally, just on their servers. Same with CircleCI.

Is that also what Reflame is doing? If so, what's it doing differently that makes it faster? If not, how does it deal with node_modules installation and are there are any caveats there, like how does it deal with resolutions, lockfiles, private repos, etc.?

Or am I completely misunderstanding...? Is this some sort of content diffing engine / hot reloader instead of a faster build pipeline? I'm not really sure I'm following, sorry :(

Just trying to understand what your product actually is and how it works :)

Happy to explain in a bit more detail how it works:

So Reflame does not use any of the exact same high-level, user-facing tools you might be using locally, like vite, webpack, npm, yarn, etc. Those tools are designed to be ran locally, and so if we wanted to run them on a server in a shared environment (e.g. in CI), we'd need to spin up a VM, install those tools, git clone the repo, before even starting to do any real work. This makes it impossible to offer the kinds of latencies Reflame is targetting.

To answer your question on what Reflame actually does: it composes a bunch of the low-level primitives behind the tools we run locally (along with a boatload of custom code), and runs them in a server, against every single module that gets sent in through our GitHub app and VSCode extension, and then deploys the result.

For npm packages specifically, instead of running npm install, it currently makes use of the lower level arborist library that npm is built on top of, to run package installations server side, then transforms, caches, and deploys the results. This was done to get an MVP out quickly and is not an ideal setup at the moment, because the caching behind it is not very granular. The first time you install a set of packages our servers have never seen before, it can take a while, but subsequent times it becomes instant.

This is really the achilles heel in our instant deployment story, and something I want to work on soon is a custom package resolution system using content addressing, similar to pnpm, that's more amenable to space-efficient, shared granular caching.

Package locking and private npm packages (private github repos are already supported, in case that's what you were referring to?) are not yet supported, but should be simple to add on top of the existing system if there is demand. Let me know if these are blockers for you!

Thanks for the explanation! I hope you add that sort of writeup on the product page itself too.

> The first time you install a set of packages our servers have never seen before, it can take a while, but subsequent times it becomes instant. This is really the achilles heel in our instant deployment story. [...]

If I'm understanding you right, you've created a new lower-level buildchain and caching mechanism. The first time I deploy an app to your servers it will take a while, but subsequent ones will be a lot faster.

If so, there's nothing wrong with that and in fact it's a great way to speed up subsequent builds (which are what really matter anyway). The first push of any given repo is just going to be a test anyway, it's the day-to-day speed that makes a big difference.

> Package locking and private npm packages (private github repos are already supported, in case that's what you were referring to?) are not yet supported, but should be simple to add on top of the existing system if there is demand. Let me know if these are blockers for you!

It totally depends on the scale of the repo/app that we're talking about. For simpler hobbyist projects those probably won't be needed, but then again for those projects Vercel is already fast enough, especially with incremental static regeneration. On bigger projects, speed would be GREAT (ours is sooooo slow, taking minutes to build), BUT basically it has to out-of-the-box be reproducible with what we have locally or any other buildchain (i.e. our repo, deployed anywhere, has to work the same, no matter how it's built and bundled). Package locking and private npm packages are not something I would ever WANT to add to a project, but sometimes they are the realities of legacy codebases that we have no choice but to keep using... this is why we couldn't switch to bun, for example, and probably Deno for that matter. And if I were starting a greenfield project using Reflame from the get-go, I'd still worry about broader ecosystem compatibility... like if Reflame goes under (god forbid), will my repo still be portable to other buildchains and hosts?

-------

Anyhow, it is still really exciting to see development in this space. Thanks for tackling a long-standing pain point for us, and hope to this evolve further! I signed up and will check it out at work :)

> If I'm understanding you right, you've created a new lower-level buildchain and caching mechanism. The first time I deploy an app to your servers it will take a while, but subsequent ones will be a lot faster.

Yep, but one important thing to note is this "slow the first time" behavior is limited to npm package installs only. Deploying a ton of source code changes at the same time is still going to be a bit slower than a single module due to sheer network and compute constraints, but the cache is fully granular here, and the processing pipeline is pretty well parallelized so should still take well under a second in most cases. Basically, the only time you should see a slow deploy in Reflame is when you update npm packages (and I hope to change this soon).

And understood re: your desire for reproducible builds, I hope to to add some level of lockfile support in the near future, will let you know through product update emails since you're already signed up! :)

> And if I were starting a greenfield project using Reflame from the get-go, I'd still worry about broader ecosystem compatibility... like if Reflame goes under (god forbid), will my repo still be portable to other buildchains and hosts?

This is a really valid, and probably super common, concern that I can totally empathize with. The best solution I've been able to think of is to make Reflame work seamlessly with existing toolchains, to the point you can have both Reflame and a local toolchain (and possibly another deployment provider that deploys using that toolchain) running on the same codebase simultaneously. This way there ends up being 0 risk to trying out Reflame, since you can run it side-by-side with your existing toolchain to compare, and can always swap back to the local toolchain + deployment provider by just removing Reflame if it doesn't work out.

We're not there yet for the vast majority of toolchains out there (there's a lot of them haha...), but we have built in some preliminary support for create-react-app, so if you have an existing create-react-app project, you can connect Reflame to the repo and it will detect you're using create-react-app, make the necessary config customizations to support it, and will start deploying it without requiring any major code or config changes afterwards. Give that a shot if that would alleviate your concerns around longevity and lock-in!

The next toolchain I'm hoping to do the same for is Vite-based React apps, but definitely open to changing that based on demand!

It would be interesting to include a precommit hook (or similar) in the developer's local npm setup, that sends you what packages are needing to be installed for what commit. That way you're aware of package changes before they even push, and can preinstall them.

So if a user has the VSCode extension installed, we'd actually install them even earlier than a commit hook could, since we'd install packages as soon as they save the config file. :)

Yeah makes sense. Simple but very effective.

Edit: actually a git postcommit hook would be good. Then you could cache deps against a commit hash, and then load them as soon as you see that hash in origin git.

Reply on news.ycombinator.com