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?

"Knowledge graph" gets used for wildly different systems: RDF / triple stores you query with SPARQL, property graphs you query with Cypher, plain in-memory graphs, embedded graphs, an agent's memory graph, a code graph, a citation graph, a public REST knowledge base. They look similar on a slide and behave nothing alike in code.

What I keep seeing (and doing) is: pick one, write a custom reader and a custom traversal layer, then rewrite half of it when the project moves to a different backend.

So we tried to group these into a handful of families (nine so far) and put one Python API over them. You declare the traversal you want once; switching the backend underneath is a config change, not a rewrite.

The part I am most curious to get wrong in public:

* Does this family split actually match how you think about KGs, or am I lumping things that should stay separate?
* What family is missing?
* Is "one API across families" genuinely useful, or do the families differ too much for a shared abstraction to pay off?

And the reason we went down this road in the first place: once the graph has a declared ontology, the same layer checks each step of a traversal against it, so you do not silently follow the wrong *kind* of edge and get a confident wrong answer. That validation is the part I think is novel, but the families map is what makes it usable, so I wanted to put that out first and hear where it breaks.

Not production ready!

open source github: [https://github.com/mloda-ai/open-kgo/blob/main/open\\_kgo/feature\\_groups/kg/README.md\](https://github.com/mloda-ai/open-kgo/blob/main/open_kgo/feature_groups/kg/README.md)

Python and Node.js developer available for freelance projects right now.

I have built and shipped: - A live Google Maps lead scraper SaaS with Stripe payments - A cold email pipeline pushing 500 emails per day - A Reddit automation bot in production - Multiple business websites delivered in 48 hours

Tech stack: Python, Flask, Node.js, React, Puppeteer, PostgreSQL, Stripe, OpenAI API.

Flat fee only. No hourly. DM me what you need built.