canmove, Confirmed users
1,448
edits
L10n:Pontoon/API: Difference between revisions
Jump to navigation
Jump to search
→Cons
No edit summary |
(→Cons) |
||
| Line 43: | Line 43: | ||
* Circular queries are possible (<code>{ projects { locales { projects } } }</code>) | * 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 | ||
** See https://github.com/graphql-python/graphene/issues/348#issuecomment-267717809 and https://github.com/graphql-python/graphene/issues/462#issuecomment-298218524 | |||
* Optimizations relying on <code>prefetch_selected</code> can be brittle. | * 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 <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. | ** 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. | ||
** The optimizations can be added dynamically depending on the exact query thanks to the introspection. This is similar to the approach to preventing circular queries | |||
*** See https://yacine.org/2017/02/27/graphqlgraphene-sqlalchemy-and-the-n1-problem/ | |||
==GraphQL with Relay== | ==GraphQL with Relay== | ||