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 27: | Line 27: | ||
* Requires versioning and documentation | * Requires versioning and documentation | ||
==GraphQL== | |||
GraphQL is a query language in which the consumer describes the shape of the data they want back. | |||
====Pros==== | |||
* Easy to learn syntax | |||
* Documentation generated out-of-the-box | |||
* GUI tool for browsing the API with a docs explorer (GraphiQL) | |||
* 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 | |||
* graphene_django automates a lot of integration, including support for Enum types | |||
====Cons==== | |||
* Circular queries are possible (`{ projects { locales { projects } } }`) | |||
** 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 `prefetch_selected` can be brittle. | |||
** I'm still trying to understand exactly what happens. | |||
** The best place to optimize seems to be the top-level Query Type. | |||
** For instance, when querying a list of projects, I can `ProjectModel.objects.prefetch_related('project_locale__locale')` 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 `project.project_locale.all()` which means that I now have to use `all()` in `resolve_locales` in the Project GraphQL type. Which in turn means that when asking for a single Project, I can't `prefetch_related` in its `resolve_locales`. The work-around is to `prefetch_related` in the top-level query for the single Project too. | |||
==GraphQL with Relay== | ==GraphQL with Relay== | ||