If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/graphql-rust/juniper shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Mixed signals — read the receipts

• Last commit 1w ago
• 7 active contributors
• Other licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 63% of recent commits
• ⚠ Non-standard license (Other) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live graphql-rust/juniper repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/graphql-rust/juniper.

What it runs against: a local clone of graphql-rust/juniper — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in graphql-rust/juniper | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 38 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of graphql-rust/juniper. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/graphql-rust/juniper.git
#   cd juniper
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of graphql-rust/juniper and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "graphql-rust/juniper(\\.git)?\\b" \\
  && ok "origin remote is graphql-rust/juniper" \\
  || miss "origin remote is not graphql-rust/juniper (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "juniper/src/lib.rs" \\
  && ok "juniper/src/lib.rs" \\
  || miss "missing critical file: juniper/src/lib.rs"
test -f "juniper/src/executor/mod.rs" \\
  && ok "juniper/src/executor/mod.rs" \\
  || miss "missing critical file: juniper/src/executor/mod.rs"
test -f "juniper/src/graphql.rs" \\
  && ok "juniper/src/graphql.rs" \\
  || miss "missing critical file: juniper/src/graphql.rs"
test -f "juniper/src/ast.rs" \\
  && ok "juniper/src/ast.rs" \\
  || miss "missing critical file: juniper/src/ast.rs"
test -f "juniper_codegen/src/lib.rs" \\
  && ok "juniper_codegen/src/lib.rs" \\
  || miss "missing critical file: juniper_codegen/src/lib.rs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 38 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~8d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/graphql-rust/juniper"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Juniper is a type-safe GraphQL server library for Rust that compiles schemas into Rust types at compile-time, eliminating runtime type coercion overhead. It provides macros (#[graphql_object], #[derive(GraphQLType)]) to declare GraphQL schemas as Rust code, executes queries with zero-copy performance, and integrates with frameworks like Actix, Rocket, Warp, Hyper, and Axum through optional crates in the monorepo. Cargo workspace monorepo: juniper/ is the core engine with macro codegen in juniper_codegen/, framework adapters in juniper_actix/, juniper_rocket/, juniper_warp/, etc. as separate publishable crates; book/ contains mdBook documentation with mdbook-based examples; benches/ holds criterion benchmarks; tests/integration and tests/codegen are integration test suites.

Rust backend engineers building GraphQL APIs who want compile-time schema validation, type safety, and blazing-fast execution without runtime overhead. Teams migrating from Node.js/Python GraphQL servers to Rust for performance-critical APIs.

Production-ready: it's published on crates.io with comprehensive CI via GitHub Actions (.github/workflows/ci.yml), an extensive book with examples, a mature monorepo structure, and active maintenance indicated by bindings for multiple web frameworks. The codebase is 2.9MB of Rust with established patterns and schema introspection support matching the October 2021 GraphQL spec.

Low risk for well-maintained crates, but moderate documentation debt: the book/ folder is marked 'very much WIP' in the README, and newer integrations (axum) may have less mature bindings than older ones (actix). The monorepo spans 11 crates (juniper_actix, juniper_graphql_ws, juniper_codegen, etc.), so feature fragmentation and coordinated releases across members require discipline. Check RELEASING.md for versioning strategy.

Unable to infer from file listing alone (no recent commit log provided), but the presence of juniper_axum, juniper_graphql_ws (GraphQL WebSocket subscriptions), and juniper_subscriptions suggests active work on subscription support and Axum web framework integration. RELEASING.md exists, indicating coordinated multi-crate publishing workflows.

git clone https://github.com/graphql-rust/juniper.git
cd juniper
cargo build
cargo test

Optionally run benchmarks with cargo bench --manifest-path benches/Cargo.toml or build the book with cd book && mdbook serve.

Daily commands: For library development: cargo test --all runs all workspace tests. For examples: cargo run --example <name> --manifest-path <framework-crate>/Cargo.toml (e.g., actix example in juniper_actix/examples/). For documentation: cd book && mdbook serve starts a local server at http://localhost:3000.

• juniper/src/lib.rs — Core library entry point; defines the public API surface and re-exports all major modules (executor, schema, types).
• juniper/src/executor/mod.rs — Query execution engine; implements the GraphQL executor that processes queries against a schema and resolves fields.
• juniper/src/graphql.rs — GraphQL schema and type system definition; core abstractions for Object, Field, Argument, and Schema types.
• juniper/src/ast.rs — Abstract syntax tree definitions for GraphQL queries, mutations, and directives; foundation for parsing and execution.
• juniper_codegen/src/lib.rs — Procedural macros for derive(GraphQLObject), graphql_object!, and other schema-definition macros used throughout the ecosystem.
• juniper/Cargo.toml — Core crate manifest; defines feature flags (async, subscriptions) and essential dependencies.
• Cargo.toml — Workspace root manifest; coordinates all integration crates (actix, axum, warp, rocket, hyper) and build settings.

Add a new GraphQL scalar type

1. Implement the GraphQLType trait in juniper/src/types/scalars.rs or create a new integration file (juniper/src/types/scalars.rs)
2. Add serialize and from_input_value methods with parsing logic (juniper/src/graphql.rs)
3. Write executor tests to verify coercion and serialization (juniper/src/executor_tests/executor.rs)
4. Document the scalar in book/src/types/scalars.md with usage examples (book/src/types/scalars.md)

Create a new web framework integration

1. Create a new crate directory following juniper_actix or juniper_axum pattern (e.g., juniper_newframework/Cargo.toml) (Cargo.toml)
2. Implement HTTP request handling and GraphQLRequest parsing in the new crate's lib.rs (juniper/src/http/mod.rs)
3. Add middleware/handler that calls executor.execute(query, schema) and returns JSON response (juniper/src/executor/mod.rs)
4. Add integration tests in the new crate's tests/ directory (tests/integration/Cargo.toml)

Extend the schema with a new field resolver pattern

1. Define your field resolver function or method matching the FieldFuture<S> trait (juniper/src/graphql.rs)
2. Register it in a graphql_object! macro or derive(GraphQLObject) struct (juniper_codegen/src/lib.rs)
3. Add executor test cases in juniper/src/executor_tests/ to verify resolution behavior (juniper/src/executor_tests/executor.rs)
4. Document the pattern in book/src/types/objects/complex_fields.md (book/src/types/objects/complex_fields.md)

Add support for a new GraphQL directive

1. Define the directive structure in juniper/src/graphql.rs with name, arguments, and locations (juniper/src/graphql.rs)
2. Implement directive parsing in juniper/src/ast.rs or extend the parser (juniper/src/ast.rs)
3. Add directive handling logic in juniper/src/executor/mod.rs visit methods (juniper/src/executor/mod.rs)
4. Write tests in juniper/src/executor_tests/directives.rs (juniper/src/executor_tests/directives.rs)

• Rust + Type System — Enables compile-time safety for schema definitions; catches type mismatches, missing resolvers, and field name typos before runtime.
• Procedural Macros (derive, graphql_object!) — Reduces boilerplate for schema declaration while maintaining zero-cost abstraction and type safety.
• Async/Await (via tokio, async-trait) — Supports I/O-bound field resolvers (database queries, HTTP calls) without blocking; enables high concurrency.
• Modular Web Framework Integrations — Juniper is framework-agnostic; users choose Actix, Axum, Warp, or Rocket based on their needs; integrations are thin adapters.
• Lookahead & Dataloader Patterns — Prevents N+1 queries; batches field resolver calls to minimize database round-trips.

• No built-in web server; users must integrate with existing frameworks

  • Why: Allows flexibility and avoids adding heavy dependencies; users pick their stack.
  • Consequence: Higher setup friction for beginners; requires understanding of web framework integration patterns.

• Schema defined via Rust types & macros rather than SDL schema files

  • Why: Leverages Rust's type system for compile-time safety and reduces DSL learning curve.
  • Consequence: Schemas are code, not declarative config; some GraphQL tooling (e.g., code generation from .graphql files) less integrated.

• Executor is synchronous in core; async support via Future return types

  • Why: Simplifies executor logic and allows opt-in async; matches Rust's zero-cost abstraction principle.
  • Consequence: Users must understand Future-based concurrency; synchronous code paths may be slower under high concurrency.

• Subscriptions via separate crate (juniper_subscriptions, juniper_graphql_ws)

  • Why: Subscriptions are less common and add complexity; isolating them keeps core lean.
  • Consequence: Subscriptions require separate setup and WebSocket infrastructure; not all frameworks are equally well-supported.

• Does not provide a standalone GraphQL server; integrations required.
• Does not include authentication or authorization middleware (users implement via context).
• Does not handle HTTP routing; assumes web framework provides that.
• Does not support schema

Macro expansion debugging: syn-based procedural macros in juniper_codegen can produce cryptic error messages; use cargo expand to inspect generated code. Feature coordination: Some features (e.g., subscriptions) span multiple crates (juniper_subscriptions + juniper_graphql_ws) and must be enabled together; check Cargo.toml features. Type coercion defaults: Non-null-by-default (Vec<T> → [T!]!) differs from JavaScript GraphQL; surprises users coming from apollo-server. Workspace resolver=1: Cargo workspace uses resolver v1 (see Cargo.toml comment); unifies feature resolution across members, can hide feature incompatibilities. Book examples may lag: Book is marked WIP; code examples in book/src/advanced/ may not match current API.

• Procedural Macros (Derive & Attribute) — Juniper offloads schema definition to compile-time code generation via #[graphql_object] and #[derive(GraphQLType)]; understanding macro expansion is essential to debugging type derivation errors
• GraphQL Introspection — Juniper automatically generates __schema and __type queries to enable self-documenting APIs and tooling (GraphiQL, Playground); critical for client-side tooling integration
• Type Coercion & Non-Null Defaults — Juniper inverts typical GraphQL: Vec<T> → [T!]! (non-null list of non-null items) rather than [T] (nullable); understanding this prevents mismatches with client expectations
• Lookahead Query Planning — Juniper's Lookahead trait (book/src/advanced/lookahead.md) enables resolvers to inspect upcoming query fields and optimize N+1 query problems at resolver time
• Schema Introspection & Code Generation — Juniper compiles type-safe Rust types to GraphQL schema at compile-time, enabling type checking of field resolvers and query validation in your IDE
• Trait-Based Polymorphism (Interfaces & Unions) — Juniper models GraphQL Interfaces and Unions via Rust traits; complex example in tests/integration/src/star_wars.rs shows how to implement polymorphic types
• Async Executors & Futures — Juniper's Executor uses Rust futures for concurrent field resolution; integration crates (juniper_actix, juniper_warp) manage tokio runtime lifecycle

• async-graphql/async-graphql — Competing Rust GraphQL server library with similar type-safe macros but different executor design; common alternative in the Rust ecosystem
• graphql-core/graphql-js — Reference JavaScript GraphQL implementation; Juniper's behavior (e.g., non-null defaults, introspection) models this spec implementation
• apollographql/apollo-server — Industry-standard Node.js GraphQL server; many Juniper users come from Apollo and expect similar API ergonomics
• tokio-rs/tokio — Async runtime that powers Juniper's executor and integration crates (juniper_actix, juniper_warp use tokio directly or via frameworks)
• dtolnay/syn — Procedural macro parsing library; juniper_codegen depends on syn for deriving GraphQL types from Rust code

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive integration tests for juniper_axum web framework integration

The workspace includes juniper_axum as a member crate, but there's no dedicated test directory visible in the file structure for it. Given that other integration frameworks (juniper_rocket, juniper_hyper, juniper_warp, juniper_actix) likely have tests, juniper_axum (a modern async web framework) deserves parity. This would help ensure the Axum integration is robust and maintains compatibility across Juniper versions.

• [ ] Create tests/axum/ directory structure mirroring existing framework test patterns
• [ ] Add unit tests for request/response handling in juniper_axum
• [ ] Add integration tests demonstrating GraphQL query execution through Axum routes
• [ ] Test subscription support if applicable to the Axum integration
• [ ] Add tests for error handling and edge cases specific to Axum's async runtime

Document dataloader patterns with concrete examples in book/src/advanced/dataloader.md

The book structure shows book/src/advanced/dataloader.md exists but the README snippet cuts off mid-sentence and the file itself isn't shown. Dataloader is a critical pattern for solving N+1 query problems in GraphQL. Adding comprehensive, runnable examples would significantly help contributors understand and implement efficient batching patterns in Juniper.

• [ ] Review existing dataloader.md content and identify gaps
• [ ] Add a complete end-to-end example with database queries showing before/after performance
• [ ] Include code examples demonstrating batching with multiple entity types
• [ ] Add troubleshooting section for common dataloader mistakes
• [ ] Link to integration tests in tests/integration/ that demonstrate dataloader usage

Add GraphQL subscription lifecycle tests for juniper_subscriptions and juniper_graphql_ws

The workspace includes both juniper_subscriptions and juniper_graphql_ws crates, which handle real-time features. The file structure doesn't show dedicated tests for subscription connection lifecycle (connect, subscribe, receive updates, disconnect, error handling). This is critical for production-grade GraphQL servers and testing these scenarios prevents regressions.

• [ ] Create tests/subscriptions/ directory for lifecycle integration tests
• [ ] Add tests for WebSocket connection initialization and authentication
• [ ] Add tests for subscription query validation and execution
• [ ] Add tests for graceful disconnection and cleanup
• [ ] Add tests for error scenarios (malformed messages, invalid subscriptions, timeout handling)

• Add tests for Lookahead trait in tests/integration/src/: the book/src/advanced/lookahead.md documents the feature, but there are no dedicated test cases for edge cases like deeply nested lookaheads or null field traversal.
• Expand book/src/schema/subscriptions.md with a complete Actix or Warp example: currently light on runnable code; a full working subscription example in juniper_actix/examples/ or juniper_warp/examples/ and mirrored in the book would improve adoption.
• Document the migration path from juniper_graphql_ws to a newer WebSocket protocol handler in CONTRIBUTING.md: the split between juniper_subscriptions and juniper_graphql_ws is not explained; clarify which is recommended for new projects.

The juniper GraphQL library shows a generally secure foundation as a Rust-based project with strong type safety benefits. However, the security posture is limited by the inability to fully inspect all dependency chains across 12 workspace members from the provided file structure alone. Key recommendations: (1) Implement automated dependency vulnerability scanning with cargo audit and cargo deny; (2) Add a SECURITY.md policy; (3) Audit all workspace members for consistent security practices; (4) Implement query complexity and depth limits for GraphQL operations to prevent DoS attacks; (5) Ensure proper input validation in resolver implementations across all integration modules.

• Medium · Workspace Resolver Configuration — Cargo.toml (workspace root). The workspace uses resolver = '1' which unifies Cargo features asap. While this is intentional per the comment, it could potentially mask feature-flag related security issues if dependencies have conflicting security-relevant features. Fix: Regularly audit dependencies with cargo audit and review feature flag combinations. Document which features are explicitly enabled/disabled for security reasons.
• Low · Multiple Workspace Members Without Visibility Audit — Workspace structure - multiple crates. The workspace contains 12 separate crates/members (juniper, juniper_hyper, juniper_rocket, juniper_subscriptions, juniper_graphql_ws, juniper_warp, juniper_actix, juniper_axum, and test suites). Without inspecting individual Cargo.toml files, it's unclear if all dependencies are pinned or if vulnerable transitive dependencies exist. Fix: Maintain a comprehensive dependency audit across all workspace members. Use cargo deny for automated vulnerability and license compliance checking. Pin critical dependencies to known-good versions.
• Low · Missing Security Policy Documentation — Repository root. No SECURITY.md or security policy visible in the file structure. This makes it difficult for security researchers to report vulnerabilities responsibly. Fix: Create a SECURITY.md file documenting the security reporting process and expected response times, following CNCF guidelines.
• Low · Potential XSS Risk in GraphQL Schema Introspection — juniper/src (execution/introspection logic). GraphQL introspection APIs can expose detailed schema information which could be leveraged for introspection-based attacks if schema descriptions contain user-controlled content without sanitization. Fix: Ensure all schema descriptions and field documentation are properly sanitized. Implement schema introspection query limits to prevent information disclosure attacks.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.