Hello friends! A few weekends ago, I participated in the Sitecore Hackathon 2025—a 24-hour event that starts at 7 PM on Friday and ends at 8 PM EST on Saturday. But wait, that's 25 hours? Well, the first hour is dedicated to brainstorming an idea based on the provided category. This year, our team—team DED (named by combining the first letters of team members Dylan, Dan Solovay, and Erica Stockwell-Alpert)—used that entire hour to develop our concept. The category gave us freedom to build anything we wanted. While we initially considered creating a CLI for IAR files, we ultimately settled on an idea that energized the whole team. I was particularly excited because it aligned with my work on the Sitecore Assistant and would expand the tool in a new direction (which I'll discuss later when covering the Hackathon outcomes).

## The Idea

We decided to build something similar to the Sitecore Assistant tool, expanding upon a tool that Erica had developed for XM/XP. However, since Sitecore XM Cloud's landscape has changed and traditional package installation methods no longer work, we created an XM Cloud replacement—a separate Next.js application that integrates with both the XM Cloud Edge/Delivery APIs and the Authoring/Management APIs. The app's architecture allowed us to deploy it to Vercel (check it out here: [https://sitecore-content-export.vercel.app](https://sitecore-content-export.vercel.app/)). Taking inspiration from the Sitecore Assistant, we added a Copilot feature that pulls content from the Delivery/Edge API. Though we had to rush the interface, the potential is enormous. I particularly loved our tech stack choice—Next.js, Tailwind, and ShadCN for the UI. Even with my limited UI experience, I breezed through the interface development using Vibe code, and the results were fantastic.

## My Overall Thoughts

This was definitely one of the best Hackathons I've ever experienced. With AI by my side, I never felt stuck—I could use it to overcome any obstacle. I primarily relied on GitHub Copilot, which proved invaluable for 90% of situations. Rather than getting bogged down wondering how to build something, I could simply ask how to refactor the code to achieve specific goals, and I was off to the races.

That said, Copilot Edits has its drawbacks—it frequently overwrote my changes, causing me to lose code, and its formatting leaves much to be desired. Still, Copilot's chat feature has been transformative for my productivity. When Copilot occasionally struggled, I turned to Claude 3.7, which was phenomenal for coding modifications. I could even attach photos and draw on them to illustrate the issues I was facing, and somehow it understood and resolved them perfectly.

AI particularly excels at UI work, and the latest models are clearly improving rapidly in this area. While I'm uncertain about when it might replace humans—I encountered some challenges with AI in another post-hackathon project—it proved to be an invaluable tool for enhancing the UI. I successfully created a stunning UI for the Chat app, which I'll definitely incorporate into future applications.

![](https://cdn.sanity.io/images/lanua4su/production/c2668dbb966d589b04d7c93b1f1ac594926354db-1285x838.png)

## The Outcome

I was impressed with what we were able to create. I plan to make several improvements to both the Sitecore Assistant and this new application. For the app we built during the hackathon, I'll first enhance the API Instance configurator. The initial version was confusing, so I'm rebuilding it to be more flexible and allow for future Sitecore integrations, such as Personalize. While helping Erica enhance the Instance configuration, I also plan to bring more features into the original tool. I learned an important distinction between Session Storage and Local Storage—Session Storage only persists during the current browsing session, while Local Storage remains across multiple browsing sessions indefinitely. This storage functionality is one of the tool's features I'm most proud of, as it allows anyone to configure instances and start using them with their environments. Of course, if we pursue adding this to the Marketplace, we'll need to do additional development work to meet their requirements.

I plan to rename the Sitecore Assistant to Sitecore Copilot and transform it into a multi-agent tool that handles content, personalization, and future capabilities. I'll incorporate the UI we built for the Hackathon submission into Sitecore Copilot and develop advanced chat interfaces that integrate with other Sitecore systems. Additionally, I hope to bring the content-related copilot enhancements back into the Hackathon submission.

I'll share more details about these enhancements to the Sitecore Assistant (Copilot) in my next few posts. Overall, it was an excellent Hackathon experience—our team collaborated seamlessly, and I'm already excited for the next one.


Sitecore Hackathon 2025: Team DED - My Thoughts and Review My Contributions

Hello everyone! I'm back in 2025 after a three-month hiatus—I've been busy moving to a new home, which hasn't left much free time. I've also started a new position at Velir, where I'm working extensively with XM Cloud implementations. While I had some experience before, I'm now diving much deeper into the technical details, and I'll be sharing these insights with you. Today, I'll explain how I solved a particular XM Cloud challenge.

Recently, I created a complex component in Sitecore XM Cloud using Integrated GraphQL ([Integrated GraphQL in JSS apps | Sitecore Documentation](https://doc.sitecore.com/xmc/en/developers/jss/latest/jss-xmc/integrated-graphql-in-jss-apps.html)). While building this component, I encountered a challenge—the component required a complex GraphQL query with multiple nested levels, which triggered the following error:

```jsx
{
  "errors": [
    {
      "message": "Query is too nested to execute. Depth is 17 levels, maximum allowed on this endpoint is 15.",
      "extensions": {
        "code": "INVALID_OPERATION"
      }
    }
  ]
}
```

After encountering this issue, I needed to determine the best solution. While searching online, I found that most articles recommended patching the XM Cloud configuration—which is strongly discouraged in Sitecore XM Cloud. This reminded me of my early days learning Sitecore: just because someone writes an article about a solution doesn't mean it's the right approach. Though patching a configuration isn't quite as problematic as creating custom .NET extensions, it was evident this wasn't the optimal path forward. Here's an example of the patch configuration method that I decided against:

```jsx
<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/"
  xmlns:set="http://www.sitecore.net/xmlconfig/set/"
  xmlns:role="http://www.sitecore.net/xmlconfig/role/"
  xmlns:env="http://www.sitecore.net/xmlconfig/env/">
  <sitecore>
    <api>
      <GraphQL>
        <defaults>
          <security>
            <publicService type="Sitecore.Services.GraphQL.Hosting.Security.GraphQLSecurity, Sitecore.Services.GraphQL">
              <complexityConfiguration type="GraphQL.Validation.Complexity.ComplexityConfiguration, GraphQL">
                <maxDepth>15</maxDepth>
                <maxComplexity>2000</maxComplexity>
                <fieldImpact>2</fieldImpact>
              </complexityConfiguration>
            </publicService>
          </security>
        </defaults>
      </GraphQL>
    </api>
  </sitecore>
</configuration>
```

This experience inspired me to write this blog post once I found a solution. It's worth noting that I tried different GraphQL approaches, switching from a datasource query to a search query. However, the query depth limit remained the same regardless of the GraphQL type used.

## Splitting up the Query

As the title suggests, I needed to split up the query to retrieve all necessary data without triggering the error mentioned above. Since these pages are statically generated, making multiple requests is a reasonable approach—it's far less problematic than it would be if we were making these requests on every page load.

While researching this topic, I identified key requirements for the correct approach. The component needed to render on initial page load rather than loading dynamically afterward. While there are cases where you might want an initial interface followed by asynchronous data fetching from Edge GraphQL, I wanted everything to load seamlessly at once. Though both options I'll discuss would satisfy this requirement, I also had to consider how each approach would affect the content editing experience within pages. Before diving into these two approaches, I should mention the Sitecore XM Cloud Accelerate documentation, which thoroughly explains the benefits and drawbacks of the different data fetching methods: [Getting Component Specific Data | Accelerate Cookbook for XM Cloud | Sitecore Developer Portal](https://developers.sitecore.com/learn/accelerate/xm-cloud/implementation/external-data-integration/getting-component-specific-data#related-recipes).

### Using a Placeholder

The first approach is separating the inner components and their data into Placeholders. The issue, as I alluded to above, is that this complicates Page Builder. A component that could be handled as a single unit would now require content authors to drop one component and then immediately drop a second component. This isn't ideal due to that extra complexity. There has to be a better way.

However, this placeholder method can make sense in certain cases, particularly when data is difficult to manage elsewhere and you want to give content authors flexibility in building components with multiple nested elements. For cases where the data structure remains constant, you may want to consider using the Linked List approach, which I'll discuss in a future post.

### Using Component Level Data Fetching

Let's explore the better approach: component-level data fetching. This method allows your component to fetch any additional data needed for your website. Whether it's third-party data or, in this case, breaking down a complex GraphQL query into manageable pieces. I chose to remove all Integrated GraphQL (though I could have simply simplified it to include only what I needed) since working without it seemed more straightforward. I implemented `GetStaticProps` at the component level. For those familiar with traditional Next.js development, this might seem unusual—typically, you'd pass complex objects at the page level and drill props down to their respective components. However, JSS enables these additional requests at the component level, which both simplifies data access and eliminates the need for extensive prop drilling from the page component.

<aside>
⛔

**Important note:** Since `getStaticProps` and `getServerSideProps` are bundled on the client side, be cautious not to include any sensitive information in these functions.

</aside>

Let's take a closer look at the code for our component. The original complex component wired up with XM Cloud handles only its datasource fields, while I use those same fields to construct `additionalFields`, which I hydrate from the `getStaticProps` function:

```jsx
export type HeaderFields = {
  additionalFields: {
    item: {
      megaMenuLinks: {
        targetItems: {
          ...
        }
      }
    }
  };
  fields: {
    logo: ImageField;
    fieldA: TextField;
    fieldB: TextField;
    fieldC: TextField;
    ...
  }
}

export HeaderProps = ComponentProps & PlaceholderProps & HeaderFields;

const Default = (props: HeaderProps): JSX.Element => {
  const { fields, additionalFields} = props;
  
  ... (Rest of the Code to Render Fields)
}

export const getStaticProps: GetStaticComponentProps = async (rendering, layoutData) => {
  const graphQlClient = graphqlClientFactory();
  
  const response = await graphQlClient.request<HeaderAdditionalFields>(headerQuery, { datasource: rendering.dataSource, language: layoutData.sitecore.context.language, });
  
  return {
    externalFields: response || {},
  };
};
  
```

To complete the picture, I should mention that `headerQuery` is simply a datasource GraphQL query stored in a separate TypeScript file.

When you find recommendations to customize the patch config, avoid that approach. Instead, re-engineer your component and break up your request into smaller, manageable pieces. Patching the configuration is a slippery slope—while we might only need a few more nested levels now, future queries could require even more depth, tempting us to keep increasing the limit beyond what's appropriate. This approach also isn't future-proof: what happens if Sitecore removes the ability to customize this configuration? As XM Cloud developers, we must build solutions that will stand the test of time.

Sitecore XM Cloud

Sitecore Hackathon 2025: Team DED - My Thoughts and Review My Contributions

Sitecore XM Cloud: The Correct Way to Resolve GraphQL Too Nested to Execute Issue