Hacker News Reader

Comment by thinkingkong | Hacker News Reader

4 years later and Id argue graphql is the clear market winner. Whether or not you really need it is debatable but its fashionable. Schema driven development and types have also been adopted along side that system so they sort of fit well together, too.

View on HN

I have almost never encountered GraphQL in production, including when inspecting other sites. I think it's still a pretty small niche and mostly used on newer projects.

Same for me. I will add to this that probably very few know how to implement GraphQL on the server-side *efficiently*, or, put differently, most have a gut feeling about how hard to manage it can become.

While frontend implementations look good, GraphQL sure looks like an unsolved problem on the server to me.

I don't use it only because people at other companies demand REST.

I was going to comment something similar to this. We integrate with a lot of APIs every day and graphql we have never encountered. It seems, for now, to be a HN distortion field that it is 'a clear market winner'? It seems not only to be used on newer projects but at a specific type of startup projects. Looking at HN launches which have an API recently, it seems hardly used at all yet.

The problem being that not many people seem to know how to implement it server side, while REST is trivial.

> while REST is trivial.

I'm not convinced of this -- or at least, we might use different definitions of "REST".

The guy who created the concept of REST regularly (or used to regularly) call out common problems with "REST" APIs that make them more like RPC APIs that happened to be built on top of HTTP. For instance, [0].

Now, just because someone created a thing doesn't mean they had it right from the get-go. (For instance, the guy who named "gif" clearly pronounces it wrong.) But I've become convinced by Roy's points about what REST ought to be, and if "REST" is going to be meaningfully distinguished from "RPC", it's probably worth understanding his position.

[0] https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...

I see your point and yes, you are right. I probably would have to say that 'what people gobble together and call REST is easy to implement' and sidestep the problem that it has a lot of issues. Or maybe just that it is far easier than graphql to bolt on server-side. But yes, I agree with your comment.

Yes, sorry to pick on you specifically for that ;)

In my admittedly limited experience, GraphQL is easier to get right than true REST, but obviously somewhat harder than a slapped-togther RPC API. I also like GraphQL better because if your domain fits it, it's really easy to use a GraphQL schema as a limited kind of domain model in its own right. And you can factor that schema (as well as describe proposed patches to it) with `extend type`, not unlike C#'s `partial class`.

I am quite enthusiastic about grapql, but the teams at my clients just stare at me like I am crazy and then go back to work. Basically everyone would rather do create /api/userswithgroupsandaclsandinvoices next to /api/users than look for other options. It's just so quick & easy to do that instead of look at other tech. I guess in companies beyond a 2 people startup team, the persons having to use the API and the persons creating it are different groups and they both are doing what is easy for them and their team. I think we would need to see a lot more server implementation and benefit tutorials for grapql to fix that issue.

In the case of most of our partners and clients for instance, the API users are other companies in the same vertical; not only do the API teams not care a lot about the usage as long as it works; spending time doing something 'fashionable in the cutting edge dev world' might be nice, but no-one in their vertical will use it. They will simply ask for the 'normal API' instead.

It's definitely hard to argue against something so easy, right? At the same time, it's often really hard for people to grasp that a solution now might have repercussions later -- and even if they do, maybe they won't be around to worry about the repercussions anyway.

And if there won't be repercussions -- maybe the product is short-lived, maybe they're okay with forcing clients to upgrade every X months, maybe they rewrite the backend software regularly so cruft can't accumulate so easily -- are they wrong?

GraphQL can't tell you what your problems are. I agree that there could be more resources out there, but as software engineers, we have to wrangle with the specific problem domain we're being asked to solve, and decide what the core issues are and how to tackle them. Nobody outside your team can do that for you (and I count consultants as being on your team, even if temporarily).

> And if there won't be repercussions -- maybe the product is short-lived

Unfortunately the API's I work with are long-lived; decades. Many (but not close to most luckily) integrations are SOAP for instance. With API versioning and 'hidden' APIs (API's which are not in their normal Swagger or docs, but do exist to fix), issues like returning too much or too little is resolved, and it's fast & easy.

I don't know much about GraphQL, but my instinctive reaction to it is that it seems like it has a lot of hidden consequences that I would not be able to predict in advance. For example, from what I've seen it seems like it would be easy to write queries with exponentially large responses, and that just seems dangerous to expose in an API.

REST is trivial only when it's RPC by another name.

Counter-anecdote: the last two places I've worked at have adopted GraphQL in production, and are happier for it.

I didn't intend to imply that GraphQL is better or worse than REST-ish APIs. I just haven't seen it catch on anywhere outside of Facebook.

I have integrated many dozens of APIs into backends by now, and never have I even had an option to use GraphQL if I wanted to.

FWIW, my team has adopted GraphQL because it fits our domain needs better in a few ways. Our product is org-internal, so that might play into the choice a little bit.

I guess clear market winner depends on what one defines as market.

Anecdotally though, I have been working with medium sized startups in NYC that are heavily API driven for the last several years, and I haven't seen graphQL in production once. Not at my companies, nor in any external API we have interfaced with.

I will even go a step farther and day that I cannot recall a single time that another of the several dozens of devs or managers I have worked with has even mentioned the idea of using it.

I can only assume the market OP is referring to is a very specific one. I could make a guess or two, but wouldn't want to ruin the reader's enjoyment from doing the same.

Reply on news.ycombinator.com