In my personal experience, mobile app development (or single-page client application development) tends to be very annoying with REST APIs. REST APIs often force client application developers to perform many HTTP calls, possibly with several levels of dependence, in order to fetch enough data to render a screen. Example: to render a product page, fetch the product information, but also seller information, related products, available offers, user data, recommendations, user comments, etc. From the client application point of view, it would be much more efficient and clean to perform only one request to get all the information necessary to build each specific screen. That does not map well to a resource-oriented API.

To make things worse, changing needs of client applications often result in API versioning: one cannot force all users to switch instantaneously to the newer version of the mobile app, hence the old and the new API versions both have to be maintained indefinitely, with great frustration of API developers.

There is a tension between the different requirements of client application developers and REST API developers. I have seen these kind of issues straining the relationship between backend and mobile teams a number of times.

GraphQL definitely simplifies this a lot from the point of view of the client application developer: the server simply defines what can be fetched, while the client chooses what to fetch, in one single request. This approach often also alleviates the problems that come with API versioning, that can be especially annoying in big REST APIs.

Another common solution is to implement a “backend for frontend”, that orchestrates all the HTTP requests and exposes the combined result in fewer endpoints taylor-made for the client application. That layer has to manage dependencies between requests, error handling, often also transforming the result. GraphQL can be used for this too, operating on top of a REST API.

Aspects where instead GraphQL struggles and REST shines, in my opinion, are caching (REST is very much designed for that, and can leverage cache-control headers and client-side caching too), pagination (possible with GraphQL of course, but slightly annoying because it requires wrapping each paginated list of results), and performing updates (can be done with GraphQL mutations, but in this territory REST is often simpler). With GraphQL it is also harder to protect against DoS by crafting very complex requests: with REST one can more easily assess the complexity of each separate endpoint, and rate-limit differently.

My personal preference is to use REST for external APIs, and GraphQL for read-only internal APIs used by the client application. For writes, I usually still prefer the REST way. I also prefer REST for very long paginated lists of flat simple results, where caching can be handled much more easily.

REST APIs often force client application developers to perform many HTTP calls.

There is no restriction to publishing resources that aggregate other resources to save the number of requests that you have to make. Exposing these aggregates would be in line with consumer-driven contracts. And by factoring out these “aggregates” into separate APIs you end up with BFFs which you mention.

Of course if you aren’t in control of the API you consume you are at the mercy of what the provider is willing to give you.

hence the old and the new API versions both have to be maintained indefinitely, with great frustration of API developers.

As far as I can tell GraphQL APIs can suffer the same sort of versioning problems.

I have seen these kind of issues straining the relationship between backend and mobile teams a number of times.

Seems to be the same type of chasm that has been historically associated which Object vs. Relational.

This approach often also alleviates the problems that come with API versioning

How? I’m not convinced this is at all true for GraphQL.

• I’m not denying the short term gain of being able to specify against a schema exactly what you want to get back.
• I’m also not denying that there are some ways in which a schema can be evolved without breaking existing queries.

But as soon as some major refactoring (in the general sense) needs to take place which moves types around in the relationship graph, you are going to need a new version. The issue is that the client becomes coupled to those parts of the schema that need to be traversed to get to the data it actually wants. I wouldn’t describe a schema as a narrow API because the client may need to know about intermediate types it doesn’t really care about.

In OO there is the law of demeter - similarly the more relations you have to traverse to get to your data, the more fragile (and coupled) your query becomes in the face of a changing schema.

It’s really only the BFF acting as an Anti Corruption Layer that can protect the front end from API changes - but the BFF still has to adapt to the original API. And as a BFF would have an API that is optimized for a particular client there would be very little benefit to using GraphQL - because the BFF API can focus on exactly what the client needs, so a for-purpose REST API works just as well (and in many cases is simpler).

Designing a schema that can serve the needs of multiple client communities is a non-trivial task.

To some some degree I think that “bad” APIs, REST or GraphQL, are a result of too much focus on technology and tools, while not expending enough effort on trying to understand the underlying abstractions that the technology is based on.

• For example, to me Swagger seems to focus too much on “pretty URLs” rather than resource design REST: I don’t Think it Means What You Think it Does • Stefan Tilkov.
• With GraphQL most resources tend to focus on tooling and technology but really don’t get into the right way to design a schema or how to design a schema for extensibility/maintainability (potentially this - still waiting, talk by the author).

Then there are cases where GraphQL APIs (or REST APIs) simply expose the underlying data model - coupling the front end all the way down to the back end data model.

While doing my master (many years ago) our university forced us to work with a “successful startup”. The term successful is used rather benevolently here, since they were just people with friend in the University and were looking for fresh bodies to join the meat grinding machine they called a company.

We had to use their REST API for our project and … it was horrible. The API itself made little to no sense and half the calls didn’t even work. It was even admitted the API was the product of some guy doing extra hours at home, so I am not surprised. Never again.

On the other side, I have also studied and used GitHub’s API, a rather nice experience.

In the end I think that REST vs GraphQL experiences will largely depend on the people who made them - you can also have terrible GraphQL APIs, just as you can have really nice REST ones.