I'm a bit lost, since I've never seen GraphQL before and I've only spent
a short amount of time looking at documentation.
The first impression is that it offers a lot of flexibility, probably
more than we need. If it doesn't come at a cost (e.g. code complexity,
dependencies, etc.) I guess it won't hurt. Let me know if you deploy
that branch somewhere, I'll probably play with the editor (I don't have
Pontoon installed locally, but I might at some point).
As long as the API can also be accessed via dumb GET requests[1], I'm
fine with any solution you adopt.
Francesco
[1]
http://graphql.org/learn/serving-over-http/#http-methods-headers-and-body
Stas,
Thanks so much for researching, implementing and documenting all of this!
I gave your patch a spin, which allowed me to use GraphQL for the first
time (yay!). I find it easy to use and also performant for the use case
from bug 1302053. The API explorer is indeed helpful. I like the
flexibility of the output GraphQL gives me.
Once he's back from vacation, I'd love to hear what flod - as the main
consumer of the bug 1302053 use case - thinks about these two approaches
and which one would he prefer.
BTW, the other day I came across this article and quickly scanned through
it:
https://philsturgeon.uk/api/2017/01/24/graphql-vs-rest-overview/
One thing worth pointing out is "You can definitely use both [REST and
GraphQL] at the same time". I understand that's not ideal, but it's a
useful reminder that even if we choose X over Y and sometime in the future
Y turns out to be much more suitable for use case A, it's not like we have
to rewrite the whole thing.
-Matjaž
On Wed, Jul 12, 2017 at 7:14 PM, Staś Małolepszy <[email protected]> wrote:
I'd like to work on exposing Pontoon data via an API. The main driver
is the use case from bug 1302053:
- Stats for a locale: supported projects, status of each project.
- Stats for a project: supported locales, incomplete locales,
complete locales.
I researched using REST and GraphQL and wrote down my notes on the wiki:
https://wiki.mozilla.org/L10n:Pontoon/API
I'm still hesitating between REST and GraphQL (without Relay). The
former is familiar and well-established. The latter offers really nice
syntax and an amazing API explorer with built-in documentation. OTOH,
in case of some requests, using GraphQL naïvely may result in a lot of
queries being made to the DB.
In an effort to see if the problem of too many queries can be remedied
I implemented four simple entry points for Pontoon: projects, project,
locales and locale. Prefetch_selected optimizations are only added if
the query requires them. Cyclic queries are also explicitly forbidden
to prevent querying for projects of locales of projects etc. (I'm sure
the code I wrote for this can be generalized and made more robust, but
it's good enough for the purposes of the demo.)
https://github.com/mozilla/pontoon/compare/master...stasm:graphql
The demo is read-only . The GUI editor is only available in DEV mode.
On production, the /graphql endpoint is available without
authentication, CSP nor CSRF.
This exercise nicely shows off the good things about GraphQL, too.
See the following 1.5-minute-long silent screencast of the GraphiQL
tools which makes writing queries and debugging them a pleasure:
https://drive.google.com/file/d/0B4XpFaGRPsjHai1nUXJRdWMya3c/
view?usp=sharing
I'd love to open this up for discussion. Let me know if my notes
reflect your experience working with REST and GraphQL. What other
factors and considerations are important here? What would your
preferred way forward be?
Thanks,
Staś
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
