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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

REST in Peace. Long Live GraphQL

94 点作者 quincyla将近 8 年前

32 条评论

nemild将近 8 年前
I&#x27;m pretty disappointed by this title.<p>I know that it might be said in fun - and is an easy way to get clicks, but it feeds into the narrative of new, shiny tech. As the article points out at the end, there are very real engineering tradeoffs with GraphQL - and the answer isn&#x27;t as easy as REST is dead, anachronistic technology that no engineer should consider (the XML analogy felt particularly inflammatory).<p>Kelly and I were chatting about GraphQL, and his post might be a more thoughtful engineering post: <a href="http:&#x2F;&#x2F;kellysutton.com&#x2F;2017&#x2F;01&#x2F;02&#x2F;do-we-need-graphql.html" rel="nofollow">http:&#x2F;&#x2F;kellysutton.com&#x2F;2017&#x2F;01&#x2F;02&#x2F;do-we-need-graphql.html</a> (the title - Do we need GraphQL? - is at least the way I&#x27;d expect engineers to approach the problem, where he discusses the tradeoffs)<p>In my MongoDB series, I point out a past case where Free Code Camp fed the hype, by telling engineers that the reason everyone had to learn the MEAN stack was due to employability in the software industry: <a href="https:&#x2F;&#x2F;medium.freecodecamp.org&#x2F;the-real-reason-to-learn-the-mean-stack-employability-29011ff6b2eb" rel="nofollow">https:&#x2F;&#x2F;medium.freecodecamp.org&#x2F;the-real-reason-to-learn-the...</a><p>(you had to dig into the article to realize that their argument was more nuanced, and that they taught SQL first before MongoDB)<p>A number of &quot;engineering&quot; posts are not written as a thoughtful engineer might, and are in many ways marketing for the products sold (like a training program or code camp).
评论 #14840693 未加载
评论 #14840689 未加载
ucho将近 8 年前
<p><pre><code> What is GraphQL? GraphQL is all about data communication </code></pre> Somehow it reminds me of good old &quot;The S stands for Simple&quot;: <a href="http:&#x2F;&#x2F;harmful.cat-v.org&#x2F;software&#x2F;xml&#x2F;soap&#x2F;simple" rel="nofollow">http:&#x2F;&#x2F;harmful.cat-v.org&#x2F;software&#x2F;xml&#x2F;soap&#x2F;simple</a>
评论 #14840048 未加载
andreyf将近 8 年前
The reference implementation of GraphQL has a patent grant identical to React [1].<p>It does not seem wise to use anything with that rider if you have or would like to leave open the possibility of having patents which you license to &#x2F; enforce against Facebook.<p>The argument for patent disarmament strikes me as reasonable, but some companies have novel tech they would like to license to Facebook, and restricting the use of software like this seems a pretty severe violation of the notion of Free Software.<p>1. <a href="https:&#x2F;&#x2F;raw.githubusercontent.com&#x2F;graphql&#x2F;graphql-js&#x2F;master&#x2F;PATENTS" rel="nofollow">https:&#x2F;&#x2F;raw.githubusercontent.com&#x2F;graphql&#x2F;graphql-js&#x2F;master&#x2F;...</a>
评论 #14840443 未加载
theptip将近 8 年前
Anyone got experience transitioning a large production site from REST to GraphQL? I&#x27;m aware Yelp did this recently, wondering about any pain points.<p>In particular, I have some FUD about how to go about rate limiting, when in theory a single request could grab every resource that the client is authorized to retrieve, and thrash the database.<p>Looks like Github counts&#x2F;restricts the number of total nodes returned: <a href="https:&#x2F;&#x2F;developer.github.com&#x2F;v4&#x2F;guides&#x2F;resource-limitations&#x2F;" rel="nofollow">https:&#x2F;&#x2F;developer.github.com&#x2F;v4&#x2F;guides&#x2F;resource-limitations&#x2F;</a><p>Also is there any protection against pathological requests? (e.g. if there are loops in the object graph, can I build an arbitrarily deep GraphQL query that will take an arbitrarily long time to complete?)
评论 #14840163 未加载
评论 #14840239 未加载
评论 #14840517 未加载
评论 #14840173 未加载
评论 #14840175 未加载
merb将近 8 年前
&gt; The need to do multiple round trips to fetch data required by a view: With GraphQL, you can always fetch all the initial data required by a view with a single round-trip to the server.<p>I&#x27;m not sure what&#x27;s different. You can actually implement the same with plain old http api&#x27;s, also.
评论 #14840029 未加载
评论 #14840153 未加载
评论 #14840105 未加载
评论 #14840165 未加载
评论 #14840035 未加载
评论 #14842397 未加载
评论 #14840020 未加载
评论 #14840112 未加载
dperfect将近 8 年前
&gt; When it comes to versioning, GraphQL has an interesting take on that. Versioning can be avoided all together. Basically, we can just add new fields without removing the old ones, because we have a graph and we can flexibly grow the graph by adding more nodes.<p>In my experience, versioning a RESTful API is not hard (much has been written about the various approaches). The cases when versioning <i>does</i> get hard usually correspond to major system architecture changes (e.g., restructuring fundamental relationships between data models), and in those cases, I suspect GraphQL wouldn&#x27;t help a whole lot. You may still need to build some kind of compatibility layer to support older versions.<p>Other than that, adding new fields (which account for 90%+ of the changes to APIs I work on) are just as easy to add to RESTful endpoints. If payload size really does become an issue (it&#x27;s usually negligible), it&#x27;s easy enough to add a parameter or two to control the extent of the response data.<p>As for reducing round trips, I do see the advantage of using GraphQL, though to be fair, well-designed RESTful APIs can avoid excessive round trips as well - they just require a bit more coordination between client and server development (which is a good thing!). RESTful APIs also have the advantage of mutation payloads that <i>look like</i> their corresponding response representations.<p>To address some of the potential concerns with GraphQL (such as resource exhaustion), I believe it would require more development time&#x2F;resources for most of the projects I&#x27;ve worked on - even after factoring in any technical debt brought on by RESTful API limitations.
otto_ortega将近 8 年前
The JSON API specification resolves the 2 major problems people have with REST:<p>The need for multiple round-trips to the server and sparse field-sets (returning only the fields needed):<p><a href="http:&#x2F;&#x2F;jsonapi.org&#x2F;format&#x2F;#fetching-includes" rel="nofollow">http:&#x2F;&#x2F;jsonapi.org&#x2F;format&#x2F;#fetching-includes</a> <a href="http:&#x2F;&#x2F;jsonapi.org&#x2F;format&#x2F;#fetching-sparse-fieldsets" rel="nofollow">http:&#x2F;&#x2F;jsonapi.org&#x2F;format&#x2F;#fetching-sparse-fieldsets</a>
supergeek133将近 8 年前
I always enjoy these absolute &quot;X tech is dead long live tech Y&quot;.<p>Note that earlier the top story on HN was about MSPaint and the top comment said:<p>&gt; &quot;All the comments that &quot;you can just use X to do Y&quot; is missing the point that Paint just works&quot;<p>REST still (and will continue to) just work for most people, I&#x27;m sure some will switch or some will go straight to GraphQL, but lets not just go ahead and declare the whole thing dead. Haha.
baron816将近 8 年前
I tried to build a GraphQL server, but found it impractical since I didn&#x27;t want to use Relay or Apollo on the front end. Formatting the query strings just made a mess and was a lot of trouble considering the simple resources I needed. Dealing with authentication and authorization looked like it was going to be a headache as well. I ended up going back to REST.<p>Should I give it another look? Was I too quick to dismiss it?
评论 #14840245 未加载
评论 #14840789 未加载
评论 #14840206 未加载
评论 #14840188 未加载
jmull将近 8 年前
I guess this makes me sad. Apparently REST has come to mean such a small and specific thing that a REST vs. GraphQL comparison makes sense.<p>There actually shouldn&#x27;t be anything contradictory about choosing the GraphQL interface for a REST API.<p>Also, before anyone jumps in head first on this, keep in mind the downside to things like GraphQL. Your data API is a promise to your clients and GraphQL presents a flexible, unbounded API. This puts a heavy burden on the data service: it&#x27;s going to have to handle all the valid queries <i>and</i> perform well doing it.<p>Further, there are a lot of things that will have an impact on this, such as how&#x2F;where the data is persisted and what the data model is, how the service needs to scale, etc. These will all be impacted by using GraphQL as your data interface. It&#x27;s a lot to commit to, especially if you aren&#x27;t sure how these things will change over time.
评论 #14846790 未加载
bsaul将近 8 年前
Reading all the skeptical comments make me really happy. Maybe it&#x27;s just HN but I&#x27;ve got the feeling the community is starting to be much more &quot;professional&quot; in the sense that it looks for some real benefits before jumping to the brand new shiny tech.<p>Maybe the recent wave of JS framework had at least this beneficial side effect.
sotojuan将近 8 年前
Typical &quot;RIP older tech, long live new trendy tech&quot; blog posts designed to get beginner experts hyped about something they&#x27;ll probably never use.
tomc1985将近 8 年前
<p><pre><code> &quot;who in their right mind would use XML over JSON today?&quot; </code></pre> Lost me already... there are lots of reasons to still use XML today. And since someone is going to ask, here are some:<p>* you want to use xpath<p>* you want to communicate with an enterprise app (salesforce, magento, etc)<p>* you need strongly-typed message-passing in a human-readable well-understood format (rules out messagepack, etc)<p>* nobody actually documented the API, but they might have a WSDL
评论 #14841911 未加载
评论 #14841083 未加载
acukan将近 8 年前
Then to read the planet’s name, we ask: GET - &#x2F;planets&#x2F;1 And to read the films titles, we ask: GET - &#x2F;films&#x2F;1 GET - &#x2F;films&#x2F;2 GET - &#x2F;films&#x2F;3 GET - &#x2F;films&#x2F;6 Once we have all 6 responses from the server, we can combine them to satisfy the data needed by our view.<p>this is stupid there is no need to go multiple rounds?
评论 #14840089 未加载
sixdimensional将近 8 年前
I&#x27;ve often wondered about this example: 1) Relational databases already had network interfaces 2) SQL isn&#x27;t perfect, but it has been reliable for a long time 3) Why we didn&#x27;t increase the performance and security of SQL interfaces, relational databases and just expose those to client applications, including in the browser, directly?<p>Ok, there are a lot of reasons.<p>I worked on a project once that was essentially a &quot;data platform&quot;, kind of a SQL firewall to &quot;any data&quot; (a bit of a stretch, but that was the concept). You could put any data system (relational, non-relational, web services, etc.) behind it, but then join across heterogeneous systems using plain old SQL. You had a query language and a network interface, and since it was separate from the actual databases themselves, you could do some interesting things with security, caching and scalability in a different layer.<p>GraphQL has always seemed like the same kind of query abstraction over data, with a network interface. Props to Facebook for making the tech and releasing it open source.<p>This also makes me think about the command query responsibility separation (CQRS) pattern, a similar discussion.<p>EDIT: Also, lest we forget OData... which never really took off, but offers similar functionality.
评论 #14840874 未加载
评论 #14840629 未加载
lolive将近 8 年前
Basically, GraphQL is a revamping of SPARQL (you know, the W3C language to query RDF databases). FYI, DBPedia is a big big endpoint for these old-school technologies.<p>My question is then: - will there be a &quot;standard&quot; way to describe the data model (aka vocabulary) of your GraphQL endpoint? Something like RDFS or OWL.
评论 #14840276 未加载
daliwali将近 8 年前
There is a lot of FUD from the GraphQL side of this debate, and even overlapping goals with REST. From the article:<p>&gt;With GraphQL, the client speaks a request language which decouples clients from servers. This means we can maintain and improve clients separately from servers.<p>This is actually how the web works right now. Browsers (clients) evolve independently from web pages (servers). Even the author of REST said it is &quot;intended to promote software longevity and independent evolution&quot;. Standards are governed by standards bodies such as IETF, IANA, W3C, WHATWG, etc., not a single corporation like Facebook.<p>I think only time will tell if this is just another fad that took off but didn&#x27;t age well, like SOAP.
评论 #14841858 未加载
maaaats将近 8 年前
Compared to a by-the-book REST-api, GraphQL is more powerful. But we always end up making specialized endpoints anyway.
infinitone将近 8 年前
The article starts with: &gt; With GraphQL, the client speaks a request language which: 1) eliminates the need for the server to hardcode the shape or size of the data<p>And then ends with: &gt; There are some mitigations we can do here. We can do cost analysis on the query in advance and enforce some kind of limits on the amount of data one can consume.<p>... so basically you did nothing in the way of perf but add complexity.
ergo14将近 8 年前
How do people solve performance problems with GraphQL?<p>I can imagine that it can be quite slow internally with multiple joins&#x2F;subqueries in the datastore.
评论 #14840370 未加载
randallsquared将近 8 年前
As your REST API grows, you will often want to implement search endpoints, and allow queries using fields you&#x27;ve defined. GraphQL is just the search endpoint for your REST API, if you need to allow so much flexibility that implementing it all would be troublesome.
bkovacev将近 8 年前
Not sure what you&#x27;re using for your api framework, but you can definitely fetch only particular fields on your get requests with Django Rest Framework.<p>Also, you can definitely version nicely. You just have to document it well. If you&#x27;re supporting different api version in you&#x27;re bound to add more code, not sure what that argument is about, since I assume (could be wrong) you&#x27;d have to define a new schema and add new logic to handle the queries in the translating layer, correct?<p>Also, the author makes a bold title and then goes ahead and mellows it in the first few paragraphs. Stick to it or don&#x27;t do it at all.
brianllamar将近 8 年前
REST is certainly not dying anytime soon, GraphQL is just solving the data fetching problem in a different way. My intro to GraphQL came from researching GitHub&#x27;s move towards it. For those interested, I chatted in detail with API manager there on my podcast. Transcription is also available for those who want to skim. <a href="https:&#x2F;&#x2F;www.heavybit.com&#x2F;library&#x2F;podcasts&#x2F;jamstack-radio&#x2F;ep-5-graphql-at-github&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.heavybit.com&#x2F;library&#x2F;podcasts&#x2F;jamstack-radio&#x2F;ep-...</a>
Ciantic将近 8 年前
GraphQL needs a good server side library. But for e.g. C# I&#x27;ve found only libraries that can&#x27;t be called stable. With stability I also mean who is developing and maintaining the code? If it&#x27;s just one person effort it can&#x27;t be called stable. I have understood it&#x27;s much better in Java side, so perhaps if you can start your backend with Java&#x2F;kotlin&#x2F;Scala you are good to go.
baby_wipe将近 8 年前
If I understand GraphQL correctly, it sounds like I will be re-writing queries multiple times across different clients (android&#x2F;ios&#x2F;web). For the majority of (simple) read operations this doesn&#x27;t seem like such a big deal. But for write operations, wouldn&#x27;t this mean having business logic repeated across clients? If so, I don&#x27;t like that.
luord将近 8 年前
I&#x27;ll keep creating plain REST APIs for the time being. I haven&#x27;t really faced any of the issues mentioned. Or at least they haven&#x27;t impacted development time for me in a meaningful way.<p>If a client requires a GraphQL API, I&#x27;ll happily learn. It does look like an interesting technology and a valid alternative.
swlkr将近 8 年前
I do like the idea of GraphQL, but even with it&#x27;s problems, REST can be much simpler to understand&#x2F;use <a href="https:&#x2F;&#x2F;www.slideshare.net&#x2F;landlessness&#x2F;teach-a-dog-to-rest" rel="nofollow">https:&#x2F;&#x2F;www.slideshare.net&#x2F;landlessness&#x2F;teach-a-dog-to-rest</a>
vinceguidry将近 8 年前
Why not just expose SQL? Only half kidding. I mean, you can set permissions and everything.
borplk将近 8 年前
I am yet to see a proper easy production-ready GraphQL setup.<p>Lots of &quot;hello world&quot; stuff out there.<p>Throw in the requirements of a real SaaS and everyone shrugs.
davewritescode将近 8 年前
GraphQL only solves half the problem, how do you update resources with GraphQL?
评论 #14840379 未加载
评论 #14840430 未加载
评论 #14840331 未加载
Dowwie将近 8 年前
Playful title, but not to be taken literally
评论 #14840243 未加载
owebmaster将近 8 年前
GraphQL is vaporware. React&#x27;s success took over Facebook Engineering&#x27;s mindset.