TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: When should I use GraphQL

8 点作者 SadCordDrone12 个月前
Where does it really shine? Can you give an example along with what would be the alternative?

9 条评论

rootshelled12 个月前
GraphQL is good at complex specificity. Leaving it to the caller how it wants its data structured in the return.<p>The struggle with it is more on the provider side. As you&#x27;d have horrible performance if you&#x27;d just rawdog an ORM onto it. The complexity of combining is where you&#x27;ll struggle.<p>Last I played with GraphQL was with PHP. There is exactly one package that did GraphQL at that time. Where we had to define the models both in yaml and php.<p>Though this could probably be solved with dynamic building of the yaml.<p>Also last I checked the testing utils werent there yet.<p>Though it is really cool to be able to do supergraphs if you decide to do microservices.<p>Alternatives are json and protobuf. GraphQL kind of lands between big json blobs and protobuf&#x27;s binary in size. Due to it&#x27;s possible exactness. But that is wholly dependant on implementation.
bnchrch12 个月前
At a quick fly over its useful in situations where:<p>- You value typing<p>- You have many relations and interrelations<p>- You have multiple clients with different needs<p>- Your org has a distinct divide between backend and frontend<p>- You need to stitch together data from many different sources (N microservices powering 1 api)<p>Ive had a lot of success with GraphQL and think the idea of providing an API schema instead of an API interface to be a beautiful addition to a systems design.<p>Also <a href="https:&#x2F;&#x2F;hasura.io" rel="nofollow">https:&#x2F;&#x2F;hasura.io</a> has been a great accelerator when creating POC for products.
评论 #40514043 未加载
moomoo1112 个月前
When you have multiple consumers who need different shapes of the same data, like mobile clients or external consumers.<p>We used it at $lastJob and I thought it was a lot of complexity for what it offered. I had done a analysis of our gql stuff and maybe 20% of the time consumers took advantage of it.<p>Personally I&#x27;d just build a good RESTful API and not cram shit into responses that makes no sense. It isn&#x27;t that hard to batch requests together, and imo I&#x27;d opt for KISS 100 out of 100 times.<p>I haven&#x27;t worked somewhere that took 80%+ advantage of gql. Maybe its only Meta and a handful other capable places that really need gql, IMO.
sandreas12 个月前
As good as REST and GraphQL seemed to me, I personally had much better experiences with RPC - specifically jsonrpc. I did spend a lot of time using protocols like jsonapi[1] and GraphQL in the past, but somehow always came to the conclusion that it is to heavyweight and framework driven.<p>Nowadays, I&#x27;m trying to keep things simple again and use jsonrpc. It&#x27;s simple, versatile, portable and can even be used via WebSockets or raw socket protocols.<p>1: <a href="https:&#x2F;&#x2F;jsonapi.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jsonapi.org&#x2F;</a>
engageintellect12 个月前
When your API becomes large enough where overfetching becomes an issue.
tusharmath12 个月前
Hopefully this sums it up<p><a href="https:&#x2F;&#x2F;blog.tailcall.run&#x2F;graphql-vs-rest-vs-grpc" rel="nofollow">https:&#x2F;&#x2F;blog.tailcall.run&#x2F;graphql-vs-rest-vs-grpc</a>
engageintellect12 个月前
When your API is large enough to where overfetching becomes an issue.
satvikpendem12 个月前
I wrote another comment the other day (<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37125685">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37125685</a>) about how GraphQL has true typing unlike bolted on solutions to REST, and that most people use GraphQL incorrectly then complain about how they&#x27;re running into problems with N+1 and all that. Basically, the way Facebook originally designed it was in combination with Relay and its graph query optimizing compiler that can stitch your entire app&#x27;s query data together so that you never over- or under-fetch, at all. If you just use it like REST, you&#x27;re gonna have a bad time. The comment:<p>GraphQL is very useful, it removes whole classes of bugs. You can even use a Result&#x2F;Either type where if you don&#x27;t handle both the success and error cases, the GraphQL request won&#x27;t even compile, so you can get type safety at both the client and the server while also not having to use purely TypeScript like with tRPC, allowing multiple clients like mobile and web. Pothos does this very well as an error extension [1], where, given the schema:<p><pre><code> type Error { message: String! } type Query { hello(name: String!): QueryHelloResult } union QueryHelloResult = Error | QueryHelloSuccess type QueryHelloSuccess { data: String! } </code></pre> you can then query it with<p><pre><code> query { hello(name: &quot;World&quot;) { __typename ... on Error { message } ... on QueryHelloSuccess { data } } } </code></pre> If you forget `... on Error` the query will simply fail. I should also add that most people use GraphQL incorrectly, to get the benefits of not over&#x2F;underfetching, the Relay approach using fragments is the only viable way currently. Otherwise it&#x27;s not too much better than REST. You define the exact data required for a specific React component in GraphQL fragments, then the Relay compiler will stitch those fragments together into one and only one request. This is a great (if long) overview on the problems Relay solves and why everyone else uses GraphQL incorrectly (then complain that GraphQL sucks) [2]. Hint, Apollo is not the way.<p>[0] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=yab6i9lrEv0" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=yab6i9lrEv0</a><p>[1] <a href="https:&#x2F;&#x2F;pothos-graphql.dev&#x2F;docs&#x2F;plugins&#x2F;errors" rel="nofollow">https:&#x2F;&#x2F;pothos-graphql.dev&#x2F;docs&#x2F;plugins&#x2F;errors</a><p>[2] <a href="https:&#x2F;&#x2F;alan.norbauer.com&#x2F;articles&#x2F;relay-style-graphql" rel="nofollow">https:&#x2F;&#x2F;alan.norbauer.com&#x2F;articles&#x2F;relay-style-graphql</a>
评论 #40506121 未加载
aristofun12 个月前
almost never,<p>when you at the point where your REST looks like a mess - graphql would only make it worse<p>when your REST is still manageable - graphql doesn&#x27;t bring anything radically new or intrinsically valuable to the table<p>Probably the only good fit is when you actually fetching a lot of _graph_ data.