前端GraphQL客户端:优雅地获取数据

前端GraphQL客户端:优雅地获取数据

毒舌时刻

前端GraphQL?这不是后端的事吗?

"REST API就够了,为什么要用GraphQL"——结果前端需要多次请求,数据冗余,
"GraphQL太复杂了,我学不会"——结果错过了更灵活的数据获取方式,
"我直接用fetch请求GraphQL,多简单"——结果缺少缓存、错误处理等功能。

醒醒吧,GraphQL不是后端的专利,前端也需要专业的客户端工具!

为什么你需要这个?

  • 减少网络请求:一次请求获取所有需要的数据
  • 数据精确:只获取需要的数据,避免冗余
  • 类型安全:自动生成TypeScript类型
  • 缓存优化:智能缓存,减少重复请求
  • 开发效率:简化数据获取逻辑

反面教材

// 反面教材:直接使用fetch请求GraphQL async function fetchGraphQL(query, variables) { const response = await fetch('https://api.example.com/graphql', { method: 'POST', headers: { 'Content-Type': 'application/json', }, body: JSON.stringify({ query, variables }), }); const data = await response.json(); if (data.errors) { console.error('GraphQL errors:', data.errors); throw new Error('GraphQL request failed'); } return data.data; } // 反面教材:重复请求相同数据 async function loadUserAndPosts() { // 第一次请求用户信息 const { user } = await fetchGraphQL(` query GetUser($id: ID!) { user(id: $id) { id name email } } `, { id: 1 }); // 第二次请求用户的帖子 const { user: userWithPosts } = await fetchGraphQL(` query GetUserWithPosts($id: ID!) { user(id: $id) { id posts { id title content } } } `, { id: 1 }); return { user, posts: userWithPosts.posts }; } 

正确的做法

// 正确的做法:使用Apollo Client import { ApolloClient, InMemoryCache, gql } from '@apollo/client'; // 创建Apollo Client实例 const client = new ApolloClient({ uri: 'https://api.example.com/graphql', cache: new InMemoryCache(), headers: { authorization: localStorage.getItem('token') || '' } }); // 定义查询 const GET_USER_WITH_POSTS = gql` query GetUserWithPosts($id: ID!) { user(id: $id) { id name email posts { id title content createdAt } } } `; // 定义变更 const CREATE_POST = gql` mutation CreatePost($input: PostInput!) { createPost(input: $input) { id title content createdAt } } `; // 在React组件中使用 import React from 'react'; import { useQuery, useMutation } from '@apollo/client'; function UserProfile({ userId }) { // 使用useQuery钩子获取数据 const { loading, error, data, refetch } = useQuery(GET_USER_WITH_POSTS, { variables: { id: userId }, // 缓存策略 fetchPolicy: 'cache-and-network' }); // 使用useMutation钩子执行变更 const [createPost, { loading: creating }] = useMutation(CREATE_POST, { // 变更后更新缓存 update(cache, { data: { createPost } }) { const { user } = cache.readQuery({ query: GET_USER_WITH_POSTS, variables: { id: userId } }); cache.writeQuery({ query: GET_USER_WITH_POSTS, variables: { id: userId }, data: { user: { ...user, posts: [...user.posts, createPost] } } }); } }); if (loading) return <div>加载中...</div>; if (error) return <div>错误:{error.message}</div>; const handleCreatePost = async (title, content) => { await createPost({ variables: { input: { title, content, userId } } }); }; return ( <div> <h2>{data.user.name}</h2> <p>{data.user.email}</p> <h3>帖子</h3> <ul> {data.user.posts.map(post => ( <li key={post.id}> <h4>{post.title}</h4> <p>{post.content}</p> <p>{post.createdAt}</p> </li> ))} </ul> <button onClick={() => refetch()}>刷新</button> <button onClick={() => handleCreatePost('新帖子', '帖子内容')} disabled={creating} > {creating ? '创建中...' : '创建帖子'} </button> </div> ); } // 正确的做法:使用URQL import { createClient, gql } from 'urql'; // 创建URQL客户端 const client = createClient({ url: 'https://api.example.com/graphql', fetchOptions: () => ({ headers: { authorization: localStorage.getItem('token') || '' } }) }); // 在React组件中使用 import React from 'react'; import { useQuery, useMutation } from 'urql'; function UserList() { const [result, reexecuteQuery] = useQuery({ query: gql` query GetUsers { users { id name email } } ` }); const { data, fetching, error } = result; if (fetching) return <div>加载中...</div>; if (error) return <div>错误:{error.message}</div>; return ( <div> <h2>用户列表</h2> <ul> {data.users.map(user => ( <li key={user.id}> {user.name} - {user.email} </li> ))} </ul> <button onClick={() => reexecuteQuery()}>刷新</button> </div> ); } // 正确的做法:使用Relay import { Environment, Network, RecordSource, Store, useLazyLoadQuery, graphql } from 'relay-runtime'; // 创建Relay环境 function fetchQuery(operation, variables) { return fetch('https://api.example.com/graphql', { method: 'POST', headers: { 'Content-Type': 'application/json', authorization: localStorage.getItem('token') || '' }, body: JSON.stringify({ query: operation.text, variables, }), }).then(response => { return response.json(); }); } const environment = new Environment({ network: Network.create(fetchQuery), store: new Store(new RecordSource()), }); // 定义查询 const UserQuery = graphql` query UserQuery($id: ID!) { user(id: $id) { id name email posts { edges { node { id title content } } } } } `; // 在React组件中使用 function UserDetail({ userId }) { const data = useLazyLoadQuery( UserQuery, { id: userId } ); return ( <div> <h2>{data.user.name}</h2> <p>{data.user.email}</p> <h3>帖子</h3> <ul> {data.user.posts.edges.map(edge => ( <li key={edge.node.id}> <h4>{edge.node.title}</h4> <p>{edge.node.content}</p> </li> ))} </ul> </div> ); } 

毒舌点评

看看,这才叫前端GraphQL客户端!不是简单地使用fetch请求,而是使用Apollo Client、URQL或Relay等专业的客户端工具。

记住,GraphQL客户端不仅仅是发送请求,还包括缓存管理、错误处理、类型生成等功能。这些工具可以大大简化你的前端代码,提高开发效率。

所以,别再觉得GraphQL复杂了,使用专业的客户端工具,让数据获取变得更加优雅!

总结

  • Apollo Client:功能强大,生态丰富,适合大型应用
  • URQL:轻量级,API简洁,适合中小型应用
  • Relay:Facebook开发,性能优异,适合大型应用
  • 缓存管理:智能缓存,减少重复请求
  • 类型安全:自动生成TypeScript类型
  • 错误处理:统一的错误处理机制
  • 变更管理:执行GraphQL变更并更新缓存
  • 开发工具:GraphQL Playground、Apollo DevTools等

前端GraphQL客户端,让数据获取变得更加优雅!

Read more

美团前端要转全栈?后端可能要失眠了,别笑话前端了,你们的饭碗也要被抢了

说个真实的事。 我现在的公司,没有产品经理,没有UI设计师,没有前端工程师。 只有全栈。 每个人配一套AI工具链,一个人干完以前整个小组的活。 一人顶十人,不是夸张,是正在发生的现实。 你可能觉得这是个例。 不是。 美团履约团队已经开始要求前端转全栈了。 注意,不是转Node,是转Java。 老员工必须转,新员工只招全栈。 菜鸟国际更狠,直接让后端去写前端和测试。 大厂是风向标。 美团、阿里动了,中小公司马上就会跟进。 为什么会这样? 因为AI把“沟通成本”这个遮羞布扯掉了。 以前前后端分离,看起来是技术架构的进步。 实际上呢? 接口扯皮能扯一天,联调能调一周,一个需求三个人传话,信息损耗巨大。 老板们以前忍了,因为没办法。 现在AI来了,代码生成效率提升了10倍不止。 老板们突然发现:最贵的不是写代码的时间,是人和人之间的沟通成本。 一个会用AI的全栈,从需求到上线一个人搞定。 不用开会,不用对接口,不用等联调。 你说老板选谁? 纯前端和纯后端,

我用Claude Code + GLM4.7修前端Bug的翻车现场,1小时烧光5小时限额

本来想体验一把“vibe coding 省时间”,结果变成“vibe coding 省不了、还很贵”:折腾将近一小时,GLM 额度直接打满,Bug 还在。 背景:事情是怎么开始的 最近遇到一个前端 Bug,属于那种看起来不大、但很烦的类型:页面运行时报错,提示动态导入某个模块失败(报错里能看到类似 Failed to fetch dynamically imported module .../router/index.ts 这种信息)。 我想着正好试试工具链:Claude Code + GLM4.7。理想情况是:它读代码、跑命令、给修改方案,我负责点确认就行。 现实是另一回事。 结果:时间花了,额度没了,Bug 还没修好 简单总结一下这次的“

【web小工具】dirsearch 安装,用法,例题

原文链接:21.dirsearch:Web 路径扫描工具-ZEEKLOG博客 有错误请各位大佬多多指教~~~ 一、项目介绍 dirsearch 是一款高效、多线程的 Web 路径扫描工具,专为渗透测试人员和网络安全研究人员设计,用于发现目标网站的隐藏目录、敏感文件及未授权接口。其支持自定义字典、代理配置、请求头伪装等功能,适用于红队渗透、漏洞挖掘及资产测绘等场景。 1.1 核心功能 多线程扫描:默认 20 线程,可自定义调整以提高效率。 智能错误处理:自动过滤重复状态码(如 404),降低误报率。 灵活扩展支持: 支持自定义字典(如 -w 指定字典文件)。 支持多种扩展名扫描(如 -e php,asp,aspx)。 结果输出:生成可读性强的报告(TXT/JSON/CSV)

Cursor 3来了:内置Codex,前端福音Design Mode,WorkTree多开

Cursor 3来了:内置Codex,前端福音Design Mode,WorkTree多开

Cursor 3来了:内置Codex,前端福音Design Mode,WorkTree多开 用Cursor这种编辑器,经常遇到两个小痛点:一是他就一个聊天框,如果一个任务时间长一点,侧边栏就被占用,就没法干别的;二是害怕 Agent “一顿操作猛如虎”,直接把当前的主干分支改坏。 刚刚发布的 Cursor 3,重点就在解决这类工作流层面的问题。总体来看,它好像不太满足于做一个带对话窗的编辑器,而是在加强多任务并行和代码环境的安全隔离。 具体有三个最直接影响日常开发的新特性: 1. Agents Window:跑并行的任务控制台 快捷键:Cmd+Shift+P 输入 Agents Window 以前的对话基本是一个单向的线性流。Cursor 3 将 Agent 抽离出了独立的面板区,你可以跨仓库、跨环境(本地、云端或远程 SSH)同时运行多个任务。 配合新增的 Agent Tabs,