# GraphQL and the Italian interoperability framework **URL:** \ **Category:** Interoperabilità\ **Created:** [21 Ottobre 2019, 5:05pm UTC](https://forum.italia.it/t/graphql-and-the-italian-interoperability-framework/11762 "2019-10-21T17:05:35Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Roberto\_Polli](https://forum.italia.it/user_avatar/forum.italia.it/roberto_polli/32/1127_2.png) [@Roberto\_Polli](https://forum.italia.it/u/Roberto_Polli)\ **Post date:** [21 Ottobre 2019, 5:05pm UTC](https://forum.italia.it/t/graphql-and-the-italian-interoperability-framework/11762/1 "2019-10-21T17:05:35Z")
Since we released for comments the [Italian Interoperability Guidelines](https://docs.italia.it/italia/piano-triennale-ict/lg-modellointeroperabilita-docs/it/bozza/doc/doc_02_cap_07.html?highlight=graphql) many people asked why we speak about REST architectural style while GraphQL is only mentioned in relation with open data. Shortly [GraphQL](https://graphql.org/) 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](https://graphql.github.io/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 may be achieved with protocols like HTTP/2 and above, which implement connection multiplexing [see HTTP Chair Mark Nottingham’s post](https://www.mnot.net/blog/2019/10/13/h2_api_multiplexing); - and GraphQL may negatively impact caching. This [GraphQL at Netflix](https://medium.com/netflix-techblog/our-learnings-from-adopting-graphql-f099de39ae5f) 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](https://speakerdeck.com/zdne/what-api-your-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. ---
**Author:** ![patrick91](https://forum.italia.it/user_avatar/forum.italia.it/patrick91/32/2872_2.png) [@patrick91](https://forum.italia.it/u/patrick91)\ **Post date:** [4 Novembre 2019, 12:38pm UTC](https://forum.italia.it/t/graphql-and-the-italian-interoperability-framework/11762/2 "2019-11-04T12:38:23Z")
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! 🙂 [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 ---
**Author:** ![Roberto\_Polli](https://forum.italia.it/user_avatar/forum.italia.it/roberto_polli/32/1127_2.png) [@Roberto\_Polli](https://forum.italia.it/u/Roberto_Polli)\ **Post date:** [5 Novembre 2019, 10:18am UTC](https://forum.italia.it/t/graphql-and-the-italian-interoperability-framework/11762/3 "2019-11-05T10:18:45Z")
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! ---
**Author:** ![Roberto\_Polli](https://forum.italia.it/user_avatar/forum.italia.it/roberto_polli/32/1127_2.png) [@Roberto\_Polli](https://forum.italia.it/u/Roberto_Polli)\ **Post date:** [7 Luglio 2020, 12:28pm UTC](https://forum.italia.it/t/graphql-and-the-italian-interoperability-framework/11762/4 "2020-07-07T12:28:26Z")
The UK National Archives shared some knowledge their first GraphQL project. Thats very interesting! See their Architecture Decision Records for further information: - [https://github.com/nationalarchives/tdr-dev-documentation/tree/master/architecture-decision-records](https://github.com/nationalarchives/tdr-dev-documentation/tree/master/architecture-decision-records) ---
**Author:** ![Roberto\_Polli](https://forum.italia.it/user_avatar/forum.italia.it/roberto_polli/32/1127_2.png) [@Roberto\_Polli](https://forum.italia.it/u/Roberto_Polli)\ **Post date:** [1 Settembre 2020, 8:22pm UTC](https://forum.italia.it/t/graphql-and-the-italian-interoperability-framework/11762/5 "2020-09-01T20:22:36Z")
UK government digital services workshop on graphql minutes: [https://technology.blog.gov.uk/2020/08/28/what-we-learned-from-a-recent-graphql-workshop/](https://technology.blog.gov.uk/2020/08/28/what-we-learned-from-a-recent-graphql-workshop/)