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. :)
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.
> 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 :)