6 ms·

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

• lewisl9029 4y ago
  (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.
• lewisl9029 4y ago
  (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 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.