4 ms·

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

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.

smt88 5y ago
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.
- xcambar 5y ago
  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.
  - smt88 5y ago
    I don't use it only because people at other companies demand REST.
- tluyben2 5y ago
  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.
  - Twisol 5y ago
    > 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-hypertext-driven https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...
    - tluyben2 5y ago
      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.
      - Twisol 5y ago
        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`.
        tluyben2 5y ago
        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.
- occz 5y ago
  Counter-anecdote: the last two places I've worked at have adopted GraphQL in production, and are happier for it.
  - smt88 5y ago
    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.
- Twisol 5y ago
  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.
- randomdude402 5y ago
  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.

smt88 5y ago

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.

xcambar 5y ago
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.
- smt88 5y ago
  I don't use it only because people at other companies demand REST.
tluyben2 5y ago
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.
- Twisol 5y ago
  > 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-hypertext-driven https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...
  - tluyben2 5y ago
    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.
    - Twisol 5y ago
      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`.
      - tluyben2 5y ago
        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.
occz 5y ago
Counter-anecdote: the last two places I've worked at have adopted GraphQL in production, and are happier for it.
- smt88 5y ago
  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.
Twisol 5y ago
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.
randomdude402 5y ago
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.