7 ms·
Where in the HypeCycle is GraphQL?
- robertlagrant 5y agoStackOverflow questions don't get answered at the same rate because all the common questions are answered already and closed as dupes.
- esens 5y agoReact, Kubernetes both show the big drop at the end of 2020. Strange.
- deleted 5y ago[deleted]
- deleted 5y ago[deleted]
- Zababa 5y agoInteresting, but maybe comparing it to REST would paint a better picture?
- lolive 5y agoREST != GraphQL
- hn_throwaway_99 5y agoThat's the whole point, GraphQL is an alternative framework for composing APIs, so comparing it to REST makes sense.
- deleted 5y ago[deleted]
- Cthulhu_ 5y agoYeah we know they're not the same, can you explain what you mean by that? REST and GraphQL try to solve the same problem.
- lolive 5y agoI would say data oriented vs service oriented. But basically, the question comes down to where the DAO is. And what contracts are exposed Sounds to me like important questions, as a data engineer.
- JohnHaugeland 5y agorest attempts to solve interface normalization between services graphql attempts to solve query normalization over a single api they're as related as a vcr and a broadcast system - the problems they solve are adjacent, but do not overlap, and whereas their default sensible use is together, they can both be used without the other, or with alternatives to the other
- hn_throwaway_99 5y ago> the problems they solve are adjacent, but do not overlap I think this is just factually wrong. I've experienced many situations where exposing a GraphQL API, even when just intended to be called by another service, provided a number of advantages over a "plain REST" service, so we went with GraphQL, and I have seen other companies do the same. GitHub, for example, has a set of FAQs of "migrating from our REST APIs to our GraphQL APIs".
- throw_m239339 5y agoI disagree. But it depends on your own definition of REST, which according to its "creator" is HATEOAS. GraphQL certainly is not HATOAS. REST is a philosophy while GraphQL is a spec. There is no "REST spec", HTTP isn't REST.
- Zababa 5y agoBy "REST" I meant the way it's mostly used, so "REST API" to mean "HTTP API with maybe a notion of resources", since REST is the term people use to talk about these things.
- Zababa 5y agoYou're right, but I proposed that to get an idea on how big is GraphQL compared to other things present in the same space. GraphQL doesn't replace REST and they can leave together, but still, if there are as many searches/results for GraphQL than for REST, or 10 times more, or 10 times less, it would say a bit more about its position. Edit: someone posted a comparative google trend in the thread: https://trends.google.com/trends/explore?date=all&q=REST,GraphQL,RPC https://trends.google.com/trends/explore?date=all&q=REST,Gra.... That's the type of info I expected.
- mulmboy 5y agoThe trendlines made me physically recoil. Please, just leave them out if they're useless.
- dkersten 5y agoThey might be useful if they were exponential moving averages or something that adjusted more quikcly, so that you can see the trend shift. But in this case, you can clearly see the trend shift from the actual data anyway, so even that wouldn't really add anything.
- AznHisoka 5y agoStackoverflow mentions + Github repos created are both very imperfect proxies. Also, never show cumulative stats in a graph - it almost always go up and to the right: not insightful at all. A much better proxy is the % of job openings/companies that mention GraphQL in a job opening: https://pasteboard.co/KaZ2ko0.png https://pasteboard.co/KaZ2ko0.png Both have increased from 0.8% to 1.4% YoY, and the demand for GraphQL skills have kept increasing for more than 2 years.
- aunty_helen 5y agoThe problem with those metrics is they are laggy so may not show the trends being enacted today until a future date. The 0.8 -> 1.4 may be a result of the hype cycle peaking, companies adopting a new tech, using it enough they need to hire people with it. Or potentially now, companies not adopting this new tech with such a great rate because the hype cycle is over, graphql doesn’t get included in new projects, there’s no reason to hire someone for it in 6 months time.
- dgrin91 5y ago> Also, never show cumulative stats in a graph - it almost always go up and to the right: not insightful at all. I mean thats the definition of a cumulative graph... it basically has to go up and right. But thats ok. You can look at the slope of the cumulative graph to tell if its gaining steam or not. For example you can clearly see that the cumulative views on StackOverflow is flattening out, but the HN mentions is approximately a slope of 1
- lolinder 5y agoBut if all you're interested in is the slope and the second derivative (which seems to be the case here), why not just graph the slope? With a cumulative graph, reading the slope is hard and reading the second derivative is even more difficult. The only reason I can see to use a cumulative graph is if the total is actually what's interesting (for example, total covid vaccinations in arms over time). The total seems largely irrelevant in a discussion of hype cycles.
- afavour 5y agoOne immediate reaction: this data isn’t adjusted for overall numbers. Yes, the number of GraphQL mentions on Hacker News varied, but how did it vary compared to the overall number of comments on the site? Same with SO questions and GitHub repos. Without controlling for that you might just be looking at the normal ebb and flow of site traffic throughout a year. In fact you see it in the SO data, where both GraphQL and Kubernetes take a dive at the end of 2020. I’ll bet overall site traffic was down as people left for holidays, focused on end of year reviews, etc etc.
- cj 5y agoPerhaps a simpler way to control would be comparing the trend to the trend of nginx/apache or some other similarly widely used mature tech.
- afavour 5y agoThe post mentions all the data come from BigQuery so it should be relatively simple to get an overall row count. I'm not clued in enough on BigQuery pricing to know whether it would suddenly make the query uber-expensive, though.
- Cthulhu_ 5y agoOr compared with similar technologies. Here's a very naive comparison between GraphQL, REST and RPC: https://trends.google.com/trends/explore?date=all&geo=NL&q=REST,GraphQL,RPC https://trends.google.com/trends/explore?date=all&geo=NL&q=R... They all seem pretty stable, although REST and RPC switched places in the mid-2000's
- Scarblac 5y agoBut "rest" is also an unrelated English word, is that taken into account somehow?
- true_religion 5y agoUsing the more specific scopes, it looks like REST is only gaining in popularity. https://trends.google.com/trends/explore?date=2005-06-13%202021-07-13&geo=NL&q=%2Fm%2F03nsxd,%2Fg%2F11cn3w0w9t,RPC https://trends.google.com/trends/explore?date=2005-06-13%202...
- tyingq 5y agoI've only had a little experience with GraphQL, but I'm finding it frustrating because designers of the APIs tend to normalize structures since the backend is often a relational (or graph) database. For example, rather than having top level "admin contact email" and "business contact email", API designers will have a sub graph of contacts, with label->email. (Note that this is the trivial example, it gets much worse) Most of the time, I need a flattened version to actually do the work. Now, with SQL, that's not an issue because I can put a query together that flattens/joins as needed. But, with a GraphQL result withs lots of edges and nodes, I can't do that simply. I have to write some bespoke recursive walker to pull the data back up. I understand I could fix this with the schema, but these aren't my APIs, I'm just a consumer. There doesn't seem to be some universally supported way to do the equivalent of a join. Or, more simply, the culture around REST/JSON seems to prefer flatter structures, but the GraphQL crowd tends to like more nested structures...even when it's not really needed. Edit: Also, it's not so simple to make a universal, declarative-driven "flattener", as the nested structures vary pretty wildly in how they are done.
- ericwooley 5y agoI never got the edges and nodes thing, and every time I have worked with a graphql endpoint that did, I was indeed very annoyed. Feels like something that came with a graph database, and people tried to blindly copy it. Graphql code generator is great though. Absolutely wonderful. Makes it really hard to go back to rest.
- hirundo 5y agoWe left out edges and nodes from our GraphQL API because of how confusing they are. But the downside is that we had to add a <collection>Stats object for each collection type to support meta data like the count. Still it seems to be easier this way for non-developers to learn. And the API consumers are mostly not developers, like account managers and accountants, usually via GraphiQL.
- dustymcp 5y agoever tried swagger and nswag for client generation in rest it does the same thing but requires abit of a wire
- christkv 5y agoWe found a normal http api with the ability to do projection on the returned JSON covered most our needs.
- hnmullany 5y agoAnother data point - user traffic to graphql.org has been flat since mid-2020 - at least according to Semrush - at about 250k visits per month. So it's a tech that people are using, but it seems to have saturated its use case.
- vyrotek 5y agoWe bought into the GraphQL vision on past projects but I came out the other end never wanting to work with it again. So much effort is put into trying to make "one API to rule them all". The shape of that API will always have inefficiencies, waste, and misaligned expectations about the data. If you control the client the server then most likely your client has a function wanting data so just call a function on the server to provide it. A generic http-based abstraction in the middle isn't always the right answer. Our most recent project is a SPA making RPC calls with a BFF* architecture. We couldn't be happier. * https://samnewman.io/patterns/architectural/bff/ https://samnewman.io/patterns/architectural/bff/
- weeboid 5y agoThat conclusions section … publisher may want to reconsider whether this damages their brand. I certainly view this article as BS
- jensneuse 5y agoI would love to hear your feedback in a more actionable way.