Add GraphQL & AI subpage (/ai) with interactive demos - #2469
Conversation
New /ai route showcasing GraphQL for AI systems (MCP servers, RAG, agents & tool calling). Includes hero with canvas particle network, interactive Star Wars GraphQL demo executing real queries client-side, syntax-highlighted code blocks, by-the-numbers stats, and CTA. - src/app/(main)/ai/: page + 9 components (hero, interactive-demo, how-it-works, why-graphql-ai, use-cases, by-the-numbers, cta-community, syntax-highlight) - src/pages/_meta.tsx: add 'ai' nav entry pointing to /ai - src/globals.css: add @Keyframes fadeInUp used by interactive demo - package.json + pnpm-lock.yaml: add sharp dependency
|
@aexol is attempting to deploy a commit to the The GraphQL Foundation Team on Vercel. A member of the Team first needs to authorize it. |
Run `prettier --write` on the 7 files flagged by `pnpm format:check` to unblock the CI prettier check on the feat/ai-subpage branch. No behavioral changes — formatting only.
| rest: "ad-hoc", | ||
| restDesc: "no guarantees", | ||
| explanation: | ||
| "GraphQL responses match the query shape exactly — validated against the schema at runtime. REST responses offer no structural guarantees, forcing LLMs to handle arbitrary JSON shapes.", |
There was a problem hiding this comment.
This is somewhat disingenuous considering that OpenAPI exists, and that most programming languages are fully typed.
I would suggest that this breaks down for agents specifically when they need to remember very complex types with deep relationships.
It's not the types that make the difference. It's that you don't need to know all of them at the same time when dealing with graph data.
| rest: "manual", | ||
| restDesc: "per endpoint", | ||
| explanation: | ||
| "Every GraphQL API includes built-in introspection. Agents can discover available types, fields, and arguments automatically. REST tool calling requires hand-crafted JSON Schema definitions for every endpoint.", |
There was a problem hiding this comment.
It doesn't have to be hand-crafted. Nearly every REST framework has automatic OpenAPI auto-creation capability built-in, so I don't think this is a point in GraphQL's favor.
You have to tell the agent where that schema is produced. It's built-in to the spec in GraphQL, so GraphQL is plug-in-play.
Similarly - and not mentioned here - is how easy it is to add per-field, per class, and per query documentation which can also be introspected.
So you need only a graphql schema instead of needing an AGENT.md + RAML + API in order to have things work with AI, and you don't need to tell an agent how to get to all three things; you only need one thing.
3 participants
New /ai route showcasing GraphQL for AI systems (MCP servers, RAG, agents & tool calling). Includes hero with canvas particle network, interactive Star Wars GraphQL demo executing real queries client-side, syntax-highlighted code blocks, by-the-numbers stats, and CTA.
Closes #
Description