Skip to content

Commit

Permalink
New translations querying-best-practices.mdx (Italian)
Browse files Browse the repository at this point in the history
  • Loading branch information
@benface
benface committed Dec 28, 2023
1 parent cfc2271 commit 9e85c52
Showing 1 changed file with 50 additions and 50 deletions.
100 changes: 50 additions & 50 deletions website/pages/it/querying/querying-best-practices.mdx
View file
Original file line number Diff line number Diff line change
Expand Up @@ -205,7 +205,7 @@ Quando si interrogano le GraphQL API, si deve sempre pensare di effettuare query

Una causa comune di over-fetching sono le collezioni di entità. Per impostazione predefinita, le query recuperano 100 entità in un collezione, che di solito sono molte di più di quelle effettivamente utilizzate, ad esempio per la visualizzazione all'utente. Le query dovrebbero quindi essere impostate quasi sempre in modo esplicito e assicurarsi di recuperare solo il numero di entità di cui hanno effettivamente bisogno. Questo vale non solo per le collezioni di primo livello in una query, ma ancora di più per le collezioni di entità annidate.

For example, in the following query:
Ad esempio, nella seguente query:

```graphql
query listTokens {
Expand All @@ -220,13 +220,13 @@ query listTokens {
}
```

The response could contain 100 transactions for each of the 100 tokens.
La risposta potrebbe contenere 100 transazioni per ciascuno dei 100 token.

If the application only needs 10 transactions, the query should explicitly set `first: 10` on the transactions field.
Se l'applicazione ha bisogno solo di 10 transazioni, la query deve impostare esplicitamente `first: 10` sul campo transazioni.

**Combining multiple queries**
**Combinazione di più query**

Your application might require querying multiple types of data as follows:
L'applicazione potrebbe richiedere di effettuare query di più tipi di dati, come di seguito indicato:

```graphql
import { execute } from "your-favorite-graphql-client"
Expand Down Expand Up @@ -256,9 +256,9 @@ const [tokens, counters] = Promise.all(
)
```

While this implementation is totally valid, it will require two round trips with the GraphQL API.
Sebbene questa implementazione sia assolutamente valida, richiederà due viaggi di andata e ritorno con GraphQL API.

Fortunately, it is also valid to send multiple queries in the same GraphQL request as follows:
Fortunatamente, è anche possibile inviare più query nella stessa richiesta GraphQL, come segue:

```graphql
import { execute } from "your-favorite-graphql-client"
Expand All @@ -279,13 +279,13 @@ query GetTokensandCounters {
const { result: { tokens, counters } } = execute(query)
```

This approach will **improve the overall performance** by reducing the time spent on the network (saves you a round trip to the API) and will provide a **more concise implementation**.
Questo approccio **migliorerà le prestazioni complessive** riducendo il tempo trascorso sulla rete (si risparmia un viaggio di andata e ritorno verso l'API) e fornirà **un'implementazione più concisa**.

### Leverage GraphQL Fragments
### Sfruttare i frammenti GraphQL

A helpful feature to write GraphQL queries is GraphQL Fragment.
Una funzione utile per scrivere GraphQL query è GraphQL Fragment.

Looking at the following query, you will notice that some fields are repeated across multiple Selection-Sets (`{ ... }`):
Osservando la seguente query, si noterà che alcuni campi sono ripetuti su Selection-Sets multipli (`{ ... }`):

```graphql
query {
Expand All @@ -305,12 +305,12 @@ query {
}
```

Such repeated fields (`id`, `active`, `status`) bring many issues:
Tali campi ripetuti (`id`, `active`, `status`) comportano molti problemi:

- harder to read for more extensive queries
- when using tools that generate TypeScript types based on queries (_more on that in the last section_), `newDelegate` and `oldDelegate` will result in two distinct inline interfaces.
- più difficile da leggere per le query più estese
- quando si usano strumenti che generano tipi TypeScript basati su query (_per saperne di più nell'ultima sezione_), `newDelegate` e `oldDelegate` risulteranno in due interfacce inline distinte.

A refactored version of the query would be the following:
Una versione riadattata della query sarebbe la seguente:

```graphql
query {
Expand All @@ -334,29 +334,29 @@ fragment DelegateItem on Transcoder {
}
```

Using GraphQL `fragment` will improve readability (especially at scale) but also will result in better TypeScript types generation.
L'uso di GraphQL `fragment` migliorerà la leggibilità (soprattutto in scala), ma anche la generazione di tipi TypeScript.

When using the types generation tool, the above query will generate a proper `DelegateItemFragment` type (_see last "Tools" section_).
Quando si usa lo strumento di generazione dei tipi, la query di cui sopra genererà un tipo `DelegateItemFragment` corretto (_vedi l'ultima sezione "Strumenti"_).

### GraphQL Fragment do's and don'ts
### I frammenti GraphQL da fare e da non fare

**Fragment base must be a type**
**La base del frammento deve essere un tipo**

A Fragment cannot be based on a non-applicable type, in short, **on type not having fields**:
Un frammento non può essere basato su un tipo non applicabile, in breve, **su un tipo che non ha campi**:

```graphql
fragment MyFragment on BigInt {
# ...
}
```

`BigInt` is a **scalar** (native "plain" type) that cannot be used as a fragment's base.
`BigInt` è un **scalare** (tipo nativo "semplice") che non può essere usato come base di un frammento.

**How to spread a Fragment**
**Come diffondere un frammento**

Fragments are defined on specific types and should be used accordingly in queries.
I frammenti sono definiti su tipi specifici e devono essere usati di conseguenza nelle query.

Example:
Esempio:

```graphql
query {
Expand All @@ -377,20 +377,20 @@ fragment VoteItem on Vote {
}
```

`newDelegate` and `oldDelegate` are of type `Transcoder`.
`newDelegate` e `oldDelegate` sono di tipo `Transcoder`.

It is not possible to spread a fragment of type `Vote` here.
Non è possibile diffondere un frammento di tipo `Vote` qui.

**Define Fragment as an atomic business unit of data**
**Definire il frammento come unità aziendale atomica di dati**

GraphQL Fragment must be defined based on their usage.
I Fragment GraphQL devono essere definiti in base al loro utilizzo.

For most use-case, defining one fragment per type (in the case of repeated fields usage or type generation) is sufficient.
Per la maggior parte dei casi d'uso, è sufficiente definire un fragment per tipo (nel caso di utilizzo di campi ripetuti o di generazione di tipi).

Here is a rule of thumb for using Fragment:
Ecco una regola empirica per l'utilizzo di Fragment:

- when fields of the same type are repeated in a query, group them in a Fragment
- when similar but not the same fields are repeated, create multiple fragments, ex:
- quando i campi dello stesso tipo si ripetono in una query, raggrupparli in un Fragment
- quando si ripetono campi simili ma non uguali, creare più fragment, ad esempio:

```graphql
# base fragment (mostly used in listing)
Expand All @@ -413,45 +413,45 @@ fragment VoteWithPoll on Vote {

---

## The essential tools
## Gli strumenti essenziali

### GraphQL web-based explorers
### Esploratori web basati su GraphQL

Iterating over queries by running them in your application can be cumbersome. For this reason, don't hesitate to use [The Graph Explorer](https://thegraph.com/explorer) to test your queries before adding them to your application. The Graph Explorer will provide you a preconfigured GraphQL playground to test your queries.
Iterare le query eseguendole nell'applicazione può essere ingombrante. Per questo motivo, non esitate a usare [Graph Explorer](https://thegraph.com/explorer) per testare le query prima di aggiungerle all'applicazione. Graph Explorer fornisce un'area di GraphQL playground preconfigurata per testare le query.

If you are looking for a more flexible way to debug/test your queries, other similar web-based tools are available such as [Altair](https://altair.sirmuel.design/) and [GraphiQL](https://graphiql-online.com/graphiql).
Se si cerca un modo più flessibile per eseguire il debug/test delle query, sono disponibili altri strumenti simili basati sul web, come [Altair](https://altair.sirmuel.design/) e [GraphiQL](https://graphiql-online.com/graphiql).

### GraphQL Linting
### Linting di GraphQL

In order to keep up with the mentioned above best practices and syntactic rules, it is highly recommended to use the following workflow and IDE tools.
Per tenere il passo con le best practice e le regole sintattiche di cui sopra, si consiglia vivamente di utilizzare i seguenti strumenti di workflow e IDE.

**GraphQL ESLint**

[GraphQL ESLint](https://github.com/dotansimha/graphql-eslint) will help you stay on top of GraphQL best practices with zero effort.

[Setup the "operations-recommended"](https://github.com/dotansimha/graphql-eslint#available-configs) config will enforce essential rules such as:
[L'impostazione della configurazione "operazioni consigliate"](https://github.com/dotansimha/graphql-eslint#available-configs) farà rispettare regole essenziali come:

- `@graphql-eslint/fields-on-correct-type`: is a field used on a proper type?
- `@graphql-eslint/no-unused variables`: should a given variable stay unused?
- and more!
- `@graphql-eslint/fields-on-correct-type`: un campo è utilizzato su un tipo corretto?
- `@graphql-eslint/no-unused variables`: una determinata variabile deve rimanere inutilizzata?
- e altro ancora!

This will allow you to **catch errors without even testing queries** on the playground or running them in production!
Questo vi permetterà di **cogliere gli errori senza nemmeno testare le query** sul playground o eseguirle in produzione!

### IDE plugins
### Plugin IDE

**VSCode and GraphQL**
**VSCode e GraphQL**

The [GraphQL VSCode extension](https://marketplace.visualstudio.com/items?itemName=GraphQL.vscode-graphql) is an excellent addition to your development workflow to get:
[L'estensione GraphQL VSCode](https://marketplace.visualstudio.com/items?itemName=GraphQL.vscode-graphql) è un'eccellente aggiunta al vostro flusso di lavoro di sviluppo:

- syntax highlighting
- autocomplete suggestions
- validation against schema
- snippets
- go to definition for fragments and input types
- vai alla definizione dei frammenti e dei tipi dell'input

If you are using `graphql-eslint`, the [ESLint VSCode extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) is a must-have to visualize errors and warnings inlined in your code correctly.
Se si utilizza `graphql-eslint`, [l'estensione ESLint VSCode](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) è indispensabile per visualizzare correttamente gli errori e gli avvertimenti inseriti nel codice.

**WebStorm/Intellij and GraphQL**
**WebStorm/Intellij e GraphQL**

The [JS GraphQL plugin](https://plugins.jetbrains.com/plugin/8097-graphql/) will significantly improve your experience while working with GraphQL by providing:

Expand All @@ -460,4 +460,4 @@ The [JS GraphQL plugin](https://plugins.jetbrains.com/plugin/8097-graphql/) will
- validation against schema
- snippets

More information on this [WebStorm article](https://blog.jetbrains.com/webstorm/2019/04/featured-plugin-js-graphql/) that showcases all the plugin's main features.
Maggiori informazioni in questo [articolo di WebStorm](https://blog.jetbrains.com/webstorm/2019/04/featured-plugin-js-graphql/) che illustra tutte le caratteristiche principali del plugin.

0 comments on commit 9e85c52

Please sign in to comment.