Why not use GraphQL?

Re:Why not use GraphQL? by Diesel555 on Saturday November 07, 2020 @09:37PM (#25022296)

I'm surprised at all the people that prefer REST over GraphQL.

I'm a developer of my own projects for fun. I don't work in tech. My frontends are on iOS / Android / the web with Typescript. So my confusion is from a perspective without expertise.

I started with REST via Django and a few others, and now I've switched to GraphQL. I love GraphQL over REST backends due to the type automation tools such as GraphQL Code Generator and query tools like Apollo. Also being able to construct a query and access children via one request is super nice. For example my old REST APIs call for a post, then get pictures for that post, then get comments for that post, then gets the username and other user data for the owner that made the comment. It's four requests. My GraphQL requests just get them all in one customizable request. Post can contain pictures and comments and all their properties. Comments can contain the owner of the comment and all its properties to include things like username.

The result is a typescript object that is strongly typed and has all the data I need. Before GraphQL, in REST, this would be four requests, three of which are in series (post -> comment -> owner to get username). I know I could make a custom REST API to do the same thing, but it was just so easy in GraphQL, I didn't have to worry about it.

I'm not working in teams, I'm not creating a super large backend, it's not complex projects... so I don't know what I don't know.

But what am I missing? Maybe not everyone needs / uses the typing I do? That's the big benefit for me. Maybe not everyone cares about being able to query children (or create children via a nested create)? Maybe these things were easier than how I was doing it in REST?

[ Parent | on HN ]

Re:Why not use GraphQL? by pault on Saturday November 07, 2020 @10:46PM (#25022728)

These are all excellent points in favor of productivity with GraphQL. I always avoid new technologies for a few years to let the hype cycle mature (for example, everybody talking about how great mongodb is and writing blog posts about how they migrated, followed two years later by everybody talking about how terrible mongodb is and how they had to migrate to posgresql). As a dev working on a commercial software project, especially if you're in leadership, you have to look very carefully at every technology you introduce into your stack, because you are going to be supporting it for years. If it turns out to be the wrong decision, or you get caught out by a bunch of edge cases that weren't well known in the early days, you can end up losing millions of dollars in productivity, and possibly killing the company when you can't fix bugs and ship new features. So I've been suspicious of GraphQL, but keeping an eye on it. I still don't know if the productivity gains you get up front are actually technical debt in disguise, but if that turns out not to be the case, and it really is a matter of only having to write one query instead of making five requests and several dozen lines of types, validators, and async redux middleware, I'll be happy to adopt it in the future.

[ Parent | on HN ]

Re:Why not use GraphQL? by balfirevic on Sunday November 08, 2020 @10:34PM (#25031219)

> Maybe these things were easier than how I was doing it in REST?

That might be the case. Those things (such as returning children - and generally crafting a custom endpoint for specific use-case) are indeed very easy in my language/framework of choice (ASP.NET with a little help from LINQ).

I also get automatic generation of client-side data classes and strongly typed functions that encapsulate endpoints on the server using a small code generation framework that literally took 2-3 days to write (it's really not that complex).

[ Parent | on HN ]

Re:Why not use GraphQL? by mattmanser on Sunday November 08, 2020 @06:50AM (#25025126)

You (and we) have no clue how bad your code is.

You're suffering under Dunning-Kruger.

For example, what you described about making 4 requests with your 'REST' API, you didn't have to do that. YOU made that terrible API. That's not a feature of REST, but you seem to have mixed the two up in your head.

[ Parent | on HN ]

Re:Why not use GraphQL? by jensneuse on Sunday November 08, 2020 @09:29AM (#25026006)

The idea of a REST endpoint is to represent a resource, not a view. How will you bring good RESTful API design together with the requirement of wanting an API that serves one very specific view that depends on multiple REST APIs. This seems to be in conflict doesn't it? What's your idea on resolving this conflict without abandoning the principles of RESTful API design?

[ Parent | on HN ]

Re:Why not use GraphQL? by balfirevic on Sunday November 08, 2020 @10:09PM (#25031105)

> The idea of a REST endpoint is to represent a resource, not a view

Resource is not what you think it is. The conflict you’re talking about doesn’t exist.

[ Parent | on HN ]

Re:Why not use GraphQL? by htkibar on Sunday November 08, 2020 @09:22AM (#25025959)

What feature of REST would allow you to separate your entities as they should be while being able to arbitrarily query them together?

[ Parent | on HN ]

Re:Why not use GraphQL? by balfirevic on Sunday November 08, 2020 @10:15PM (#25031137)

Feature where you can write an endpoint to return whatever it is that you need. Granted, it’s not automatic as in some GraphQL frameworks - not sure if that’s what you meant by “arbitrary”. But then again, such things are a step beyond just using GraphQL as a protocol.

[ Parent | on HN ]

Re:Why not use GraphQL? by htkibar on Monday November 09, 2020 @05:53PM (#25040956)

The comparison would be;

REST: Any time there is a new "view"; you need to go to your server and write a new endpoint.

GraphQL: You can stitch data together however you want; as long as that data is defined.

So for example if I need name of someone and the url of their children; querying it alone is enough with GraphQL whereas with REST either I need to fetch multiple times or write a new endpoint that serves both together.

[ Parent | on HN ]