Deploying Sitecore Next.js application to Sitecore Managed Cloud with containers and Vercel

Introduction

Many of you have probably attended User Groups where Nick Wesselman showed how to go about working with Sitecore JSS Next.js SDK and deploying it to Vercel where Vercel was pointing to a local environment. If you didn’t, you might have seen the videos of his presentations in Sitecore YouTube channel.

If you haven’t seen either of them, here are the videos with Nick’s presentations:

·         Sitecore Headless Development with Next.js with Nick Wesselman and Thomas Desmond (https://youtu.be/3AQYkgm_10s)

·         Walkthrough: Deploying JSS Next.js apps to Vercel (https://doc.sitecore.com/xp/en/developers/hd/190/sitecore-headless-development/walkthrough--deploying-jss-next-js-apps-to-vercel.html)

You can also find more information about Next.js SDK at https://doc.sitecore.com/xp/en/developers/hd/190/sitecore-headless-development/sitecore-jss-for-next-js-differences-from-jss-for-react,-angular,-and-vue-js.html

 On one of my recent projects, I had to almost the same that Nick did in his demos, but with Sitecore instance being in Sitecore Managed Cloud with containers instead of local developer machine.

I am not going to repeat Nick’s presentations. I’ll focus on area where there are differences.

Sitecore Managed Cloud with containers

If you haven’t worked with Sitecore Managed Cloud with containers (MCC) yet, you can learn more about what it is and how to work with it on Sitecore documentation site at https://doc.sitecore.com/xp/en/developers/102/managed-cloud/introduction-to-managed-cloud.html

There are a couple of things to keep in mind when you are deciding whether MCC is right for your project or not. Sitecore MCC doesn’t support multiple regions as Sitecore Support informed us. Also, you won’t be able to add your own repository to DevOps along side the application and infrastructure Sitecore MCC repositories. This is also according to Sitecore support.

If you are working with a solution that doesn’t require multiple regions on won’t need a CD role and will only be served from Vercel, MCC might be suitable for that kind of solution. Vercel is multiregional and if you are using APIs like Edge, you most likely won’t need CD.

Application repository changes

As indicated in Sitecore MCC documentation, you’ll have to build your own Docker images. For this project I added JSS and SPE roles to my CM, CD and MsSql-Init images. The new images were uploaded to Azure Sitecore MCC container registry. The references to the new CM and CD images were updated in application repository /config/docker-images/docker-images.json. I added a new line for my custom mssql-init job. The name had to be added without dashes or spaces for configurations to work properly.

In addition to that my custom mssql-init job had to be added to the templates folder where I referenced the image from the docker-images.json above.

The steps for the new job had to be added to the init.yaml file as well.

The details you can find in Sitecore documentation at https://doc.sitecore.com/xp/en/developers/102/managed-cloud/walkthrough--adding-the-jss-module.html

There was one issue with Sitecore Layout Service access that we ran into. When Vercel tried to connect to Azure MCC instance passing the sc_apikey header, the header was being stripped out. It turned out that it is related to ingress controller. You can find more information on this default functionality at https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/?highlight=disappearing%20http%20headers#missing-disappearing-http-headers

Sitecore Support team provided a fix for this issues that we were able to implement. In this fix there was a new custom-nginx folder with the folder structure you see below. 

In addition to that a reference to custom-nginx needed to be added to the root main.yaml file.

 

After all the configurations are done, checked in into a new branch, and the branch is merged into the master branch, the application pipeline starts building and deploying to Azure. After deployment is successfully completed, you should see SPE and JSS modules in your CM.

Vercel configurations

Nick is going into a lot of details on how to configure a deployment in Vercel, so I am not going to cover that. I would like to mention just the areas that I had to change.

For more information regarding configurations that you need to have in Vercel deployments, see https://doc.sitecore.com/xp/en/developers/hd/190/sitecore-headless-development/walkthrough--deploying-jss-next-js-apps-to-vercel.html

Sitecore Experience Editor configurations

I used the same Sitecore Containers for Next.js template for this project as Nick did, so the file structure I am referring to is the same as in Nick’s demos.

In a Sitecore patch file that contains the JavaScript Services definition I updated the configuration for serverSideRenderingEngineEndpointUrl and serverSideRenderingEngineApplicationUrl attributes. Both of these variables were added to Azure Key Vault and are being used in ASK pod creation.

In Azure MCC the values for both RENDERING_HOST_URI and RENDERING_HOST_PUBLIC_URI are the same while in local environment the value for the first attribute points to your local rendering host container - https://rendering:3000.

 Preview mode

When you configure a deployment in Vercel, you supply the reference to your solution repository. It can be GitHub, GitLab or other source control systems that Vercel supports. When you check in a change into any branch in your repository, a new Vercel deployment starts. The master (or a different branch that you configure as the main branch) gets deployed to Production environment. All other branch deployments produce a Preview Vercel url where you can validate your work before it gets deployed to production.

Conclusion

Next.js with Vercel has been a very promising and popular architectural approach. The solution becomes even easier to configure and maintain with introduction of Sitecore Managed Cloud with containers.