I think it will be easier to create a some kind of bridge between REST & GrapQL. REST in my interpretation has a subset of GraphQL's capabilities. We could create the core GraphQL backend and then create REST backend which will only execute simplified queries on GraphQL backend.
On Mon, Jul 17, 2017 at 11:12 AM, Francesco Lodolo [:flod] <[email protected]> wrote: > 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 > -- Kind regards Jarek "jotes" Śmiejczak, P ython programmer by day, mozillian by heart.. Homepage: https://evilb.it, Github: http://github.com/jotes Mobile: +48693027040, Mozillian: http://mozillians.org/u/jotes _______________________________________________ tools-l10n mailing list [email protected] https://lists.mozilla.org/listinfo/tools-l10n
