Sitecore XM Cloud learnings

Sitecore XM Cloud is gaining popularity with each passing day. As I begin learning Sitecore XM Cloud, I want to share some of my insights that may be useful for anyone just starting. This is a completely different approach to development as compared to the traditional Sitecore way and it could be intimidating, let's see how we could make this transition smoother:

Embrace the new changes: This has to be the first point, especially for those who have worked on multiple Sitecore projects for many years. Developing on XM Cloud projects is very different from the traditional way of Sitecore development with either Sitecore MVC or Sitecore SXA. There are no Content Delivery servers, no Sitecore customizations, and development mostly uses Frontend technologies. Once we accept this change, the way of working becomes easier.
Using the Starter kit from Sitecore: The starter repository from Sitecore: https://github.com/sitecorelabs/xmcloud-foundation-head could be treated as the starting point for any development with Sitecore XM Cloud. This is the recommendation from Sitecore. Sitecore community members and developers from Sitecore have contributed to making this repository the de facto starter kit with many optimizations and useful stuff needed for development.
Use Next.js for the head: The website, or the head, of the Sitecore XM Cloud project could be built using any frontend technology, be it Angular, Vue, or even Astro (https://exdst.com/posts/20231002-sitecore-astro from Sitecore MVP Anton Tishchenko). We could even use .Net core for this purpose, but Next.js is currently the best option. Next.js offers out-of-the-box features such as Server Side Rendering (SSR), Static Site Generation (SSG), Incremental Static Regeneration (ISR), and image optimization, making it a suitable choice for building robust applications.
Prefer Static Site Generation (SSG) when possible: Static Site Generation is a concept where the site is pre-rendered at build time so that when a user visits a page, that page is loaded from the cache instead of being assembled at the time. Server Side Rendering, on the other hand, means when a user requests a page, each component configured on the page is built on the fly and the page is assembled by combining these components. By definition itself, it is clear that SSG will be faster than SSR any day. As most sites will have most pages as static pages, it makes sense to go with SSG. But again there might be pages that require rendering at runtime. So it's important to gauge what's the best option and accordingly decide. The most suitable option can be to go for the best of both worlds, a hybrid approach, where SSG will be used for static pages and dynamic pages like login pages could be rendered server side.
Balance your approach to rendering strategies: This is slightly contradictory to the above point but if you have a site with thousands of pages, there's a high chance that a lot of pages won't ever be visited or maybe visited just once or twice. In this scenario, it makes a lot of sense to pre-render only those pages that will be visited more often, for example, the home page or contact us page. Using this trick, we can reduce the build time, (pre-rendering pages at build time also takes up time) while also decreasing the cache size.
Using Sitecore Pages and Explorer more: What's the point of using the shiny new product of Sitecore, a.k.a XM Cloud, and still sticking to the old tools? Sitecore Pages and Sitecore Explorer are unique to XM Cloud and offer a more intuitive, fast, and user-friendly way of creating and managing content in Sitecore. Pages is also way faster than Experience Editor. So embracing these two features is the way forward.
Getting familiar with Items as Resources (IAR): Items as Resources is a feature from Sitecore, released with Sitcore 10.1 (so available for both XM/XP and XM Cloud), where the default Sitecore items are stored as files on the disk in the Protobuf format instead of the database. More about IAR here: https://konabos.com/blog/generating-your-own-custom-iar-files-of-your-sitecore-items. While IAR is optional for XM/XP, it is the only way to deploy content to our XM Cloud instance as the Sitecore package module does not work.
Following the guides from Sitecore: Sitecore Accelerate Cookbook has many "recipes" from Project Planning to Securing the Head application which help execute the XM Cloud Project properly. Sitecore Migration Advisor akin to its name is a tool from Sitecore to help decide the way forward when migrating a platform to XM Cloud and other composable projects. These two resources are constantly evolving with updates and more helpful content. So, it's always better to keep track of these two websites. Also, joining the #xm-cloud Sitecore slack channel will be mighty useful too.
Keeping track of the new changes through changelog: Sitecore XM Cloud is a SaaS product and Sitecore keeps improving it either by adding new features or ironing out issues on a daily basis. For example, earlier Github was the only supported repository provider whereas now a new project could be created with Azure DevOps too. Then there are daily updates made to the newly launched XM Cloud Forms. All these changes could be overwhelming if logging into the portal after a while. Sitecore understood this and thereby have created a Changelog page where they list and explain all the changes made post the last release.
Getting Certified: While this is an optional step, in my opinion, it is good to get certified in Sitecore XM Cloud. It's not only a good test of the current understanding but the preparation for it makes you learn and understand the product a little better. Reading the documentation, going through the courses at Sitecore Learning, and other sources as part of the preparation for the exam will help give a better picture of the workings of Sitecore XM Cloud. The exam itself is a nice challenge to surpass.