Sitecore and Azure Static Web Apps
Disclaimer: This article is written in January 2024. Different Vendor static hosting offerings may change over time. And recommendations as well.
Azure Static Web Apps (SWA) is a Microsoft Azure technology for hosting static web applications. It supports Alpine.js, Angular, Astro, Aurelia, Backbone.js, Blazor (WASM), Ember, Flutter, Framework7, Glimmer, HTML, Hugo, Hyperapp, JavaScript, jQuery, KnockoutJS, LitElement, Mithril, Next.js (Static HTML Export), Next.js (Hybrid Rendering), Nuxt 2, Nuxt 3, Preact, React, RedwoodJS, Solid, Stencil, SvelteKit (static), SvelteKit, Three.js, TypeScript, Vue.js.
Sitecore headless website in 2024 will be 90% Next.js base. That is why we are interested in 2 Next.js options:
- Static HTML Export
- Hybrid Rendering
Static HTML Export
This naming is self-explanatory. Static HTML Export is a static HTML, JavaScript, and Stylesheets (BUT not the images) that are hosted as static content.
Hybrid Rendering
Hybrid is a more common Next.js approach. It allows the usage of more Next.js features. However, it has these limitations:
- 100Mb app size. It is too small. You can’t build a Sitecore website with 3 pages without hitting this limit. You need to use
standaloneNext.js feature, otherwise, you will not be able to deploy your website. - Deployment via the Static Web Apps(SWA) CLI doesn’t work
- Local development via the SWA CLI doesn’t work. You can start Next.js separately and then pass URL back to SWA. But that will work differently compared to SWA.
staticwebapp.config.jsonfile could not be used. Features such as custom headers and routing can be controlled using thenext.config.jsfile.- Static Web Apps provide Authentication and Authorization doesn’t work. Instead, you can use the Next.js Authentication feature.
- Incremental static regeneration (ISR) does not support caching images and on-demand revalidation.
- Next.js versions 13 and above have limited support for hybrid-rendering.
- Next.js App Router is not supported
- Node.js versions support. Only 12, 14, 16, 18 are supported.
Next.js Static HTML Export with Sitecore
If we want to use this mode together with Sitecore, we should take into account that all Next.js parts that are dynamic will not work. We will not be able to use serverless or edge functions. We will not be able to use Static Site Rendering(SSR). We will not be able to use Incremental Site Regeneration. Also, Static Site Generation is possible only if we generate all pages at once. We can’t make a build, where only part of the pages is generated and the other part on the first request.
But the main not obvious thing here, is image optimization. You need to turn off it on the Next.js side(otherwise build will fail). You need to fall back to well-known optimization on the Sitecore side using Dianoga. Or you will need to use some 3rd party solutions like next-image-export-optimizer.
Next.js Hybrid Rendering with Sitecore
Limitations of SWA Next.js Hybrid Rendering are severe. And we decided to try to host Sitecore and check how they affect Sitecore. The main dynamic part of Sitecore is editing mode. And, it was required to make a bunch of changes to make it work.
- The first change was to enable standalone mode by
output: "standalone"next.config.js file configuration. It allows build optimization to meet the 100 MB limit requirement - Disable middleware. If you rely on middleware for Next.js, it may not work properly. In our case, deployment just failed. Hopefully, we did it on an almost empty project, and there was nothing important that we relied on.
- Rewrite Sitecore JSS
EditingRenderMiddlewareConfig. Sitecore JSS Next.js Edit Mode relies on writing the editing state to disk. It is done usingsync-disk-cacheNPM packages. (Azure SWA is a black box, next conclusions are made based on assumptions from logs and experiments). It looks like SWA creates a few Azure functions at once for each SWA deployment. And these functions don’t share the same disk cache. It causes the issue that two sequential API calls may call different functions. You will get an error in Experience Editor and an error in logs that this cache key is absent. It is possible to overcome this issue by using shared storage for your editing state cache. (Azure Cache for Redis, Cosmos DB, etc. The difference will be only in the responsiveness of the Experience Editor). Or if you are lazy or do it only for an experiment, wrap API calls with retries. Once a 10 requests you will call the same Azure functions instance.
We were able to achieve Sitecore Next.js (including Experience Editor) running on Azure Static Web Apps. However, we got a strange feeling. It looks like you are hitting the edges while trying to make it work. And after managing to make it fully work, you have a fear that the next issue you face will be the last and you will not be able to overcome it.
Conclusion
If you want to use the latest Next.js features then Azure Static Web Apps hosting is not for you. Azure SWA has a lot of limitations. And it has a small speed of new features adoption. Next.js Hybrid Rendering still has a preview mark. It is not often we hear about any updates about new features to match Vercel.
Also, we don’t recommend using Next.js Hybrid Rendering for Sitecore editing capabilities. It doesn’t look reliable. The better option will be SWA Next.js Static HTML Export together with Node.js container running for Sitecore Experience Editor mode.
You can consider Azure Static Web Apps hosting for your Sitecore Next.js website if you don’t need the latest Next.js features, you don’t need complex page cache revalidation, you have a huge amount of traffic and you want to shrink hosting costs. Azure gives you more granular control over the services that you are using. And you pay based on service usage.