Hosting Sitecore XM Cloud Next.js frontend app in AWS Amplify

Next.js's creator, Vercel, is the preferred hosting solution. However, many other hosting providers have recently begun to support hosting frontend apps and various features of Next.js. One of them is Amazon Web Service (AWS) Amplify. 

AWS Amplify, backed by robust AWS infrastructure, is a hosting service provided by Amazon Web Service. You can host the frontend application like Next.js app or you can do full stack development using their Amplify Studio. AWS Amplify supports many features of Next.js but it lacks support on Edge API Routes (Edge middleware is not supported), On-Demand Incremental Static Regeneration (ISR), Internationalized (i18n) automatic locale detection, Next.js streaming, Running middleware on static assets and optimized images. You can refer this page for any updates on the Next.js feature support. 

To use AWS Amplify as the hosting provider, you can either use your existing subscription or sign up for trial AWS account which gives free access to some of their service for 12 months. 

Hosting XM Cloud Foundation Head

1. An XM Cloud project has been setup and Foundation template repository is cloned in your source control. 
2. Sign in to the AWS Management Console and open the Amplify console. 
   
   
   
   
3. In the AWS Amplify home page, click Get Started if you are using it for the first time.  
   
   
   
4. Click Get Started in Amplify Hosting. 
   
   
   
   
   
   
5. Select the source code location. In my case, it is GitHub. You will have to authorize Amplify to read/write your repository.  
   
   
   
   
   
   
6. Once the permission is set, you can choose the repository, branch and also check Connecting a monorepo and set the path as srx/sxastarter as the Next.js application is placed in that folder. 
   
   
   
   
   
   
7. When you click Next, you will see the build settings. You can see the build commands, app root folder and the artifacts base directory as well. 
   
   
   
   
   
   
8. Set the Sitecore related environment variables. You can get the SITECORE_EDGE_CONTEXT_ID from XM Cloud Deploy App --> Environment --> Details (Context ID (Live)).
   
   
   

   
   
   
9. Review the changes and click "Save and Deploy"
   
   
   
   
   
   
10. It will provision the environment, build and deploy it. You will get the AWS Amplify domain name at the end. https://*.amplifyapp.com/
    
    
    
    
    
    
    
    
    
    
    
    
11. When browsing the site https://main.d30qedhkgseqw4.amplifyapp.com/, you can see the content but it will be missing the styles. When checking the network tab, you can see the domain name for the static files as http://localhost:3000. 
    
    
    
    
    
12. You can go ahead and add an environment variable called PUBLIC_URL and add the newly generated amplifyapp.com URL including protocol. 
    
    
    
    
    
13. Now, your site will load perfectly with all the styles. https://main.d30qedhkgseqw4.amplifyapp.com/ 
    
    
    
    
    

PUBLIC_URL Environment Variable

The URLs which are generated for the static files depends on the domain name set by the hosting provider or the PUBLIC_URL Environment variable. PUBLIC_URL environment variable has higher precedence than any other environment variable. If it is not set, then it fall back to the hosting provider environment variable. 

Hosting providers like Vercel and Netlify provide the unique deployment URL in the system defined Environment variable by default. 

Vercel: VERCEL_URL.

Netlify: DEPLOY_URL

For AWS Amplify, as of now, the feature is not available and an issue is open in GitHub. The format of the Amplify URL is https://{branchName}.{AmplifyAppID}.amplifyapp.com. There are few ways to generate the URLs and I will discuss it in another post. 

To check how Sitecore Next.js SDK consume these URLs, please refer this Utils file in GitHub. 

Happy Learning!

Vercel Edge Config for Sitecore Projects

Vercel has a key-value storage option, Edge Config, for ultra-fast read to handle quick logic at the edge. 

As of now, Vercel has 4 different storage options. 

Product	KV	Postgres	Blob	Edge Config
Details	Durable Redis	Serverless SQL	Large file storage	Global, low-latency data store
Reads/Writes	Fast/ms	Fast/ms	Fast/ms	Ultra-fast (~5ms - ~15ms) /s
Use Case	Key/value and JSON data	Structured, relational data	Large, content-addressable files ("blobs")	Runtime configuration (e.g., feature flags)

Advantages

• Incredibly fast to read. Lookups return in 5 ms or less, and 99% of reads will return under 15 ms.
• Do not need to perform a deployment.
• Global, available in all regions

Use Cases

• Feature flags and A/B testing
• Enabling maintenance pages or critical redirects
• Malicious IP and User Agent blocking

Details

• Should not be used as a general-purpose key/value store. Use KV instead. 
• Cost is mostly depends on the reads as the primary use case of Edge Config is reading data at the edge. Number of writes also matters in overall pricing. 
• Important to note that the maximum store size of all the key value data is 64KB. So it is limited to only critical data which needs to be in edge for quicker read. 
• Takes 10 seconds to propagate the changes in key-value data to global regions. 
• There are costs and limits to the number of reads and writes per plan so I would recommend using it when there is a feature release, soft launching a feature to a limited group or similar tasks. Once done, it should be removed to avoid any charges. 

Edge Config SDK and API

• Edge Config connection string should be added in the environment variable with key EDGE_CONFIG. By default, SDK reads the connecting string from the environment variable. 
• An SDK to read data from Edge Config API is available. @vercel/edge-config. Install the npm package using 
• get - Reading a value
• has - Checking if a key exists
• getAll - Reading all items or in batches

Use Case 1: Redirect

In case if you have a feature update on certain section of a site and you would like to enable maintenance page and need a way to quickly remove it without any deployment, you can add the flag in the Edge config and use it to rewrite the section of the site to maintenance page using middleware. 

Refer this demo page: Use case 1. https://nextjs-edgeconfig.vercel.app/

Use Case 2: Feature Flags

In case if a feature should be enabled or disabled with a feature flag, Edge Config can help in changing the response. This should eventually removed once the feature has been permanently enabled to avoid Edge Config read hits. 

Similarly there are many uses cases where the edge data can be used. Another reminder that this edge config is not for regular key-value data as there are restrictions to the size and the number of read/write hits.