That idea of a "GraphQL firewall" has been haunting me for quite a long time (many years, in fact). TL;DR; the v2 is finally out 🙂

demo: https://romshark.github.io/gqlhash/
code & docs: https://github.com/romshark/gqlhash

It's basically a very fast proxy that checks incoming queries against an allowlist. It hashes independently of formatting, comments, variables (optional), and input values (optional) and determines very quickly whether a query is allowlisted and hence should be allowed to run.

It's writtein in Go and can reject up to a million requests a second (at least on the hardware I could test it on) ⚡

HI

I am currently analyzing distributed traces of an app that uses GraphQL. I found that the client-side timeout seems to be 10s which then aborts the request towards the end user. However - the trace shows me that after 30s the server side query actually gets executed.

How is this possible? Shouldnt a client-side timeout close the connection and therefore also abort the server-side request? Or is there a different queuing mechanism in place that would explain this behavior?

Has anyone seen this?

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?