Hacker News Reader

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.

(posting some extras as comments since the original post is already way too long)

What's the pricing going to be like?

Pricing is still very much a work in progress. Feedback from early customers will play a major factor here. Here's my current thinking:

Reflame should be free to use for individuals deploying apps that live on the default *.reflame.dev subdomains. Deploying apps to custom domains will probably require a monthly fee, which will enable custom domains on all apps of the user (i.e. there won't be an additional fee for having more than 1 app with custom domains). For organizations, there will be a simple monthly fee per member, for any number of apps with custom domains in that org.

I'm planning to avoid usage-based pricing for the deployment side of Reflame if at all possible, because I don’t think it leads to a good alignment of incentives. I don't want to financially disincentivize customers from deploying as often as they want (within reasonable limits to protect against DoS), and I really don't want to be financially disincentivized to make customers' deploys faster over time. Every usage-based CI platform out there benefits financially from our builds getting slower, so have no financial incentive to build anything to make them faster. I believe usage-based pricing for CI and the diametrically opposed incentives it introduced has been a huge driver of stagnation in the industry.

I'm sorry but I honestly can't think of a single real-life use case.

I do NOT want to instantly deploy to preview on a file save, and certainly not to production. And let's not even talk about working as a team.

The only situation where I can think this is useful is if you write code locally but run your "local" version on a cloud machine. But in that case it's already covered by rsync.

What am I missing?

> Previews in Reflame are accessible at the exact same URL customers will use to access the production deployment, instead of at a different subdomain for each preview (i.e. every preview is accessed through https://reflame.app instead of at https://some-branch-of-reflamedotapp.reflame-previews.dev). Behind the scenes, this is implemented using session cookies that our CDN will check to determine which version of the app to serve.

Also this sounds like the worst idea of the century for many reasons, including security, convenience, reliability, and much more.

It's also covered from cloud dev server + local editor.

I find the tech really interesting, but I'm concerned about the business side.

I've also rebuilt a foundational level tool before and I think there are some critical problems with doing this.

---

Low level development becomes a massive bottleneck. Product development becomes really hard because you often have to touch low level stuff to do anything, which is generally not the kind of thing you can quickly iterate on.

For example, you mentioned that you only support CRA right now with support for Vite maybe coming soon. This seems really bad for adoption and it's not something you can easily change because you have to rebuild this infrastructure just to get people in the door. You might do all this work to support a build system and then realize all those users have no interest in your product.

---

Even if low level development is isolated from product development, low level development is far more time consuming and harsh since correctness matters more. I found it very difficult to balance product development with low level development.

The questions I would be asking are:

- Who is actually going to pay for this and what does their build system look like?

- Are the people who I think are going to pay beating down my door when I tell them about my product?

If there is no clear build system(s) among people who might be paying customers I would be concerned, and if they are not very excited when I tell them about the product I would be doubly concerned because it seems like supporting a build system is high effort.

---

My point of view for rebuilding something foundational is now that it needs to enable something new that is extremely valuable. You are enabling deployments on file save, but is that extremely valuable to people? I honestly don't think so. There might be another use case of this tech which is though.

An example of this is https://bun.sh. He's rebuilding a JS runtime which is a herculean task, but the goal is extremely clear and the outcome (A way faster runtime) is extremely valuable if he succeeds.

I feel like you should pick a single build system and validate the value prop with that first before adding multiple build systems, because otherwise you might be doing a lot of work for nothing.

PS: I really don't like everything on the same domain. Subdomains seem preferable to me.

Vercel is cutting this particular Gordian knot by acquiring / hiring the people who make already popular tooling. And yet, it’s a struggle to shift a substantial production app from AWS to Vercel because the change of programming model from server to serverless is a massive lift for those kinds of apps. Your runtime and build architecture are even farther away from the stuff we ship to production today. I would love to use these features - just like I’d love to deploy on Vercel with NextJS instead of ECS with Express, but it’s a wide chasm. For you more so than that combo, because you can’t provide a local dev experience.

Really appreciate you taking the time to write this super thoughtful comment! There's definitely a lot of valuable feedback/advice for me to take away here.

Re: supporting new build systems. You're totally right that it's a lot of work, with tons of potential edge cases to cover. In my ideal world people would just use the dev workflow provided by Reflame out of the box, and not bother with Vite/CRA/anything else, and everything would be easy. But in the real world I do need to meet potential customers half way and make the product as easy and low risk as possible for them to adopt, and supporting existing local dev toolchains is a crucial part of that effort.

Luckily though, I think supporting just CRA and Vite-based React apps is enough for me to capture a good 50% of the kinds of apps I'm looking to target, and I don't have plans in the short term to add support for anything else without strong demand from customers.

Re: monetization, this is definitely still the big question mark hanging over my head and keeping me awake at night. Pretty much everybody I show Reflame to seem super excited about the idea of previewing and shipping instantly, but only a very tiny fraction of those people have actually ended up giving me their credit card.

I did end up getting quite a few more new users to talk to with this launch though, so I'm looking forward to chatting with them to figure out whether they are willing to pay for instant deployments, and if so, how much, and if not, what's missing.

It's going to take a while, but I'm personally convinced that engineers having to wait minutes to deploy is a valuable problem worth solving (companies are already spending tons of money, both on SaaS and entire teams of engineers just to _keep_ it in single/low-double digit minutes in the first place, after all), and can be turned into a great business. And even if I turn out to be wrong, at the end of the day, I've been building the deployment platform of my dreams that I always wanted to use, that I can continue to use to build new products going forward even if nobody else does. I don't think I'd ever regret a single moment spent doing that (in fact I've been deeply regretting not having started on it sooner).

Re: Bun. I'm a huge fan of Jarred and Bun too! Have been following his progress for quite a while, and it's been an amazing source of learning and inspiration, even though we're solving very orthogonal problems.

Re: same domain vs subdomain previews. Appreciate the feedback! I'm not dogmatic at all on _only_ having same-domain previews. But it was important for me to have it available as an option at the start, because I think it is valuable to have in many circumstances, even if not as a default. And I at least wanted to experiment with having it as a default, because at least in theory, more production parity should offer us more confidence, still TBD on how that works out in practice. Adding subdomain based previews will certainly be on the table if I get enough similar feedback. Should actually be a lot more straightforward to implement since I already have most of the pieces in place.

(posting some extras as comments since the original post is already way too long)

How does Reflame deploy so quickly?

Some major contributors:

- Reflame never does more work than absolutely necessary for any change. Every JS/TS module deployed through Reflame is transformed and shipped as independent ES modules. Only modules that have never been seen before are transformed and deployed (taking advantage of content-addressing to simplify caching). This means Reflame isn't just fast when our projects are small. It will stay just as fast as we scale to hundreds or thousands of modules. Because it will continue to do the minimum amount of work possible for every change.

- Reflame always deploys via the most direct possible path. A typical deploy of a trivial hello world project using a traditional CI service consists of: a git commit & push from our laptops, waiting for a webhook from github, spinning up a VM or container, cloning the git repo, installing npm dependencies, transforming and bundling source code, and finally uploading the output. Each of these steps has a latency floor measured in seconds, adding up to 10s of seconds of latency to deploy even the smallest change. Compare that to a deploy with Reflame's VSCode extension: we get a file change event, we upload the file, our server transforms it and stores the output for serving. Done.

- Reflame is completely region-agnostic. We haven't yet figured out how to make light move faster in fiber optics, but we can lower the effective latency floor it imposes by having servers close to our users. Reflame lives in 3 regions today: 1 in western US, 1 in eastern US, 1 in central EU, and we'll be adding more based on customer demand. Each region is a first class citizen. Updates in each region are visible immediately to users in that region, and replicated asynchronously to all others. We also have some magic in our CDN to ensure previews get routed to the originating region so customers can collaborate using previews across the world without dealing with replication delays.

I just watched the video and I'm wondering about the fact that you don't have preview URLs but instead have a cookie based way to differentiate a preview from the real production version.

Is that really something that makes it easier? Debugging which cookies are used, deleting specific cookies or sharing a specific preview version seems to be a lot harder that way? Or am I missing something?

Having worked on a similar system in the past - it’s a trade-off.

On one hand, all your domains match across all environments/deployments and you can set a cookie and refresh to switch versions fast. Only 1 HTTPS cert and no subdomains to manage. You could invisibly do a slow rollout of deployments by slowly changing cookies. Fun stuff like that.

On the other hand, you have to have special links to set the cookies, and you end up building some kind of environment/version indicator somewhere or else you’ll lose your mind when debugging. And buckle up for when you accidentally switch versions in a different tab instead of using Incognito and screw up some debugging. Or try explaining to a confused marketing person that they’re looking at the wrong version of your landing page because a cookie they don’t know about is set wrong.

It’s all trade-offs. Personally having used both approaches I think the cookie method sounds better than it ends up being in practice. Different domains is uglier, but more clear.

Thanks for the explanation, that makes sense. I think I prefer the more explicit version over the seemingly more elegant version.

Yep, definitely a tradeoff. Really awesome to hear others have explored this in the past!

I wanted to err on the side of _enabling_ an identical-to-production development workflow, because AFAIK nothing else really offered this. So the cookies approach is what I ended up starting with, and I also built a UI to help make the difference abundantly obvious: https://reflame.app/~r/start-preview/?mode=production&varian...

Even still, subdomains are definitely less confusing though, and doesn't lead to the same kind of strange behaviors that you could only make sense of if you understood exactly how cookies work and how Reflame makes use of them (a tall order, I'm not even sure if I do 100% today). I may eventually also offer a subdomain version of these previews, for those who might be collaborating with less technical folks who are more likely to be confused by the cookie-based implementation.

Love the widget!

Assuming an app handles it correctly, unique domains-per-deployment give me the warm fuzzies when debugging. When tracking down a problem, I want there to be no doubt I'm looking at the correct version. Vercel's approach here is nice.

That's a really fair concern, in fact it's one that's bitten me quite a few times. Can't count the times I stared at a page waiting for an update, only to realize I'm looking at production, or vice versa.

This why I ended up building a small UI overlay to show the current preview and allow exiting the preview and switching between prod/dev modes (in fact I just shipped this yesterday in preparation for the launch since I knew it would make a huge difference to developer experience).

This is not in the demo because it was recorded a while ago, but take a look at this Live Preview I just created to see what it looks like: https://reflame.app/~r/start-preview/?mode=development&varia...

They are ersatz feature flags

Very impressive!

I am curious about who your intended user is. I’m just thinking about how most FE build pipelines I’ve used have a bunch of “checks” like linters, running various tests, maybe reaching out to some other services when the build passes or fails.

Is the idea with this that the developer would do these steps locally? I also might just be misunderstanding this tool.

Thanks for sharing this :)

Really appreciate the kind words!

The things in build pipelines today that you mentioned (linting, testing, events/webhooks), are all things that Reflame will eventually try to build versions of, with a focus on speed similar to what we've done with deployment, but they're definitely not there today.

This means if you want those things (and most reasonable people probably do), you do still need to install and run them locally and in whatever existing CI pipeline you're currently running them in.

The difference Reflame makes even in this context is that your deploys, both to preview and to production, are no longer blocked behind all of those frustratingly slow processes that break your flow every time you hit them:

If you want to share a work in progress with someone else, you no longer have to wait minutes for a preview to go up. It will be up the moment you made your changes.

If you have a production issue where you need to ship new code to fix, you no longer have to wait minutes for a build pipeline to run, during which your product will remain broken. It can go live as soon as you're done coding the fix.

Most importantly, having instant deploys unblocks a ton of opportunities around running tests and checks against the live production deployment, either as sanity checks that run after shipping with notifications on failure, allowing you a chance to revert (also instantly) if you broke something, in order to maximize the efficiency of the feedback loop (this is the approach I'd recommend and build first), or as a blocking safety net that can prevent broken changes from reaching customers in exchange for adding more friction to deploy every other good changeset (I'll probably build this eventually given enough demand, but would recommend that it be used very sparingly).

> Reflame will eventually try to build versions of, with a focus on speed similar to what we've done with deployment

Nice! The time I wait during builds tend to break my mental flow.

Best of luck!

This looks super cool, very impressive!

How flexible is this?

I get the impression from the video that this will work for a blessed React configuration that you support.

But if I have a legacy React app with a complicated build setup - am I screwed?

Or if I want to deploy a Vue/Vite app, would that require a huge engineering lift on your side since it’s not React?

Thank you for the kind words!

To answer your question, the system is definitely not as flexible as I'd like it to be today. The eventual goal is for Reflame to support many of the most popular development toolchains out of the box, enough to make it possible to run alongside them in the same codebase, across many frameworks.

But we have to start somewhere, and create-react-app is where we've focused our attention so far. I want to work on supporting Vite-based React apps next, and where we go from there is pretty much entirely up to community demand.

There's also no technical limitation stopping Reflame from supporting frameworks outside of React. In fact, I'm pretty sure if you stuck with production mode live previews that do full browser refreshes on every change, you could just swap out the React initialization code in the entry point with a Vue/Solid/Angular version and it should work just fine (hit me up if you end up trying this and running into blockers, happy to look into what it'd take to unblock this use case). However, there's just a ton of work that needs to go into building a first-class HMR-style, state-preserving workflow for each framework, and until then I wouldn't be comfortable with advertising first-class support for them.

Unfortunately, I don't think we'll ever be able to support a fully custom webpack config that's not based on a popular preset like create-react-app. The surface area to cover is just too gigantic there.

I think this is really your big downside. You're inadvertently competing with Vite and Webpack right now. I don't know if there's a good way around that, though, seeing as your magic is that you've written a faster bundler.

I hate to be the Hacker News commenter who is like "are you going to open source it?" But I am curious, do you think you think you could release your toolchain in a way that people can run it locally and get the same benefits that you're advertising?

(I say this as someone who currently uses esbuild and Preact. Your service looks really cool, but you would have to convert me to react-create-app if that's all you support.)

So supporting Vite-based React apps is _very_ high on my list of priorities at the moment, precisely because I don't really want to be pushing people to create-react-app just to use Reflame, since it offers a strictly inferior experience compared to Vite today. :)

I ended up having to start with create-react-app support, mostly because that's what one of my ideal early customers was using, and I wanted to make it as easy as possible for them to make the switch.

So hopefully once Vite support is ready, that could unblock your use case? (though I guess you'd also need to be willing to switch to React from Preact, which I realize is not a small ask)

Re: open source. I do actually intend to open source pieces of it. The VSCode extension is an especially great candidate since it's relatively well contained and doesn't require any specific infra to run.

Open sourcing the backend pieces probably won't happen anytime soon though, because it is very tightly coupled to very specific infrastructure (fly.io, NGS, FaunaDB, Dynamo, just to name a few), and there's a ton of moving pieces that all need to be configured to precisely to work together in order for even basic functionality to work as expected (especially in a geo-agnostic setup, like the one I'm current operating).

The support overhead for a self-deployed setup would be absolutely massive, and I'd have to think really hard about taking it on even for a lucrative contract for a large enterprise client (and the answer in the end would probably still be no). There's no way I can possibly offer that for free while making any progress on improving the service.

Thanks, I didn't know how integrated your backend was. Good luck

Great idea. I usually run a dev server on a cloud instance and rsync to it and run pnpm install. In the future I want to do this for an entire monorepo. It’s amazing the waiting tax you pay for modern ci and paas stuff for non-prod stuff.

Haha that's awesome. In fact, part of Reflame was inspired by the good old days of webdev where we could just ship changes by editing PHP files sitting on the production server.

There are obviously very good reasons why we mostly don't do that anymore, but you can't deny how great of a feedback loop that was for shipping to production. We've lost that for the longest time with this new generation of development workflows that take latencies of minutes for granted.

With Reflame I want to restore that awesome feedback loop for shipping we used to have, but this time with all the modern niceties with source control for collaboration and different preview environments to test changes in, so we can have the best of both worlds.

That's really great, I could see your smirk when you said the bottleneck was how quickly you could create the PR because the deploy was already finished and you definitely deserve to be smiling :D

Haha thanks, yep, that actually took quite a few takes to record, but couldn't help but smirk on every one. :)

> Every JS/TS module deployed through Reflame is transformed and shipped as independent ES modules

This means it's impossible to do any cross-module type checking, correct?

Depends on what you mean by cross-module type-checking! TypeScript would still be running locally because Reflame doesn't run your typechecking for you yet (though we'll be working on it!), either on your laptop or in a CI server somewhere, so everything supported by your local TypeScript version should still work the same.

What Reflame does require is turning on the `isolatedModules` compiler flag in your TypeScript config, so it can help you avoid features that would block isolated module compilation (that would similarly block things like Babel/SWC that only transpile individual modules as well).

Luckily those features are rarely used to begin with, here's the relevant bit in the example TypeScript repo with more about this: https://github.com/reflame/example-typescript/blob/main/tsco...

What I’m asking is, even if you support type checking how can it fit usefully into your compilation model, given you can’t do any cross-module analysis?

Or more pithily: a fast linker isn’t impressive if it has no error handling.

So JS has this really nice property where things really can be just deployed as independent modules, and they will just work together without any cross-module compilation or analysis needed. It's a big part of what makes Reflame's approach possible.

That said, Reflame does actually perform dependency analysis on the entire module graph, persists it, and then updates it in response to every change. We're mostly doing this for optimizations like preloading only modules reachable from the entry point to flatten the network waterfall, but we also use it to provide nice error messaging as well. Here's a quick PR showing the dependency analysis in action: https://github.com/reflame/example-typescript/pull/2

We do this by doing analysis on each module as they come in to generate metadata on what modules they depend on, so subsequent modules can build up the dependency graph using just that metadata for each module, without having to have download the full code or analyze them again.

> So JS has this really nice property where things really can be just deployed as independent modules, and they will just work together without any cross-module compilation or analysis needed.

If you're tolerant of undefined behavior when interfaces don't match expectations, every language has this property. In truth it's not really nice!

I don't know if I'm gonna end up using Reflame for my projects, but that's an impressive DX, you've really delivered there!

Thank you so much for the kind words!

Mind me asking what you're using to deploy web apps today? And what you feel Reflame is missing? Wanted to make sure I get those on my roadmap. :)

I'm on the NextJS stack, so my React app ships with my backend in Netlify. I also am re-evaluating just deploying everything to my Kubernetes cluster (currently only background jobs) depending on the project.

I might not be your average use case!

Ah got it. Yep SSR is definitely not something Reflame can support for now.

I do hope to figure something out for backend development eventually though, since I'm actually constantly feeling the pain of lacking a similar feedback loop for backend dev (Reflame is actually 90%+ backend by LOC and time spent haha...).

Yeah when you get state involved (e.g. database migrations), this is even harder. But if I was deploying backend and frontend separately I would definitely love using Reflame.

Sounds this could be quicker than local development.

Something to check: When I click the button "Let's create your first app", I get "Oh no, something went horribly wrong!"

Oh no, that's terrible! Looking into it now.

If you could open up a support chat so I can grab the user ID and get back to you when I have a fix, that would be super helpful!

Done - thank you!

Ok I think I figured this one out. I'm using the GitHub GraphQL API, and was adjusting some overly conservative pagination limits so some folks with a ton of repos can see all of theirs listed. Turns out I went a bit overboard and went past the limits GitHub had set in place.

Shipping a fix now, should be up in a couple of minutes (if only I could use Reflame to build the backend of Reflame... maybe one day...).

And it's up! Thanks for waiting!

Awesome, works now =)

> Something to check: When I click the button "Let's create your first app", I get "Oh no, something went horribly wrong!"

That's what deploying to prod every time you save in VS Code will do to your website.

Very cool, I may use this for my next React project :)

(posting some extras as comments since the original post is already way too long)

What kinds of things should I not build with Reflame?

Reflame in its current state can only deploy client-rendered React apps. So it comes with the usual caveats with client-rendered React apps around poor SEO, requiring JS to render anything at all, and offering non-ideal first visit performance. Some examples of the kinds of things you probably shouldn't use it for: marketing sites, ecommerce stores, social media sites, discussion forums, etc.

Reflame is hyper-focused on the use case of iterating as quickly as possible on product dashboard apps (like https://dashboard.brex.com) that are usually locked behind a login that can't be crawled by search engines, where most visits are repeat visits from existing users with a primed cache.

For this very specific (but still fairly common) use case, it has several rather unique value props that I've never seen offered anywhere else:

- Truly instant deploys, measured in milliseconds, regardless of how large your app becomes.

- Maximally efficient cache invalidation on updates, i.e. only modules that are updated (and the entry point html) are ever invalidated.

- Ability to preview changes as customers would see them exactly, down to the URL.

The second point is key to why apps built with Reflame will be fast in practice. Instead of cargo-culting lighthouse scores that emphasize empty-cache first visit performance which are few and far in between for this class of apps, Reflame focuses on what actually matters for this use case: maximizing cache granularity and minimizing cache invalidation in the face of frequent updates.

Every JS/TS module deployed through Reflame is transformed and shipped as independent ES modules, served using content-addressed url references, with immutable, far-future cache headers, and loaded with maximum parallelism with HTTP/2 through modulepreload links to flatten the module loading waterfall.

The content-addressed url references are translated using import maps instead of with url rewrites. This further minimizes write-amplification such that only the import map and the specific updated modules need to be updated, instead of having to update the updated modules and every dependent module recursively to the root (due to the content addressing), which would result in a potentially unbounded update latency ceiling and invalidation blast radius. We also create proxy modules for non-js resources such that they can be imported as string URLs, instead of rewriting the import statement, also in service of minimizing write-amplification.

All of this means that a user loading an app with built with Reflame a second time will only have to download the new html and specific, independent modules that have been updated since the first time, instead of a gigantic bundle of hundreds of KBs of JS every time any single module is updated.

However, the unfortunate reality today is, even with a fully flattened and parallelized module loading waterfall with HTTP/2, there is still a tangible overhead to loading 100s of independent modules at once vs a handful of large bundled modules. I'm hopeful that dynamic server-side bundling with WebBundles might be able to offer the best of both worlds someday in the future, but today this is an unavoidable tradeoff.

So, fundamentally, an app built using Reflame trades off some efficiency of the initial empty-cache visit for the best possible efficiency of subsequent primed-cache visits, even in the face of frequent updates. As I mentioned in the first paragraph, this is not a great tradeoff for many common use cases (so you shouldn't use Reflame for those use cases), but I do believe it is the ideal tradeoff we have available today for the kinds of apps I'm hoping to target with Reflame.

This is really impressive stuff! Congrats on the launch! Does this work for next.js apps?

Thanks for the kind works! Unfortunately, if you're using Next for SSR, and your use case requires SSR, the answer is going to be an unambiguous no (at least today). See https://news.ycombinator.com/item?id=33134092 for more on this.

If you're using Next as mostly a static renderer for an app that doesn't absolutely need SSR, then it could work as long as you're willing to fiddle with configuration a bit and change some code. If this becomes a popular migration path, we'll definitely look into automating the process like we've done with create-react-app.

What about SSR?

Unfortunately only client-rendered React apps are supported. So if your use case requires SSR, Reflame is probably not a good fit. For more on this, see: https://news.ycombinator.com/item?id=33134092

Show HN: Reflame – Deploy your React web apps in milliseconds