SUGCON India 2026 — My Key Takeaways from Two Days in Delhi

 

Hello Sitecorian Community,

SUGCON (Sitecore User Group Conference) India 2026 just wrapped up in Delhi on June 4–5, and what an incredible two days it was!

If you couldn’t make it this year, or if you attended and want a structured recap of everything that happened — this post is for you. I’m going to walk through the biggest announcements, the sessions that stood out, and what I personally think you should be paying attention to as a Sitecore practitioner right now.

Let’s dive in. 🚀

🔷 The Big Announcement: Sitecore vNext

If there was one topic that had every room buzzing at SUGCON India 2026, it was Sitecore vNext.

The next major evolution of the Sitecore Platform DXP is officially on the horizon — and here’s what makes it genuinely exciting: it’s not the kind of “upgrade” that forces you to rewrite everything overnight.

What we know about vNext so far:

• Built on a modern .NET foundation, fully aligned with Microsoft’s long-term roadmap
• Uses the Strangler Fig pattern for gradual modernization — you adopt new capabilities at your own pace, alongside your existing implementation
• No forced migrations, no massive rewrites
• AI-powered authoring experiences built in from the start
• A refreshed Content Editor and Experience Editor experience
• Support for Windows Server 2025, SQL Server 2025, Solr 10, and .NET 10

🔥 What really got the room talking: The Strangler Fig approach means organisations can introduce vNext capabilities gradually — running them alongside what they already have, and transitioning components when the time is right for them. That’s a massive shift from the traditional “big bang” upgrade model Sitecore customers have been used to.

And the bridge to get there? Sitecore 10.5.

Sitecore 10.5 is the next stepping stone and it’s already delivering AI-powered authoring capabilities as a preview of what vNext will bring at scale.

✅ Three Things You Can Start Doing Right Now

1. Build clean separation between your Sitecore implementation and custom code — this is what makes the Strangler Fig approach actually work
2. Stay current — 10.4 and 10.5 are key modernization milestones, don’t fall behind
3. Invest in automation — DevOps pipelines, CI/CD, and regression testing will be your best friends during any gradual migration

🔷 AI Is Moving From Buzzword to Engineering Discipline

This was the theme that ran through almost every technical session at SUGCON India 2026: AI has moved out of the slide deck and into the codebase.

The conversations weren’t about whether to use AI. They were about how to engineer with it properly.

Two sessions stood out here in particular.

Building AI-Powered Migration Engines with MCP

The Model Context Protocol (MCP) is enabling a genuinely new class of developer tools. Sessions at SUGCON showed teams using MCP to build migration engines that dramatically cut the time and risk of moving content and configurations across Sitecore environments.

What used to be weeks of careful manual work is being transformed into guided, AI-assisted workflows. For anyone who has managed a large content migration on a Sitecore project — you’ll understand just how significant that is.

Building Hallucination-Safe AI Assistants

This was one of the most practically useful sessions of the conference.

Building AI assistants on top of a DXP is only valuable if those assistants can be trusted. Speakers walked through architectural patterns for:

• Grounding AI responses in verified, approved content sources
• Implementing guardrails that prevent out-of-scope or incorrect responses
• Designing systems that fail gracefully — rather than confidently generating wrong answers

⚠️ Key insight from this session: The shift isn’t just about adding AI to your implementation. It’s about treating AI as an engineering discipline with proper reliability, testing, and governance built in from day one.

🔷 XM Cloud and Headless: Maturing Faster Than You Might Think

For developers in the headless space, the XM Cloud and Next.js sessions offered some of the most immediately actionable content of the two days.

The state of headless Sitecore in mid-2026 is genuinely more mature than it was even 12 months ago. Sessions covered:

• Next.js performance optimization for Sitecore-powered sites — tackling real-world bottlenecks around rendering strategies, edge caching, and ISR/SSR tradeoffs
• Composable DXP architecture patterns that are proving out at scale in production environments
• Developer experience improvements in XM Cloud — local development tooling, component scaffolding, and how teams are structuring their headless codebases for maintainability

The clearest signal from these sessions: headless isn’t the “advanced” or “optional” approach anymore. It’s becoming the default, and the ecosystem tooling around it is catching up fast.

✅ Tip: If you’re still on a traditional Sitecore rendering model and haven’t started exploring a composable path yet, now is the time to start. The XM Cloud ecosystem is ready.

🔷 The Community: Still What Makes SUGCON Special

I’d be doing a disservice to the conference if I only talked about the technology.

What makes SUGCON India genuinely different from any other enterprise tech event is the people — and the culture of openness they’ve built together. Sitecore MVPs, architects, developers, and product leaders all in the same space, sharing knowledge freely, asking hard questions, and genuinely helping each other figure things out.

This edition had a particularly meaningful moment: a heartfelt farewell to Tamas Varga, whose energy and vision have shaped the SUGCON community for years. And a warm welcome to Sebastian Winter, stepping into his new leadership role — wishing him the very best as he continues building on that momentum.

A huge shoutout to the organizing committee who made this all happen in Delhi:

Sakshi Khurana, Sean Broderick, Rob Earlam, Hardeep Bhamra, Vikas Kumar, Yamini Punyavathi Muttevi, Raman Gupta — and every volunteer and sponsor who contributed behind the scenes.

And to the sponsors — Horizontal Digital, Altudo, Arroact Technologies, BIZTECHNOSYS, Codehouse, EPAM Systems, and Techxot — thank you for supporting the community.

🔷 My Personal Takeaways — What I’m Doing Differently Now

Here’s what I’m taking back to the desk and actually acting on:

On vNext and platform modernization: Start getting familiar with the Strangler Fig approach now — don’t wait for a migration to be forced. Understanding the pattern early means you can start shaping your current implementation to support it.

On AI: Move past experimentation. If you’re building anything with AI in the Sitecore space, invest in understanding MCP and hallucination-safe design patterns. The maturity bar for production AI implementations is rising quickly.

On headless and XM Cloud: If you haven’t started the composable journey yet, the ecosystem is ready for you. The tooling, patterns, and community knowledge are all there now.

On community: Show up. Whether at SUGCON, local Sitecore user groups, or online forums — the knowledge shared in this community is one of the most underrated resources in the Sitecore ecosystem, and it only works because people contribute to it.

Wrapping Up

SUGCON India 2026 was a reminder that the Sitecore ecosystem isn’t standing still. vNext signals a platform team that has listened carefully to years of community feedback and is building for the next decade — not defending the last one.

The combination of modern .NET foundations, AI woven thoughtfully into the platform, and a maturing headless ecosystem makes the next 12–18 months a genuinely exciting time to be working in this space.

I hope this recap was useful — whether you attended and want to consolidate your notes, or you couldn’t make it and wanted a proper rundown of what happened.

Stay tuned for more Sitecore articles, tips, and deep-dives right here on the blog.

Till then, Happy Sitecoring! 😊

Did you attend SUGCON India 2026? What was your biggest takeaway? Drop it in the comments below — I’d love to hear from you!

XM Cloud Migration and API Patterns — Real Challenges We Faced and How We Fixed Them

Hello Sitecorian Community,

If you’ve worked on a Sitecore XM Cloud migration project, you’ve probably faced something like this:

“The architecture is signed off. The team starts building. Three weeks in, we discover 80% of the existing MVC components won’t work. The estimate needs to triple.”

This is not a rare situation. It happens regularly because most migration guides focus on what to do at a high level — not the specific things that will actually bite you mid-sprint.

In this post, I want to share the real challenges we’ve encountered on XM Cloud migration projects, and the API integration patterns that break in production even when they work fine in dev.

The Real Problem With XM Cloud Migrations

The first thing to be clear about:

Migrating from Sitecore 10 MVC to XM Cloud is not an upgrade. It is a full re-platforming to a headless, SaaS architecture.

Here is what changes at the architecture level:

Traditional Sitecore MVCXM Cloud (Headless)Controller renderings + Razor viewsJSS components in Next.js / ReactServer-side rendering and logicFrontend-driven renderingCD server for content deliveryExperience Edge CDN — no CD serverxDB-driven personalizationRule-based only, or Sitecore PersonalizeTight coupling with .NETAPI-first, decoupled architecture

Challenge 1: Every MVC Rendering Needs to Be Rebuilt

This is consistently the largest effort in any migration.

Controller renderings, Razor views, rendering parameters, server-side visibility logic — all of it needs to become a JSS component. There is no conversion path. You rebuild using the Headless SXA information architecture:

• Tenant → Site → Pages
• Page Designs and Partial Designs replace layouts
• All rendering logic moves to the frontend
• Custom placeholder logic needs to be redesigned — older nesting patterns don’t map cleanly

⚠️ If your existing solution is not SXA-based: adopting Headless SXA becomes an additional workload on top of the component rebuild. You need to re-map your entire solution into the SXA tenant/site/page structure. Budget for this separately.

Challenge 2: Personalization Cannot Be Migrated — It Needs to Be Redesigned

This is the one that surprises most teams.

XP personalization was powered by xDB analytics. XM Cloud does not have xDB. The personalization rules you built on XP will not work in XM Cloud. Do not try to port them — the engines are fundamentally different.

What we did instead:

• Audited every existing personalization rule
• Identified the business intent behind each rule
• Redesigned using XM Cloud built-in rules for simple cases (geo, auth, device type)
• Used Sitecore Personalize for anything requiring behavioral targeting or multi-source decisioning

This needs to be a separate scoping conversation with the client — not something discovered during sprint three.

Challenge 3: Bad Content Migrates Perfectly

The tooling (Sitecore CLI, Content Serialization) handles the mechanical migration well. What it cannot fix is content that was already messy.

Common issues we see after migration:

• Items losing workflow state or associations
• Media references breaking because folder casing changed
• Personalize dependencies still embedded in content items
• Old placeholder configurations causing component mapping errors
• Inconsistent templates creating template explosion in the new environment

✅ What helped us: Run a full content audit before any migration script runs. Agree a freeze period with the client — no new content during the audit and initial migration window. It sounds disruptive but saves weeks of cleanup later.

Challenge 4: The C# Team and Next.js

Most established Sitecore teams are strong in C#. All XM Cloud documentation and official tooling assumes you are building with Next.js.

The ASP.NET Rendering SDK exists but you will be off the golden path — fewer examples, less community support, and real limitations when integrating with Sitecore Personalize.

What helped us: We ran a Next.js learning sprint before the project kicked off. Getting two or three developers comfortable with React, the JSS SDK, and the Next.js App Router before sprint one paid back immediately. Don’t skip this step.

About SitecoreAI Pathway

Sitecore announced SitecoreAI Pathway at Symposium 2025. Here is what we know from official sources:

• Handles content migration only — not code. The rendering rebuild is still a separate effort
• Up to 70% faster content migration timelines — around 100,000 pages migrated during beta
• Included in Sitecore 360 subscriptions at no extra cost
• Supports Sitecore XP migrations now, rolling out to Adobe/Optimizely/Contentful
• AI + human-in-the-loop — you validate and correct what the AI missed

If your client is on Sitecore 360, include a Pathway assessment in your discovery phase.

API Integration — The Patterns That Break in Production

Moving to API integration patterns on Sitecore projects. Here is a scenario we’ve encountered more than once:

“The integration with the CRM worked perfectly in dev and UAT. On go-live day, under real traffic, it starts timing out. Logs point to Experience Edge GraphQL being hammered.”

API failures on Sitecore projects are rarely about writing the wrong code. They are almost always about not fully understanding how Experience Edge works.

How Experience Edge Actually Delivers Content

Experience Edge is Sitecore’s globally distributed, CDN-backed GraphQL API. Your Next.js rendering host fetches content from Edge — not directly from the CM.

Two critical things that follow from this architecture:

• Custom Content Resolvers do not execute on Edge. They run at publish time only. If your resolver needs runtime context (visitor’s browser, query string, session data) — that is not supported on Edge. Redesign around it.
• Content not appearing on the live site? Check the publish-to-Edge pipeline first, not your Next.js code. A publishing job that fails silently during busy editorial periods is a common cause — set up infra-level alerting on Edge publish failures.

Caching Strategy — Don’t Treat All Data Sources the Same

The pattern that breaks most often: a page pulls from XM Cloud content, a product API, and CDP profile data — all with the same caching approach. Change frequency is completely different for each source:

Data SourceChange FrequencyCorrect StrategyXM Cloud contentHours to daysISR or full static generation (Next.js)Product / commerce dataMinutes to hoursServer-side with short revalidationCDP profile / audience dataPer sessionClient-side fetch after page load — cannot be edge-cached

The Webhook Write-Back Problem

A common integration pattern now with SitecoreAI: a webhook fires → Azure Function calls an AI service → result writes back to Sitecore via the Management API.

The silent failure we hit: the Management API respects workflow state. If the agent tries to write to an item in an approved or published workflow state, and the API token does not have override permissions — it fails silently. No error in logs. No exception thrown. Just nothing happens.

# Always test write-back against every workflow state:
# Draft state         → write allowed ✅
# Awaiting review     → depends on token permissions ⚠️
# Approved state      → fails silently without override ⚠️
# Published state     → fails silently without override ⚠️

✅ Fix: Add Management API write-back tests for every workflow state your implementation uses. Not just the happy path. This test will save you a go-live incident.

Use Sitecore Connect Before Writing Custom Code

Before writing any custom integration from scratch, check Sitecore Connect first. It ships with pre-built connectors for Salesforce, OpenAI, Gemini, and others. Connect integrations operate within SitecoreAI’s governance and audit model. A custom webhook pipeline does not. For enterprise clients with compliance requirements around data flows — this distinction matters.

Why This Helped Our Team

Before understanding these patterns:

• Go-live issues were hard to diagnose — wrong place to start debugging
• Multi-source pages had inconsistent behaviour under load
• Webhook write-backs silently failed in certain workflow states

After:

• Published pipeline alerts catch Edge failures before users report them
• Each data source has a caching strategy matched to its change frequency
• Integration test matrix covers all workflow states explicitly

Final Thoughts

XM Cloud migration and API integration both require understanding the underlying architecture deeply — not just following the official documentation. The documentation tells you what things are. Real project experience tells you where the edges are.

If you are planning an XM Cloud migration, run a full rendering inventory and content audit before committing to a timeline. Those two things will tell you more about the true scope than any architecture review.

Stay tuned for more Sitecore-related articles, tips, and tricks to enhance your Sitecore experience.

Till then, happy Sitecoring! 😊

Please leave your comments or share this article if it’s useful for you!

Mastering Advanced Search Queries with GraphQL in Sitecore XM Cloud - Part 3

Hi Sitecore folks!,

As your Sitecore content ecosystem evolves, the need for advanced and flexible search queries becomes paramount. Simple GraphQL queries are great for small datasets, but as the content grows and becomes more complex, so too must your queries. This article explores advanced search querying techniques, pagination, and real-world examples that you can implement in Sitecore XM Cloud to optimize content discovery and boost user experience.

Why Advanced Search Queries Matter

When working with Sitecore, especially in large-scale projects, simple queries quickly hit their limits. Advanced querying is essential for handling:

• Multiple Conditions: Using logical operators like AND/OR for more granular control.
• Exclusion Filters: Omitting certain results based on specific criteria.
• Sorting and Pagination: Managing large datasets for better performance and usability.
• Filtering on Complex or Nested Fields: Targeting multi-value or deeply nested fields.

GraphQL offers the flexibility needed to tackle these challenges efficiently, enabling developers to create precise, high-performing queries that meet both functional and performance requirements.

Tips for Writing Efficient GraphQL Queries

To get the most out of your GraphQL queries in Sitecore, consider the following best practices:

1. Use Logical Operators (AND/OR/NEQ): Combine conditions effectively for highly specific filtering.
2. Implement Pagination: Always paginate large result sets to avoid unnecessary data loading and to improve user experience.
3. Sort Results for Better UX: Sort results based on fields like date or relevance to enhance how users interact with your data.
4. Test Queries Before Integration: Use tools like GraphQL Playground to test and refine your queries, ensuring they work as expected before going live.

Common Comparison Operators

Understanding how and when to use comparison operators is key to building effective queries. Here’s a quick reference:

Operator Meaning Example Use Case

    EQ Equal to Department = "Engineering"

    NEQ Not equal to Status != "Inactive" 

    GT Greater than HireDate > "2022-01-01"

    LT Less than Salary < 50000 

    GTE Greater or equal Experience >= 5 

    LTE Less or equal Age <= 30

    IN In a list Department IN ("Engineering", "Marketing")

Practical Query Examples

Let’s explore some advanced query examples that leverage these techniques:

1. Filtering by Path, Template ID, and User Name with Pagination

In this example, we query for filtered items based on path, template ID, and user name, with pagination for improved performance.

query FilteredItemsResult(
  $pageSize: Int = 10
  $after: String
  $rootItem: String!
  $filterValue: String!
  $templateId: String!
) {
  ExpertData: search(
    where: {
      AND: [
        { name: "_path", value: $rootItem, operator: CONTAINS }
        { name: "_templates", value: $templateId, operator: EQ }
        { name: "UserName", value: $filterValue, operator: CONTAINS }
      ]
    }
    first: $pageSize
    after: $after
  ) {
    pageInfo {
      endCursor
      hasNext
    }
    results {
      name
      id
      UserName: field(name: "UserName") { value }
    }
  }
}

Key Points:

• AND Grouping: All conditions must be met.
• Cursor-Based Pagination: Handles large datasets efficiently.

2. Advanced Event Query: Multi-Criteria Filtering

Here we combine OR filters within an AND block to find events based on location, available seats, sponsorship status, and rating. We also exclude events tagged as “Internal” or organized by “Test Org”.

query {
  search(
    where: {
      AND: [
        { name: "_templates", value: "Event", operator: EQ }
        { name: "Status", value: "Published", operator: EQ }
        { name: "StartDate", value: "2025-01-01", operator: GTE }
        { name: "EndDate", value: "2025-12-31", operator: LTE }
        {
          OR: [
            { name: "City", value: "London", operator: EQ }
            { name: "City", value: "Berlin", operator: EQ }
          ]
        }
        { name: "SeatsAvailable", value: "1", operator: GTE }
        { name: "IsVirtual", value: "false", operator: EQ }
        {
          OR: [
            { name: "IsSponsored", value: "true", operator: EQ }
            { name: "Rating", value: "4.5", operator: GT }
          ]
        }
        { name: "Tags", value: "Internal", operator: NEQ }
        { name: "Organizer", value: "Test Org", operator: NEQ }
      ]
    }
    orderBy: [
      { fieldName: "StartDate", direction: ASC }
      { fieldName: "Rating", direction: DESC }
    ]
    first: 10
  ) {
    total
    results {
      items {
        id
        name
        fields {
          Title { value }
          City { value }
          StartDate { value }
          SeatsAvailable { value }
          IsVirtual { value }
          IsSponsored { value }
          Rating { value }
          Tags { value }
          Organizer { value }
        }
      }
      pageInfo { endCursor hasNextPage }
    }
  }
}

3. Combining Filters for Tags and Authors

This query finds articles or news posts tagged with specific labels and authored by designated individuals, all sorted by the most recent publish date.

query {
  search(
    where: {
      AND: [
        {
          OR: [
            { name: "Tags", value: "News", operator: CONTAINS }
            { name: "Tags", value: "Article", operator: CONTAINS }
          ]
        }
        {
          OR: [
            { name: "Author", value: "Alice", operator: EQ }
            { name: "Author", value: "Bob", operator: EQ }
          ]
        }
      ]
    }
    orderBy: [{ fieldName: "PublishDate", direction: DESC }]
    first: 6
  ) {
    total
    results {
      items {
        id
        name
        fields {
          Title { value }
          Author { value }
          Tags { value }
        }
      }
      pageInfo { endCursor hasNextPage }
    }
  }
}

Key Points:

• Nested OR within AND: Complex filtering allows for a flexible and tailored query.
• Ordering by Date: Ensures the most recent articles appear first.

4. Filtering by Values Greater Than a Specified Amount

This query filters employees by department, hire date, and template, returning a list of employees hired after January 1, 2022, from either the Engineering or Marketing department.

query {
  search(
    where: {
      AND: [
        { name: "_templates", value: "Employee", operator: EQ }
        { name: "Department", value: "Engineering;Marketing", operator: IN }
        { name: "HireDate", value: "2022-01-01", operator: GT }
      ]
    }
    orderBy: [
      { fieldName: "Department", direction: ASC }
      { fieldName: "HireDate", direction: DESC }
    ]
    first: 12
  ) {
    total
    results {
      items {
        id
        name
        fields {
          FirstName { value }
          LastName { value }
          Department { value }
          HireDate { value }
          Manager {
            value
          }
        }
      }
      pageInfo { endCursor hasNextPage }
    }
  }
}

Conclusion

Advanced GraphQL queries provide Sitecore developers with the flexibility to handle complex search scenarios, enabling personalized content discovery and more efficient content management. By mastering pagination, logical operators, and filters, you can create powerful, scalable solutions that enhance user experience while improving performance.

I hope you enjoy this Sitecore blog. Stay tuned for more Sitecore related articles.

Till that happy Sitecoring :)

Please leave your comments or share this article if it’s useful for you.

Unlocking the Power of GraphQL in Sitecore: A Practical Guide to Queries, Mutations, and Fragments – Part 2

Hi Sitecore folks!,
Welcome back, fellow developers! In the previous post of our GraphQL series, we dived into the basics of querying for component data in Sitecore. If you missed it, be sure to check out [Unlocking the Power of GraphQL in Sitecore: A Guide to Useful Queries – Part 1].

In this second installment, we're going to take a deeper dive into some of the more advanced features of GraphQL: mutations, fragments, and some common queries. These powerful tools allow you to extend your GraphQL usage in Sitecore, making your development work more efficient and dynamic.

We'll walk through how to harness these features, explore real-life examples, and explain how they can streamline your content management workflows. Whether you’re new to GraphQL or a seasoned pro looking to sharpen your skills, this guide will provide you with the essentials to elevate your GraphQL game.

GraphQL Mutations: Modifying Data on the Server

GraphQL isn't just a tool for reading data—it also allows you to modify data via mutations. In Sitecore, mutations empower you to create, update, or delete items, templates, media, and more directly through GraphQL queries.

Unlike REST, which typically uses GET requests to retrieve data, GraphQL uses mutations to make changes to data. This distinction ensures that your data-modifying operations are organized and explicit, reducing the potential for confusion or errors.

Create Data with Mutations

Let's start by exploring a mutation for creating new items. This is useful when you're working with content that's frequently updated or needs to be programmatically generated. Here’s an example mutation for creating a new item in Sitecore:

mutation CreateItem {
  createItem(
    name: "Created MutationsItem"
    template: "{4330C04F-5CAA-4E93-A2B2-634900395E51}"
    parent: "{C081F940-3F38-4E10-8F43-B80AA63BC1BA}"
    language: "en"
    fields: [
      { name: "title", value: "New Item Created with Mutations" }
      { name: "subtitle", value: "This is a new Sitecore item created using mutations." }
    ]
  ) {
    path
    id
  }
}

This mutation will create a new item with a specific template, assign it to a parent item, and populate its fields (e.g., title and subtitle). The result will return the path and ID of the newly created item.

Update Data with Mutations

Next, let’s look at a mutation for updating an existing item. For example, if you need to update an item's title and subtitle, the mutation would look like this:

mutation UpdateItem {
  updateItem(
    path: "/sitecore/content/Home/MySampleProject/MutationsItem/CreatedMutationsItem"
    language: "en"
    version: 1
    fields: [
      { name: "title", value: "Updated Item Title" }
      { name: "subtitle", value: "Updated subtitle content for the item." }
    ]
  ) {
    title { value }
    subtitle { value }
  }
}

This mutation targets a specific item and updates its fields with the new values. The query also returns the updated title and subtitle fields.

Delete Data with Mutations

Mutations aren't just for creating and updating—they’re also powerful for deleting content. Here's an example of a mutation that deletes an item:

mutation DeleteItem {
  deleteItem(
    path: "/sitecore/content/Home/MySampleProject/MutationsItem/CreatedMutationsItem"
  )
}

Once executed, the specified item is removed from Sitecore’s content tree.

Fragments: Modularizing Queries for Reusability

As your queries become more complex, you may notice a lot of repetition in your field selections. This is where fragments come into play. A fragment allows you to define a set of fields once and reuse them across multiple queries. This makes your queries more modular, cleaner, and easier to maintain.

In Sitecore, you might be dealing with nested content types, so creating reusable fragments for fields like title and subtitle is incredibly helpful.

Here's an example where we define two fragments: RelatedItems and SubRelatedItems. Each fragment specifies the fields we need for those content types:

fragment RelatedItems on RelatedItems {
  title { value }
  subtitle { value }
}

fragment SubRelatedItems on SubRelatedItems {
  title { value }
  subtitle { value }
}

Now, you can use these fragments in your main query to fetch content in a cleaner, more efficient way:

query ContentCardQuery($datasource: String!) {
  datasource: item(path: $datasource, language: "en") {
    name
    newsItems: children(
      includeTemplateIDs: ["{B5D116DE-BFE8-4A06-A3FE-90C84320ECCB}"]
    ) {
      name
      ...RelatedItems
    }
    blogItems: children(
      includeTemplateIDs: ["{02CDBE64-254B-424B-90C3-E74FDBA02572}"]
    ) {
      name
      ...SubRelatedItems
    }
  }
}

By using inline fragment spreads (...RelatedItems and ...SubRelatedItems), this query is now much cleaner and more maintainable. The fragments handle the repetitive fields for you, and you only need to call them where necessary.

Fetching and Organizing Data Efficiently

GraphQL shines when it comes to fetching specific data. You can retrieve exactly what you need, reducing unnecessary requests and optimizing your application. Here’s an example where we query multiple data sources under a parent item, and we fetch only the required fields for news and blog items:

query ContentCardQuery($datasource: String!) {
  datasource: item(path: $datasource, language: "en") {
    name
    newsItems: children(
      includeTemplateIDs: ["{B5D116DE-BFE8-4A06-A3FE-90C84320ECCB}"]
    ) {
      name
      ... on RelatedItems {
        title { value }
        subtitle { value }
      }
    }
    blogItems: children(
      includeTemplateIDs: ["{02CDBE64-254B-424B-90C3-E74FDBA02572}"]
    ) {
      name
      ... on SubRelatedItems {
        title { value }
        subtitle { value }
      }
    }
  }
}

In this query, we use child item queries to pull news and blog items based on their specific templates. We then use fragments to ensure we fetch only the required fields for each item.

Conclusion: GraphQL’s Full Potential in Sitecore

GraphQL in Sitecore isn’t just a powerful tool for reading data; it offers a comprehensive way to manage and interact with content. By leveraging mutations for data creation, updates, and deletions, along with fragments for cleaner, reusable queries, you can optimize your Sitecore applications and workflows.

In this part of the series, we've covered the essential techniques for handling mutations and fragments, but we’re just scratching the surface. Stay tuned for Part 3, where we’ll dive into complex queries, variables, and directives—all the advanced tools you’ll need to become a GraphQL pro in Sitecore.

Until then, get hands-on with what we've covered, and experiment with mutations and fragments in your own projects. The more you practice, the easier it will get!

I hope you enjoy this Sitecore blog. Stay tuned for more Sitecore related articles.

Till that happy Sitecoring :)

Please leave your comments or share this article if it’s useful for you.

Supercharging Sitecore with GraphQL: A Developer’s Guide

Introduction

In the dynamic world of web development, efficiency and performance are paramount. One powerful way to achieve both is by integrating GraphQL with Sitecore, a leading enterprise content management system. While GraphQL isn’t new to Sitecore, the advent of Sitecore JavaScript Services (JSS) has made its implementation smoother and more accessible than ever.

This guide walks you through the process of setting up GraphQL in Sitecore, focusing on how to craft effective queries to retrieve content. Whether you're building a new solution or enhancing an existing one, this integration can be a game-changer.

---

Why GraphQL with Sitecore?

Integrating GraphQL into Sitecore offers a host of benefits:

• Enhanced Flexibility: Fetch only the data you need—no more, no less.
• Streamlined Development: Decouple frontend and backend workflows for faster iteration.
• Improved Performance: Reduce payload sizes and speed up response times.
• Modern Frontend Compatibility: GraphQL’s schema-based approach aligns perfectly with frameworks like React, Vue.js, and Angular.

---

Getting Started: Installing JSS and GraphQL

To begin, you’ll need the correct JSS server component package for your Sitecore version. Once identified:

Step 1: Install the JSS Package

• Open Sitecore in your browser.
• Navigate to: Desktop → Development Tools → Installation Wizard.
• Upload and install the JSS package.

This installation will add several components to your Sitecore instance:

• Configuration files under App_Config (including LayoutService and GraphQL configs).
• DLLs in the bin folder.
• JssApp.cshtml view file.
• Sitecore templates under Foundation and System.

---

Step 2: Configure GraphQL

After installation:

1. Go to App_Config\Services.GraphQL.
2. Rename the file Sitecore.Services.GraphQL.Content.Master.config.example to Sitecore.Services.GraphQL.Content.Master.config.

---

Step 3: Add and Configure API Key

To query GraphQL via API:

1. Switch to the Core database.
2. Navigate to /sitecore/system/Settings/Services/API Keys.
3. Right-click and insert a new API Key item.

Enable API Key Authentication

Edit the file:
App_Config\Sitecore\Services.GraphQL\Sitecore.Services.GraphQL.config

In the <security> section, enable API Key authentication.

---

Step 4: Access the GraphQL Browser

Once everything is set up, you can test your queries using the Sitecore GraphQL Browser:

• URL format:
  https://your-domain/sitecore/api/graph/items/master/ui

If you encounter an “Authentication required” error:

Fix: Add Site-Neutral Path

1. Open:
   App_Config\Sitecore\Owin.Authentication\Sitecore.Owin.Authentication.config
2. Locate the <siteNeutralPaths> node.
3. Add:
   /sitecore/api/graph/items/

Save the file and retry accessing the GraphQL browser.

---

Step 5: Run Your First Query

Here’s a sample GraphQL query to fetch child items of a context item:

query GQLQuerySamples($contextItem: String!) {
  item(path: $contextItem) {
    children {
      id
      name
    }
  }
}

Important Notes:

• In the Query Variables section, pass the contextItem path.
• In the HTTP Headers, include your API Key.

---

Conclusion

Integrating GraphQL with Sitecore empowers developers to build faster, leaner, and more scalable applications. With precise data fetching, improved performance, and seamless frontend integration, GraphQL is a natural fit for modern Sitecore solutions.

Whether you're a seasoned Sitecore developer or just getting started, embracing GraphQL can elevate your development workflow and deliver richer digital experiences.

I hope you enjoy this Sitecore blog. Stay tuned for more Sitecore related articles.

Till that happy Sitecoring :)

Please leave your comments or share this article if it’s useful for you.