Since we released for comments the Italian Interoperability Guidelines
many people asked why we speak about REST architectural style
while GraphQL is only mentioned in relation with open data.
Shortly GraphQL is a query language:
- allowing the client to specify,
- in one single data structure,
- both the query
- and the response format requested to the server.
It is generally used over HTTP but the GraphQL spec do not mandate a transport protocol.
The short answer is: we are planning an evolutionary framework and
GraphQL may be added some day.
A longer explanation is related to public services API and data:
- with the approach proposed in the Italian Guidelines, the request URI identifies the response format and the underlying data-type. This simplifies:
- leveraging PATH and METHOD for auditing and routing requests;
- schema validation, because client can’t compose data-types.
GraphQL moves those information to the application level creating more variability.
-
The above applies to the authorization level too, which is then tied to the PATH and to the specific query that’s going to be issued. This means the GraphQL endpoint should log all relevant information.
-
GraphQL is very flexible and gives a lot of power to clients. This makes request processing more computationally intensive on servers. This might hinder API adoption.
-
GraphQL is sometimes advocated for reducing the number of requests and bandwidth consumption, but remember:
- this may be achieved with protocols like HTTP/2 and above, which implement connection multiplexing see HTTP Chair Mark Nottingham’s post;
- and GraphQL may negatively impact caching.
This GraphQL at Netflix article shows the architectural challenges
faced by Netflix for a successful adoption of GraphQL.
Another interesting source is the Guide to API Styles, slide 48 di Zdenek Nemec.
Still, GraphQL is an interesting technology when:
- clients and servers are managed by the same organization (eg. a website, an app invoking its own server)
- when the server has the ability to bill for expensive requests (eg. pay-per-use APIs);
- for implementing websites front-end, eventually wrapping REST APIs
and the centralization of national platforms may even simplify its adoption providing a common framework and clear constraints for its usage.
