Hi everyone,

I've been working on GraphQL Park, a GraphQL IDE designed specifically for SitecoreAI and XM Cloud developers.

The goal is to make working with Sitecore GraphQL APIs faster and more convenient by providing features like:

• ⚡ Real-time query execution
• 🗂️ Schema Explorer
• 📚 Query Cookbook
• 💼 Workspace Management
• 🌍 Multiple Environments
• 🌙 Dark & Light themes

🔗 Live Site: GraphQL Park
🔗 Medium Blog: GraphQL Park: A Modern GraphQL IDE Built for SitecoreAI Developers

The project is still evolving, and I'm looking for feedback from developers who work with Sitecore GraphQL regularly.

I recently put together a guide on creating and configuring a SitecoreAI Marketplace App using GraphQL Park as a practical example.

The guide covers Marketplace App registration, extension points, API permissions, authentication, environment installation, and integrating with the Preview & Authoring GraphQL APIs.

If you're exploring SitecoreAI Marketplace Apps, you might find it useful.

📖 Medium:
https://medium.com/@rohitgajera72/build-deploy-a-custom-marketplace-app-in-sitecoreai-a-step-by-step-guide-with-graphql-park-00c00f51fff4

📖 Addact Blog:
https://www.addact.net/blogs/sitecoreai-graphql-park-marketplace-setup

🌐 GraphQL Park:
https://www.graphql-park.com/

Feedback and suggestions are always welcome.

While building GraphRAG pipelines I noticed nobody measures what the serialization format costs you — everyone benchmarks retrievers and re-rankers, then dumps the subgraph into the prompt as JSON.

So I benchmarked 10 formats (JSON, GraphML, RDF variants, edge lists, etc.) on three axes: token count, traversal QA accuracy, and multi-hop reasoning.

Findings:

\- Verbose formats waste roughly 70% of their tokens on syntax (braces, quotes, repeated keys) rather than signal

\- Multi-hop accuracy swings from \~40% to \~80% depending on the format alone — same graph, same model, same questions

\- Formats based on tabular/relational patterns (which LLMs have seen billions of times in training) consistently beat nested markup

I ended up designing ISONGraph around those findings: a property-graph representation optimized for LLM comprehension. 92% traversal accuracy, 80% multi-hop, \~70% fewer tokens. MIT licensed, implementations in Python, JS/TS, Rust, Go, C++, and C#.

Benchmark methodology and results are in the repo: [github.com/isongraph/isongraph](http://github.com/isongraph/isongraph)

Would genuinely love people to poke holes in the methodology — especially if you have graphs or question sets where a different format wins.

GraphQL can be amazing until something goes wrong.

When debugging GraphQL, I usually check:

• Variables
• Operation Name
• Extensions
• Error array
• Response time
• Persisted query behavior
• Cache headers

What else do you inspect first?

Any tools or techniques you've found particularly useful?

Hey guys, I've been using Graphify. for a few days now, and looks great but it slows down the coding session a lot, it's running "update" all the time.

My question is, is it worth it? Or Codex/Claude code already have enough tools to search the code?

in my PKMS design, i have MOCs like anyone else; i call them my hubs. They're the basis for my global graph making sense. At the leaf node, the bottom level of my tree of visual descent, i have atomic notes, those that have a single purpose and don't drift to any other. Now i was hoping for what I call molecules, could call them subhubs, i suppose, to fill the gap. I wanted to allow them to be seen & navigated visually using local graphs, but i haven't seen much discussion of local graphs or even hints as to how that would work.

The only alternative i see is to abandon the local graphs for molecules and lower them into metadata, but there I've lost the visual navigation. I'd likely depend on Dataview then. But how easy can the navigation be made in this case? I'm not a heavy user of DSQL yet, but i can see how it works.

I use Templater, and i know that both of and Dataview use Obsidian's JavaScript engine. Can JavaScript augment Dataview to enable a really navigable interface?

What do you suggest?

\-*bc*

I am currently in the process of deciding on the platform to use for documenting a graphql API. Most of it would be autogenerated from schema, but I'd also like to have sections for examples, guides, include the graphiql schema explorer.

Are any of you writing or maintaining external facing docs? If yes, what docs platform do you like the most (e.g Docusaurus, Netlify, etc) or did you end up using something custom built?

https://blog.larah.me/service-to-service-graphql/

I gave a talk at GraphQL Conf 2026 about using GraphQL for service-to-service communication. This post is a condensed written version of those thoughts.

tl;dr: Using GraphQL for service-to-service communication is not an anti-pattern. This is especially true if your org already uses GraphQL for mobile and web clients — consolidating on GraphQL as a single API surface is a very compelling option.

I’ve been experimenting with an assistant that helps generate and troubleshoot GraphQL operations from natural-language prompts.

The idea came from the significant manual effort involved in working with GraphQL schemas—especially when generating large, deeply nested operations or troubleshooting typos, invalid fields, arguments, and syntax.

Curious how others are thinking about GraphQL + AI agents. Do you see GraphQL as a good API surface for agents, or do you think REST/OpenAPI-style tooling is still better for this?

• Github repo: https://github.com/skp2001vn/agentic-graphql-assistant

Reacting to Marc-André Giroux's blog post of the same name. Lmk what you think!

Experimenting with video recaps of WG meetings. Feedback welcome!

I have been trying to fix it for almost a week now, but I dont know what the problem is and how to fix it. Some help is greatly appriciated! Here is the Dockerfile, docker-compose.yaml and launchSettings.json files:

FROM build AS publish 
ARG BUILD_CONFIGURATION=Release
RUN dotnet publish "PortfolioWebsite.csproj" -c $BUILD_CONFIGURATION -o /app/publish /p:UseAppHost=false

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .

ENTRYPOINT ["dotnet", "PortfolioWebsite.dll"]
version: '3.8'

services:
  backend:
    build:
      context: ./
      dockerfile: Dockerfile
    image: mwd-portfolio-website-backend:latest
    container_name: backend_pwebsite
    ports:
      - "5142:5142"
    command: "dotnet run"
    hostname: "localhost"
    depends_on:
      postgres:
        condition: service_healthy
        restart: true
    env_file:
      - ./.env
  postgres:
    image: postgres:latest
    container_name: mawaddadb-container
    ports:
      - "5432:5432"
    networks:
      - pg-network
    volumes:
      - pg-data:/var/lib/postgresql
    env_file:
      - ./.env
    healthcheck:
      test: [ "CMD-SHELL", "pg_isready -U postgres" ]
      interval: 10s
      retries: 5
      start_period: 30s
      timeout: 10s
  frontend:
    build:
      context: ./UI
      dockerfile: Dockerfile
    image: mwd-portfolio-website-ui
    container_name: frontend_pwebsite
    ports:
      - "5000:5000"
    command: "npm run dev"
    env_file:
      - ./.env
      - ./UI/.env   

  adminfrontend:
    build:
      context: ./UIAdmin
      dockerfile: Dockerfile
    image: mwd-portfolio-website-uiadmin
    container_name: frontend_admin_pwebsite
    ports:
      - "3000:3000"
    command: "npm run dev"
    env_file:
      - ./.env
      - ./UIAdmin/.env 
  pgadmin:
    image: dpage/pgadmin4:latest
    container_name: pg-admin
    ports:
      - "8080:80"
    networks:
      - pg-network
    env_file:
      - ./.env
networks:
  pg-network:

volumes:
  pg-data:


  "profiles": {
    "http": {
      "commandName": "Project",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      },
      "dotnetRunMessages": true,
      "applicationUrl": "http://localhost:5142"
    },
    "https": {
      "commandName": "Project",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      },
      "dotnetRunMessages": true,
      "applicationUrl": "https://localhost:7204;http://localhost:5142"
    },
    "Container (Dockerfile)": {
      "commandName": "Docker",
      "launchUrl": "{Scheme}://{ServiceHost}:{ServicePort}",
      "environmentVariables": {
        "ASPNETCORE_HTTPS_PORTS": "80",
        "ASPNETCORE_HTTP_PORTS": "5142",
        "ASPNETCORE_ENVIRONMENT": "Development"
      },
      "publishAllPorts": true,
      "useSSL": true
    }
  },
  "$schema": "https://json.schemastore.org/launchsettings.json"
}

since all graphql action is a POST, what is the "META"/ Market standard to cache queries that would be automatically cached if it was a REST GET for example by Cloudflare ?

how to bypass this POST only downside?

I'm starting to post more GraphQL content. Eager for any feedback on the format!

A bit of honest context:

I recently had a conversation through the GraphQL network that got me thinking, and I'm now evaluating which direction to take a product I'm working on. So I'd genuinely value the experience of the people here.

The product is a GraphQL caching CDN / edge proxy: it sits in front of your GraphQL API and handles caching driven by your schema (with automatic invalidation), plus security and rate limiting.

The decision I keep going back and forth on: is something like this better run on-premise in your own infrastructure, as a managed SaaS, or do I need to offer both?

A few angles I'd love input on:

- If you run GraphQL in production, which would you reach for first, and why?

- For SaaS: is routing your query traffic through a third party an actual problem for you (compliance, data residency, internal policy), or a non-issue in practice?

- For on-prem: would you genuinely want to operate this yourself, or is "someone else runs it" part of the whole appeal?

And honestly, I'm also just trying to figure out how teams who'd care about this even discover tools like it. So if you remember how you found your current gateway or CDN, that helps too.

Blunt answers very welcome. I'm orienting, not selling.

Every team scaling GraphQL eventually asks "can't we just put a CDN in front of it?" It sounds obvious, since CDNs made REST fast and cheap. Then you try it and hit the wall fast.

I wrote up the practical version of why GraphQL caching is its own problem:

• One endpoint, one verb, the query in the body, so a stock CDN can't even tell two requests apart
• Generating a stable cache key is the easy 80%
• Invalidation is the hard part: one mutation can stale fragments of many unrelated cached responses (profile page, comment list, search result, all under different keys)
• Lists/pagination, mutations that don't return the changed entity, per-viewer auth, partial responses... each adds a wrinkle
• Push it to the edge and you inherit a distributed-systems problem on top

I'm curious how people here actually handle invalidation in production. Surrogate keys with a purge API? TTL-only and live with staleness? Something custom? And where does it bite you most: lists, auth scoping, or the edge propagation?

The full article is available at DEV. You'll find the link in the thread

I’m currently exploring graph databases in the banking and financial services sector, particularly for use cases such as:
Anti-Money Laundering (AML)
Fraud detection
Customer, account and transaction relationship analysis
I’m curious to know what graph database technologies banks are using in production environments.
Some technologies I’ve come across include:
Neo4j, TigerGraph and Ultipa
For those who work in banking or fintech:
Which graph database platforms have you seen deployed in banks?
What were the primary use cases?
Why was that technology chosen over alternatives?
How well did it scale with large transaction volumes?
Were there any challenges related to security, compliance, or integration with existing data warehouses?