HATEOAS vs GraphQL decision criteria set for microservices? [closed]

Question

I was talking to someone recently who said they are skipping the development of HATEOAS REST endpoints completely in favor of GraphQL. So I'm curious as to what the criteria set is for deciding when to use GraphQL vs. HATEOAS or is GraphQL just a better choice in general for an API Gateway / Edge Server architecture?

Tollmann

Answer 1

The pros and cons of each are:

GraphQL

Pro:

• provides fine control of returned data in avoiding unneeded traffic
• eliminates needing to go back to the well over and over for attached / "follow-on" data
• following from the above, it allows the software designer to provide excellent performance by reducing latency - each query specifies all the things it needs, and the GraphQL implementation can assemble and deliver it with only one client<->server transaction
• possibility of slow deprecations instead of versioned APIs
• it's a query language
• introspection is built-in

Con:

• does not deal with caching (although there are now libraries that will take care of this)

HATEOAS / REST

Pro:

• caching is a well-understood matter
• relatively mature and well-understood
• lots of infrastructure for eg CDNs to spread the load
• very suitable for microservices
• file uploads are possible

Con:

• the "back to the well" problem
• not as rigidly specified
• each implementation of server and client(s) must make its own decisions
• querying is not standard

Conclusions

One interesting comparison is that people use GraphQL as a frontend for REST APIs, but no-one in their right mind would consider doing the converse. If you go for a federated / microservices design, so one GraphQL server fronts for others, they can use a common specification of the API between the frontend and the microservices; this is less certainly true if the microservices are REST.

I think that so long as you have in mind the right questions to ask, GraphQL is going to be an important part of a well-designed system. Whether to skip HATEOAS entirely is unfortunately, "it depends".

Sources

My own experience, plus Phil Sturgeon's GraphQL vs REST: Overview

Suffocate

Pretty good overview. Note that nothing prevents you from wrtiting a quick POST based aggregation endpoint that will just follow GET links from an initial resource. I find this is the best of both worlds even if it still doesn't give you standardisation. – Dachia

Bespoke complexity plus no standardisation might be seen as the worst of both worlds ;-) – Suffocate

@Ed., I have one question for ya. Which one has more complexity? – Tuberculosis

Answer 2

I love that Ed posted a link to my overview, but there's another article that I believe to be more relevant than that one.

The representation of state is completely different between the two.

https://apisyouwonthate.com/blog/representing-state-in-rest-and-graphql/

GraphQL is entirely unable to offer a series of "next steps" in a meaningful and standardized way, other than maybe shoving an array of strings containing potentially relevant mutations that you should try to hit up.

Even if you do that, it certainly cannot help you communicate with other HTTP APIs, which is a real shame.

Anyway, it's all that article! :)

Montmartre