EE support for Netlify hosting

[Antonytm]

Is your suggestion related to a problem? Please describe.

Sitecore announced a partnership with Netlify: https://www.sitecore.com/blog/news/sitecore-and-netlify-join-forces-in-new-partnership

I expected that I would be able to host the Sitecore Headless Next.js part on Netlify.
The reality is that I can host it. However, it doesn't work in EE mode.
It is not a problem for XM Cloud hosting as it comes with Rendering Host. But if you host Sitecore in some other way, you need some additional implementation to make EE work. Either, host an additional rendering host only for EE or write your own Editing Data Cache.

Describe the solution you'd like

I would like:

1. Netlify editing data cache implementation. I made PoC, it should work fine with Netlify Blobs.
2. Plugin architecture to add support for any hosting platform: Netlify, Azure, AWS, DO, etc. Not required, preferably.

See additional information for the code sample.

Is there a way to achieve this functionality with exisiting tools?

You can use a separate Rendering Host for Experience Editor mode. It will cause additional costs.

Additional information

I implemented Netilfy Editing based on Netlify Blobs. Here is the implementation:

//import { getStore } from '@netlify/blobs';
// eslint-disable-next-line @typescript-eslint/no-var-requires
const blobs = require('@netlify/blobs');
const { getStore } = blobs;
import type { Store } from '@netlify/blobs';

import { EditingDataCache } from './editing-data-cache';
import { EditingData } from './editing-data';
import { debug } from '@sitecore-jss/sitecore-jss';

/**
 * Implementation of editing cache for Netlify deployments
 * Uses Netlify Blobs to store data
 */
export class NetlifyEditingDataCache implements EditingDataCache {
  protected store: Store;

  constructor() {
    debug.editing('Netlify blobs...', process.env.NETLIFY_BLOBS_CONTEXT);
    this.store = getStore({
      name: 'editing-data',
      siteID: '...',
      token: '...',
      consistency: 'strong',
    });
  }

  set(key: string, editingData: EditingData): Promise<void> {
    debug.editing(`Putting editing data for ${key} into Blob storage ...`);
    return new Promise<void>((resolve, reject) => {
      this.store
        .set(key, JSON.stringify(editingData))
        .then(() => resolve())
        .catch((err) => reject(err));
    });
  }

  get(key: string): Promise<EditingData | undefined> {
    debug.editing(`Getting editing data for ${key} from Blob storage...`);
    return new Promise<EditingData | undefined>((resolve, reject) => {
      this.store
        .get(key)
        .then((entry) => {
          const result = JSON.parse(entry) as EditingData;
          resolve(result);
        })
        .catch((err) => reject(err))
        .finally(() => this.store.delete(key));
    });
  }
}

/** NetlifyEditingDataCache singleton */
export const netlifyEditingDataCache = new NetlifyEditingDataCache();

editing-data-service.ts
I added a switch for Netlify. But preferably have some plugin architecture there.

const getEditingDataService = () => {
  if (process.env.VERCEL) {
    return new ServerlessEditingDataService() as EditingDataService;
  }

  if (process.env.NETLIFY) {
    return new BasicEditingDataService({
      editingDataCache: netlifyEditingDataDiskCache,
    }) as EditingDataService;
  }

  return new BasicEditingDataService({
    editingDataCache: editingDataDiskCache,
  }) as EditingDataService;
};

[art-alexeyenko]

@Antonytm don't want to seem like this thread is ignored, so jumping in to comment a little. Better/simpler editing support is on our radar (including netlify and as many hosting platforms we can support) and these are all good suggestions. I'd just like to share more about it once we have something more concrete to show or share.
For now we outlined the general approach to custom caches in the second half of doc article and it's very similar to what you have: https://doc.sitecore.com/xp/en/developers/hd/21/sitecore-headless-development/use-an-out-of-process-editing-data-cache-with-vercel-deployments.html
Overall, very short rundown of every editing integration with 3rd party storages:

1. Create a custom editing data cache with get and set methods (they get or put data into storage)
2. Create an instance of BasicEditingDataService that uses the editing cache
3. Use custom editing service in src/pages/api/editing/render.ts and src/lib/page-props-factory/plugins/preview-mode.ts

Netlify Blobs storage support is in our backlog as well, and I'll update this thread more once it's properly added to a release.

[art-alexeyenko]

@Antonytm just wanted to jump in and say JSS has added a simplified editing flow for XMCloud in JSS 22.1 recently. It eliminates the need for a temporary cache for editing data - using nextjs preview data functionality instead.
We encourage everyone to make the switch to it, as it also enables using dev editing host running on your local machine, among other "under the hood" things, should hopefully come very handy.

[Antonytm]

@art-alexeyenko

Thank you! I read about it a few days ago and it sounds very promising!
No dependency on KV storage or disk cache makes a big change!
Is rendering the host completely stateless now?

And I like that there is no need for local Sitecore or playing with ngrok to run Pages using local rendering host!

---

It wasn't a big issue for XM Cloud before. XM Cloud comes with a node.js rendering host included.
I used the XM Cloud endpoint instead of patching the solution with custom cache providers. You can use the XM Cloud rendering host for Pages and Experience Editor. And you can use Netlify, AWS, Azure, ..., for Normal Mode.
Editing endpoints will not work on your hosting, but you don't care, because you have XM Cloud rendering host for it.

And for non-XM Cloud, you still need this workaround.

[art-alexeyenko]

Glad to hear you're excited about this change!

Is rendering the host completely stateless now?

It still picks the context/state data from Edge, and sites info is still saved in a temp file during build, but otherwise you don't need to manage editing state data anymore, no.

And yes, XM Cloud host could have been used strictly for editing while actual site is hosted elsewhere... but now it should also be possible to connect Pages to the JSS nextjs app hosted pretty much anywhere (AWS, Azure, Netlify etc) and have a single flow in Pages, Preview and Live. Or to Preview sites with different implemenations, if neccessary.