To update the list, we just decided to move forward with the approach #3. We'll finalize, review and deploy the current patch and see how it behaves with production data.
We'll keep track of the future use cases and milestones (including switching to Graphene 2.0) on the wiki: https://wiki.mozilla.org/L10n:Pontoon/API -Matjaž On Tue, Aug 29, 2017 at 10:58 AM, Staś Małolepszy <[email protected]> wrote: > Thanks, Matjaž! > >> What are the next steps here? > > First of all we need to decide if GraphQL is what we want. > > My take-aways from the discussion so far are: > > 1 The alternative to GraphQL is RPC, not REST. > 2 RPC requires that we come up with some sort of querying language. > 3 GraphQL is a query language and has a spec, which is nice. > 4 graphql-python and graphene are not as well maintained as their > JavaScript counterparts. > > In one of our meetings we considered a number of paths forward which > would mitigate this risk outlined in take-away #4. > > > 1. Use GraphQL to parse the query; write own RPC backend. > > The full GraphQL-in-Django stack includes: > > 1 A developer-built schema defining resolvers for data. > 2 A layer allowing the resolves to use Django models. > 3 A query executor which uses the schema. > 4 A query parser. > > One of the biggest advantages for us is that GraphQL has a well-defined > spec. We could only use the query parser and translate queries to > a custom RPC backend. This would allow us to skip layers 1-3 on the > stack. > > > 2. Use the JS implementation of graphql and set up a separate server > talking to the DB. > > GraphQL.js is well maintained and is the reference implementation. > > This approach would require extra work to ensure our GraphQL shapes > don't break when Django models change. We'd need to assess how frequent > DB migrations are in Pontoon and consider the cost of setting up systems > which validate or even auto-generate the GraphQL schema from Django > models. > > Approaches 1-2 require additional work before we have a working API. If > it then turns out that the API doesn't work well or that GraphQL is not > the right solution after all, this additional work will be for nothing. > > The reasons for trying GraphQL are strong and my recommendation would be > to give it a spin in its current form. Let's call it the approach #3: > > 3. Use graphene and graphene_django as they are > > They both seem sufficient for the purpose of the experiment that I ran > so far. The most buggy part seemed to be the Python implementation of > Relay which I don't think is a good match for Pontoon anyways. > > As I mentioned in my previous email there has been recent activity in > Graphene and it looks like version 2.0 is being worked on. If we have > concerns about the codebase, it would be nice to take them up to the > authors and help fix them. > > I have a WIP PR which I'd like to bring to a state in which it can be > reviewed. > > https://github.com/mozilla/pontoon/pull/630 > > >> There's already a new possible use case around the corner: >> https://addons.mozilla.org/sl/firefox/addon/pontoon-tools/ >> https://github.com/MikkCZ/pontoon-tools/ > > Let's keep track of use-cases on the wiki. I updated it to make room for > the roadmap: > > https://wiki.mozilla.org/L10n:Pontoon/API > > I think it's important to start small and then expand. The main driver > for the time being for me is to allow access to the following data: > > - Stats for a locale: supported projects, status of each project. > - Stats for a project: supported, incomplete, complete locales. > > That's why I decided to remove pagination in this iteration. I still > think we should add it as another entry point because that's what we're > most likely to need to prototype the new UI which fetches data from the > API. Once we have a better understanding of the prototype we want to > build we'll be able to design the API more precisely. > > Staś _______________________________________________ tools-l10n mailing list [email protected] https://lists.mozilla.org/listinfo/tools-l10n
