Building Mid Engine Co with react-snap
Mid Engine Co is a custom Shopify storefront. With react-snap, a post-build process launches a real headless Chrome browser, crawls public links, and saves rendered pages as static HTML. The visitor’s React app still loads afterward and can hydrate that markup. react-snap on npm · project documentation
react-snap uses Headless Chrome and follows links from the root page. Its README shows adding a postbuild script and hydrating existing markup. It also documents optional AJAX caching, which stores JSON responses for the app to reuse during startup.
Same rendering idea, different ownership
For the first working render, the effort can be similar: both run the SPA in a browser, wait for a useful public page, and produce HTML while leaving the visitor’s cart in the browser. The real difference is what happens after that first render. react-snap gives your build pipeline static HTML files; Spache operates the render, refresh, storage, and serving pipeline as a service.
| Responsibility | With react-snap, your team owns… | With Spache… |
|---|---|---|
| Rendering during a release | Add the browser crawl to the post-build step and provide the runtime/resources it needs in CI. | Automatic |
| Finding routes | The crawler follows links from its starting routes (default `/`); seed routes it cannot reach in `include`. Normal product links are usually sufficient. | Automatic |
| Keeping pages current after a Shopify update | Trigger another snapshot build and deploy when product data changes—even if application code did not. | Automatic, configurable |
| Publishing and serving rendered HTML | Publish generated route files and configure hosting so direct product URLs serve the snapshot rather than only the SPA fallback. | Automatic |
| Handling many routes | Regenerate the configured route set as part of builds; build work grows with the pages being snapshotted. | Automatic |
| Reusing startup API responses | Optionally enable react-snap AJAX caching for JSON responses. | Automatic for JSON GET; configurable for non-GET |
| Keeping the cart visitor-specific | Both approaches serve a shared public snapshot, then let the browser app load the visitor’s own cart. | Automatic |
If your catalog changes only as part of regular releases and you already own a static deployment pipeline, react-snap can be a straightforward fit. If catalog changes should refresh rendered pages without rebuilding and redeploying the storefront—or you do not want to own generated HTML publication and route serving—Spache takes on that operational loop. That all-in-one render-to-refresh-to-serve lifecycle is the distinction.