Not only factoring in coding effort for the API developers, but also the communication and design effort with client application developers, chances of misunderstanding and frustration, etc.
One thing that comes across in Marc-André Giroux’s talk is that communication between developers on the integrator and provider side is key in order to evolve an effective schema. So regardless what technology is employed, communication difficulties can only have a negative impact the quality of the API.
but rather about who makes which decision about the aggregate.
The provider team working in a vacuum without input from the consumers isn’t likely going to result in an effective API regardless of technology.
GraphQL, in this case, leaves these decisions to the side that has the most knowledge.
The provider side should have the most knowledge about their domain. That doesn’t necessarily imply that they fully comprehend the needs of their consumers.
My view is that in this specific case GraphQL leads to fewer decisions that have to be made cross-team
The anecdotal evidence I’ve come across over the years is that these types of problems are not best solved with technology but with cross-functional teams - i.e. the same people who consume the API also design it.
Marc-André Giroux published an introductory chapter of his upcoming book.
His hypothesis is that REST APIs ran into trouble because of OSFA (one size fits all) design. In the ideal case a REST API would just represent the domain in terms of resources but the consequence was that the API would be equally inconvenient for most consumers. Adding more resources to accommodate different consumers needs, only serve to make the API convoluted.
In response to the problem Soundcloud started to segregate these resources into separate BFFs.
I find the approach that Netflix took to be the most interesting.
They arranged for consumers to deploy server-side client adapters. That way the general API can be just domain oriented while the server-side client adapter can focus on the needs of one particular client managing lean payloads with an optimal shape for the client on the other side of the network.
Marc-André Giroux views client-side GraphQL as a “client-side BFF”. So just like a normal BFF is coupled to the general server-side API, client-side GraphQL is coupled to the provider schema.
In order to provide this sort of flexibility on the client-side I think that GraphQL has increased the end-to-end accidental complexity.
While “client-side BFF” can work, I have to wonder whether with the emergence of JS budgets to accomodate the anticipated increase in consumption of the web via lower end smart devices there is going to be a push for even leaner client-to-server interactions - where the content and shape of the data is customized to a fit specific clients needs in order to minimize the amount of code and processing time that is needed on the client.
