canmove, Confirmed users
1,448
edits
L10n:Pontoon/API: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 22: | Line 22: | ||
* By default, all fields as decided by the developer, are exposed and transferred, resulting in increased bandwidth | * By default, all fields as decided by the developer, are exposed and transferred, resulting in increased bandwidth | ||
** Work-arounds exists, e.g. &fields=foo,bar | ** Work-arounds exists, e.g. <code>&fields=foo,bar</code> | ||
* Only the relations expected by the developer can be queried in a single query, e.g. | * Only the relations expected by the developer can be queried in a single query, e.g. <code>project/1/locales</code> | ||
** Other relations require multiple requests, which can't be optimized | ** Other relations require multiple requests, which can't be optimized | ||
* Requires versioning and documentation | * Requires versioning and documentation | ||
| Line 38: | Line 38: | ||
* The consumer specifies exactly which fields they're interested in | * The consumer specifies exactly which fields they're interested in | ||
* A single query can span multiple types as long as they are connected in the graph | * A single query can span multiple types as long as they are connected in the graph | ||
* graphene_django automates a lot of integration, including support for Enum types | * <code>graphene_django</code> automates a lot of integration, including support for Enum types | ||
====Cons==== | ====Cons==== | ||
* Circular queries are possible ( | * Circular queries are possible (<code>{ projects { locales { projects } } }</code>) | ||
** In order to avoid them, we'd need to write code that inspects the query itself and checks if the fields don't repeat deeper in the query tree | ** In order to avoid them, we'd need to write code that inspects the query itself and checks if the fields don't repeat deeper in the query tree | ||
* Optimizations relying on | * Optimizations relying on <code>prefetch_selected</code> can be brittle. | ||
** I'm still trying to understand exactly what happens. | ** I'm still trying to understand exactly what happens. | ||
** The best place to optimize seems to be the top-level Query Type. | ** The best place to optimize seems to be the top-level Query Type. | ||
** For instance, when querying a list of projects, I can | ** For instance, when querying a list of projects, I can <code>ProjectModel.objects.prefetch_related('project_locale__locale')</code> in the top-level query in order to anticipate that the consumer will want to see the information about the related locales. In Django terms, this implies <code>project.project_locale.all()</code> which means that I now have to use <code>all()</code> in <code>resolve_locales</code> in the Project GraphQL type. Which in turn means that when asking for a single Project, I can't <code>prefetch_related</code> in its <code>resolve_locales</code>. The work-around is to <code>prefetch_related</code> in the top-level query for the single Project too. | ||
==GraphQL with Relay== | ==GraphQL with Relay== | ||
| Line 60: | Line 61: | ||
* Pontoon's data doesn't change so quickly (projects, locales, entities) to actually require a solution this powerful. | * Pontoon's data doesn't change so quickly (projects, locales, entities) to actually require a solution this powerful. | ||
** Translations and suggestions may change more quickly, however. | ** Translations and suggestions may change more quickly, however. | ||
* graphene_django doesn't handle ManyToMany fields well with Relay enabled; by default the | * <code>graphene_django</code> doesn't handle ManyToMany fields well with Relay enabled; by default the <code>through</code> table adds another layer of edges to the graph, which becomes verbose very quickly | ||
** See https://github.com/graphql-python/graphene/issues/83 | ** See https://github.com/graphql-python/graphene/issues/83 | ||
* Suffers from the N+1 queries problem for ForeignKeys and ManyToMany relationships | * Suffers from the N+1 queries problem for ForeignKeys and ManyToMany relationships | ||
** See https://github.com/graphql-python/graphene-django/issues/57 | ** See https://github.com/graphql-python/graphene-django/issues/57 | ||
* De-optimizes | * De-optimizes <code>prefetch_related</code> and <code>select_related</code> | ||
** See https://github.com/graphql-python/graphene-django/issues/179 | ** See https://github.com/graphql-python/graphene-django/issues/179 | ||