4 ms·

No one in their right mind would ever choose to implement GraphQL rather than a REST api. The complexity difference is just too great. Maybe have your primary A

No one in their right mind would ever choose to implement GraphQL rather than a REST api. The complexity difference is just too great. Maybe have your primary API as REST then as some kind of janky caching thing use GraphQL. The only experience I have had calling GraphQL came from github and it was not great. The API was responsive but when I was trying to figure out syntax I was longing for a much clearer REST end point that would give me the data I was after.

LewisJEllis 8y ago
Okay, I'll bite. Rather than simply shitting on a technology that thousands of developers actually like and have used to positive effect, and stating that none of those thousands of developers are "in their right mind", could you share some of your specific experiences and insights so people can understand why you hold the position you're sharing? What experiences have you had implementing GraphQL APIs, and what specific complexity differences did you observe? What experiences have you had in maintaining living REST APIs used by evolving frontend clients, while balancing backwards compatibility concerns for supporting older clients? How has this compared to doing the same with a GraphQL API? What experiences have you had in developing front-end web and/or mobile applications that consume a GraphQL API? How has that compared to consuming a REST API? Have you invested any time in learning the GraphQL syntax and understanding the goals and intentions of the project, or did you just use it that one time with GitHub's API and get a bad taste because it was unfamiliar? I will admit that for APIs provided for 3rd-party public consumption (like GitHub's), GraphQL is not as much of a natural fit for consumers (where, as long as GraphQL is not widely understood, it may just be a "figure out syntax" obstacle) as it can be for in-house APIs consumed by 1st-party front-end applications that utilize tooling built around GraphQL as an advantage. Nonetheless, I would be hesitant to advocate for REST over GraphQL in all cases (as you have) just because I had a bad experience consuming an API that used GraphQL when I was unfamiliar with it. I'm a backend engineer and I maintain a living GraphQL API consumed by web and mobile engineers on my team. I also helped in our migration from REST to GraphQL, and it's been an overall positive experience for me and the rest of my team. If you stand by your statement that I am out of my mind, I hope you have some relevant experience that you can share to back it up. I doubt you do - your comment comes across more as vague new-paradigm-hate than as experience-based wisdom - but I would be happy to be wrong.
zachrip 8y ago
I use it everyday and love it. I write both sides of it and it's paradise compared to working with rest. I'd pick my stack again any day: typescript, react, react-apollo, graphql-tools, apollo-express. I'm able to move so damn fast, it's a breath of fresh air.
- dopeboy 8y ago
  Curious about your stack - what's your backend in and what GraphQL provider do you use?
  - zachrip 8y ago
    The stack is already listed in the first comment but it's Apollo on the front and backend. Typescript on both sides as well. Interfaces a MySQL DB and various grpc services.
    - dopeboy 8y ago
      Ah ok, I thought Apollo was only a frontend client. My mistake.

LewisJEllis 8y ago

Okay, I'll bite. Rather than simply shitting on a technology that thousands of developers actually like and have used to positive effect, and stating that none of those thousands of developers are "in their right mind", could you share some of your specific experiences and insights so people can understand why you hold the position you're sharing? What experiences have you had implementing GraphQL APIs, and what specific complexity differences did you observe? What experiences have you had in maintaining living REST APIs used by evolving frontend clients, while balancing backwards compatibility concerns for supporting older clients? How has this compared to doing the same with a GraphQL API? What experiences have you had in developing front-end web and/or mobile applications that consume a GraphQL API? How has that compared to consuming a REST API? Have you invested any time in learning the GraphQL syntax and understanding the goals and intentions of the project, or did you just use it that one time with GitHub's API and get a bad taste because it was unfamiliar? I will admit that for APIs provided for 3rd-party public consumption (like GitHub's), GraphQL is not as much of a natural fit for consumers (where, as long as GraphQL is not widely understood, it may just be a "figure out syntax" obstacle) as it can be for in-house APIs consumed by 1st-party front-end applications that utilize tooling built around GraphQL as an advantage. Nonetheless, I would be hesitant to advocate for REST over GraphQL in all cases (as you have) just because I had a bad experience consuming an API that used GraphQL when I was unfamiliar with it. I'm a backend engineer and I maintain a living GraphQL API consumed by web and mobile engineers on my team. I also helped in our migration from REST to GraphQL, and it's been an overall positive experience for me and the rest of my team. If you stand by your statement that I am out of my mind, I hope you have some relevant experience that you can share to back it up. I doubt you do - your comment comes across more as vague new-paradigm-hate than as experience-based wisdom - but I would be happy to be wrong.

zachrip 8y ago

I use it everyday and love it. I write both sides of it and it's paradise compared to working with rest. I'd pick my stack again any day: typescript, react, react-apollo, graphql-tools, apollo-express. I'm able to move so damn fast, it's a breath of fresh air.

dopeboy 8y ago
Curious about your stack - what's your backend in and what GraphQL provider do you use?
- zachrip 8y ago
  The stack is already listed in the first comment but it's Apollo on the front and backend. Typescript on both sides as well. Interfaces a MySQL DB and various grpc services.
  - dopeboy 8y ago
    Ah ok, I thought Apollo was only a frontend client. My mistake.