Skip to content

GraphQL PoC: production-readiness improvements (frontend)#8250

Open
galvana wants to merge 1 commit into
graphql-poc-apollofrom
adrian/graphql-poc-improvements
Open

GraphQL PoC: production-readiness improvements (frontend)#8250
galvana wants to merge 1 commit into
graphql-poc-apollofrom
adrian/graphql-poc-improvements

Conversation

@galvana
Copy link
Copy Markdown
Contributor

@galvana galvana commented May 21, 2026

Summary

Production-readiness improvements on top of the GraphQL PoC (#8232), paired with ethyca/fidesplus#3628 (backend).

Changes:

  • Drop @defer directive -- agentBriefing is now a separate DashboardAgentBriefing query
  • Update endpoint URI from /graphql to /api/v1/plus/graphql
  • Scope ApolloProvider inside ProtectedRoute (no Apollo client for unauthenticated pages)
  • Remove custom /graphql rewrite in next.config.js (covered by existing /api/v1/* rule)
  • Regenerate all typed GraphQL documents (no @defer fragments, no @stream directives)

Why drop @defer?

@defer requires graphql-core>=3.3.0a9 on the backend -- an alpha prerelease with no stability guarantees. The separate DashboardAgentBriefing query achieves the same UX: the dashboard paints immediately from DashboardOverview, and the slow LLM-backed briefing arrives independently without blocking. The network cost is one additional small request vs. multipart streaming -- negligible.

Why scope ApolloProvider?

The original PoC wraps the entire app tree (including login pages) in DashboardGraphqlProvider. This creates an Apollo client instance for every visitor before authentication. Moving it inside ProtectedRoute means:

  • No unnecessary client instantiation on login/forgot-password pages
  • The auth token is guaranteed to be available when the client is created
  • Cleaner separation: GraphQL is a Plus feature, not app infrastructure

Research note: is Apollo the right client?

For read-only views with no mutations, Apollo's normalized cache provides little value -- there are no writes to propagate. The complexity tax of cache management (cache.modify, cache.evict, partial cache hits) may not be worth it. Worth evaluating whether RTK Query with a GraphQL fetcher, or TanStack Query, would be simpler for this use case.

Source: TanStack Query vs SWR vs Apollo 2026, Apollo Client Cache docs

Paired backend

ethyca/fidesplus#3628

Test plan

  • Verify npm run dev:mock-graphql renders dashboard with mocked data
  • Verify npm run graphql:generate produces clean types from updated schema
  • Verify agent briefing banner loads independently (separate query, not blocking dashboard paint)
  • Verify login page renders without Apollo client errors in console
  • Verify TypeScript compiles cleanly (npx tsc --noEmit)

🤖 Generated with Claude Code

- Drop @defer; use separate DashboardAgentBriefing query
- Update endpoint to /api/v1/plus/graphql
- Scope ApolloProvider inside ProtectedRoute
- Regenerate types (no @defer fragments)
- Remove custom /graphql rewrite (covered by /api/v1/* rule)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@galvana galvana requested a review from a team as a code owner May 21, 2026 00:06
@galvana galvana requested review from gilluminate and removed request for a team May 21, 2026 00:06
@vercel
Copy link
Copy Markdown
Contributor

vercel Bot commented May 21, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
fides-plus-nightly Ready Ready Preview, Comment May 21, 2026 12:06am
1 Skipped Deployment
Project Deployment Actions Updated (UTC)
fides-privacy-center Ignored Ignored May 21, 2026 12:06am

Request Review

@github-actions
Copy link
Copy Markdown

Dependency Review

✅ No vulnerabilities found.

Scanned Files

  • clients/package-lock.json

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant