menu di navigazione del network

GraphQL and the Italian interoperability framework

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:

  1. 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.

  1. 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.

  2. 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.

  3. GraphQL is sometimes advocated for reducing the number of requests and bandwidth consumption, but remember:

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.

1 Like

GraphQL is not only being able to optimise the requests, while some things can be solved by HTTP2, what GraphQL does provide more than REST APIs is the developer experience, I have yet to see some library/clients for REST that makes using an API so easy and friendly.

Take Apollo for example, you set the client one and then when you request data you pass the specific GraphQL query you need and the everything is handled by the client. No need to add logic to fetch data and store it in a cache.

In addition to that with the schema[1] that every GraphQL provides you can use tools like GraphiQL, GraphQL cli to play around with the API, do linting and getting autocomplete in your IDEs.

What I’m trying to say is that GraphQL is not just optimising requests, it is also about optimising the development cycle for the clients.

That said, I don’t think for now we should focus on having a GraphQL API, we should wait a bit more to have more people requesting and more people familiar with scaling GraphQL APIs.

Hope this helps! :slight_smile:

[1] To be fair this can be achieved with REST as well, but it is an addition to REST, and not 100% sure it is as developer friendly as I’d like

Hi @patrick91 and thanks for contributing!

GraphQL does provide more than REST APIs is the developer experience
[and] optimising the development cycle for the clients.

I agree that GraphQL tooling may simplify the developer experience,
which is important as this improves the overall quality of the services.

we should wait a bit more to have more people requesting
and more people familiar with scaling GraphQL APIs.

While familiarity with scaling GraphQL is important for web-facing APIs,
we are really interested in solving the points 1-4 cited in the post,
and I hope you can provide some examples or technical insights on that!