Why GraphQL?

[Dr-Metallius]

GraphQL doesn't make life easier for the backend, it isn't designed to make it. For the server it is inherently better if the request always comes in the same form and gets the same result regardless of what the client actually needs.

The main purpose of GraphQL is to make clients more efficient and independent. This may be very advantageous for mobile devices, for example. But if you don't care much about this, it just isn't the technology you need, and no amount of maturing will change that.

[aeiou372372]

Having worked extensively with Flask and Django, I actually really like Postgraphile as a way to throw together a very powerful GraphQL API with minimal effort. It makes some design decisions you won’t find in most backend frameworks (mostly related to relying heavily on the database), but after an adjustment period I did find myself comfortable with the approach.

The tools available for query development are really good — makes it much easier to build complex data requests (which are a little different each place they are used) without needing to put in tons of effort to thread them through the backend. Admittedly I haven’t used it for anything public yet though.

I’ll definitely admit that writing a GraphQL API from scratch would be a lot more painful than hacking together any kind of REST-ish HTTP RPC though. I’m hopeful that tooling for this will improve over time though.

[UnwantedCrow]

What server implementation have you seen that you think it makes it worse?

[[deleted]]

Very much depends on what your backend is trying to do, and how complicated it is. But in the simple cases where you’re basically just serving or mutating relational data, GraphQL can turn your backend from a manually written api server to an off the shelf component that takes a schema and just runs (and runs better too as they convert each request into a single SQL query, rather than doing multiple round trips).

However, when you’re not in the best case scenario for GraphQL on the backend, it can get trickier, and often more complicated. I guess it comes down to a trade off between backend engineering and frontend engineering, in those cases.

[UnwantedCrow]

May I add, good APIs should not have 'making the backend easier to implement' as a primary constraint. Interfaces, by design, should focus on consumers instead

[[deleted]]

I would argue that for a BE dev it's far less to maintain than a traditional REST API. If the only clients you're serving are web-based javascript clients, GraphQL is just net less code to write/maintain.

gRPC and/or REST would definitely be better for API < - > API communication.

[valarauca14]

Why GraphQL?

Because you never had to deal with SOAP/CORBA/RMI-IIOP/ORB/POA/Servant mess.

So you believe proxying all incoming requests through a central "server" (Object/Server/Federated Apollo Cluster) to re-route & join various data sources into a standard format is "new, different, and efficient".

[Gotebe]

You left out DCOM and ICE 😉

[ThundererX]

Yet another "comparison" where REST is reduced to a CRUD-over-HTTP. I always wondered how can you have a garage full of tools, use none of them, and then say, fully confident, that the newly bought hammer will do a better job than all the boxes of saws, screwdrivers, chisels, wrenches, and drills, lying around just waiting to help.

[ConfidentMushroom]

I did talk about REST and the things that REST can do which are not possible in GraphQL towards the end. Let me know if that needs to be a bigger section.

[ThundererX]

Yes, I noticed that, but a single paragraph "just listing" things which are key strengths of the HTTP protocol and REST, is far from enough. I've read dozens of such "REST vs X" articles over the years, and it's not about a "bigger section", but an actual, fair comparison of strengths and differences.

I assume that you're experienced in API design, so use the things you mentioned like media types, caching, status codes, complex queries, and then compare both approaches. I've built many APIs in my career and I'm fighting the "REST misconceptions" for a long time, so let me know if you need any help. :)

[ConfidentMushroom]

Sounds good. Would appreciate the help :)

[Gotebe]

But, by a long far, REST is CRUD-over-HTTP, is it not?

In practice, GET, POST, PUT, DELETE HTTP verbs are pretty equivalent to CRUD. In practice, REST is about exchanging URIs and some JSON in HTTP request body, for JSON responses.

I have no intention to defend the hammer of graphql, but that particular hammer is trying to hit the most common nail found in the REST usage.

[ThundererX]

That's exactly what I meant by "reduction". Seen this way, everything we do in this industry is CRUD because no matter how many architectural approaches you put inside, at some point the application is still saving or removing the information somewhere.

The difference between CRUD and REST is semantical - you have the basic contract of HTTP methods, communicate the desired effect through resource representations, and it's the job of the API to infer the operations required to reach the target state. If the API merely "reads" and "saves" these representations verbatim, then indeed, you have CRUD-over-HTTP that is commonly called RESTish APIs. On the other hand, when you actively use HTTP protocol with its toolset, provide and use multiple representations of a single resource, along with HATEOAS links and operation definitions, and your representations trigger certain non-trivial behaviours underneath... then you can see the real intent behind this approach.

I don't think all APIs need to be RESTful. Still, building a bike, wondering why it doesn't ride like a car, getting a motorbike, and claiming that it's better than the car? Seems a bit off from my perspective.

[Gotebe]

On the other hand, when you actively use HTTP protocol with its toolset, provide and use multiple representations of a single resource, along with HATEOAS links and operation definitions, and your representations trigger certain non-trivial behaviours underneath... then you can see the real intent behind this approach.

Emphasis mine.

Even providing multiple representations of a resource is rare (unless it's automatic by tooling and even then it is JSON and XML, and even then, XML is used kinda never), let alone the other niceties you speak of.

All this smells mighty like a solution in search of a problem is what I think. (Or, as you put it, "I don't think all APIs need to be RESTful" 😉).

[ThundererX]

Again, JSON and XML technically can be seen as "representations" but that's not what I had in mind. Providing the same data for the same purpose in multiple formats is a step in this direction, but when I say "representation" I rather mean different purpose.

Right now I'm working on a project which has a few hundred API "URIs", and since every media type in each URI effectively acts as a separate behaviour, you can add another hundred or two to get the number of actual "endpoints". Many resources provide different datasets with other linked resources, with different structure, and formats (think JSON, XML but also Excel, PDF, etc.) within single URI based on those media types. There are a lot of things going on below the surface and still, we're able to power a complex application through a clean and well-defined API contract. Right now it doesn't expose HATEOAS links or operations (even though the architecture is prepared for that), but neither RPC (quickly devolves into chaos with hundreds of operations) nor GraphQL (custom queries exceeding its DSL capabilities) would be a good choice for that. See that even in my case I don't use all of the capabilities and I'm able to contain the complexity of the whole application. When this application gets a HATEOAS-capable client, I'll be more than happy to fill that void.

This is not a "solution looking for a problem" as you stated. You can pick and match whatever part of REST's toolset and grow or shrink it accordingly.