Magento GraphQL Community, 31 May 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Magento GraphQL Community Meeting, 31 May 2018

Description

GraphQL Community Project Wiki: https://github.com/magento/graphql-ce/wiki
Mind Map: https://www.mindmeister.com/1094880388?t=a5LVAQ71Vq
Backlog (with Zenhub): https://github.com/magento/graphql-ce#boards?repos=128075669&showPRs=false
Backlog (without Zenhub): https://github.com/magento/graphql-ce/issues

Zenhub Chrome Add-on: https://chrome.google.com/webstore/detail/zenhub-for-github/ogcgkffhplmphkaahpmffcafajaocjbd

A

All right well, then, we'll go and get started. We've got a couple of us here in the room again, my name is Misha. I've got Alex with me, we're in the graph QL team for Magento, and this is second round of grooming, of the backlog for graph QL Phase, two community project, so where we left off last time is we went over the backlog, the mind map and through a few of the issues that were in our backlog, column, which is kind of ready for discussion before that can be accepted into implementation.

A

But we wanted to start off this week by giving some kudos to guys who have contributed last week to the project. So we had we merged a few more issues since our since last week and I wanted to show those issues.

A

That's not the right one. One of the issues that we merged was including products in the category query. So previously, when you query category, you were Nate we're not able to see what category what products are associated to that category. So this pull requests addresses that issue and big thanks to Facundo for for doing that, work.

A

And the second issue was.

A

Which is she was it.

A

This one right now this was much previously I, don't see you here, oh.

A

Here we go, this is the one. This is the issue, that's a second issue that was merged this week. It was fixing the URL resolver and to support relative path and there's some issues with a leading slash, basically on URLs, so big thanks to this big new for for doing that work. When you really appreciate the contribution.

A

Okay, so now that we've got that under way, we wanted to start off with discussing a few issues that are in our backlog, column. We pulled over these issues to groom in these sessions and the first one that we wanted to start off with is query caching, and for this one there's been some discussion by some of our community members and wanted to hit on some of those points. Today.

A

Alex and I have discussed this kind of internally, but maybe do you want to give an overview of what what the different potential approaches are and what the issues.

B

Are yeah, so the main problem with sketching graph queries is that those are usually made with post requests and there is problem discussion, post requests with varnish because varnish doesn't give you access to body of the request by default and we have basically two options: how to make graph kill queries cacheable with varnish and like the first option, is to install extension for varnish, which will allow you to parse the body and include body into cache so and this option will work as follows.

B

So basically, you do regular explain expression to understand if this is query or mutation, because clearly invitation will be sent using same post request, GT post request as soon as you figure out that this is query, you have to basically extract the query itself and instruct varnish to include it into the hash, and then it should be possible for orange to cache it and on the next post with the same body, it should be able to fetch data from cache and the main problems with such approaches.

B

First of all, additional dependency for varnish extension and second I. Don't believe this is pretty standard approach for now to use varnish flotation poster class, but it seems to be technically possible and the other option which we see at the moment is add support for get requests on outside and basically what it means. As you can see on the screen, basically, you will be able to include query, get parameter which will which will include like full draft Keo query in it, and in this case it will be.

B

It will be possible to cache it using native varnish functionality and basically, we can mimic behavior that we currently have for page cache. So we will include HTTP context there and, like any cache, related headers, and the problem with such approach is like couple problems.

B

One problem is that query lens is limited, so HTTP GET query is limited to two kilobytes, so it may be problem for some clients, most likely it'll only problem for majority, but it can be a problem for some clients and as an alternative for such use cases, it is possible to use post requests or is possible to split this query, like get query into couple. Other queries.

B

If you do it like, we sports that it will obviously be not catchable, so you are losing testing capabilities in this case, and the other problem is that you will basically get two different ways of performing the same operation and it gives you just high potential for box and client side developers. They can by mistake leverage, post and not knowingly just bypass cashing in this case. So this is something to consider and we've got great input from Paul and basically he describes some technical details, how they did it in the implementation.

B

I believe they have their custom implementation of graphical Magento based on service contracts and obviously they face some of these issues already and thanks to Paul for providing some insight on and suggestions for, implementing.

A

B

So far, we basically leaning towards the option with get request, because introducing mandatory dependency for varnish is not an optimal solution and the first option seems to be more seamless to integrate this current implementation of Magento.

B

And basically, if you go this route, we will have to add support for get queries on graph filled framework. This should not be like a great effort and then second part. We have to add something similar to our page cache to our graph.

B

Click here is to basically take those cache properly and make sure that we have opportunity to rotate it and the three processes TTP context correctly and just a non so shitty bit context basically holds information which is unique to current user, for example, it can be user group or it can be current store view, or it can be current like Halo or something like that.

B

So basically, whatever the effects catalog or like current currency, whatever effects presentation of catalog, it can be included into TTP context and basically, all those items will be cached separately, and that is what we use in page cache as well.

B

So that's basically an overview yeah.

A

Thanks thanks talks for that. So this is why it's currently tagged as a large-size item, but we've got a we've, got a pretty good idea of how to at least approach approach this implementation and as far as priority this item is gonna, be high ranks pretty high on our backlog here, because.

A

Because this is something that's basically a piece of a framework that will have a benefit for all the subsequent end points and and queries right that we developed so this is, it just will continue creating value in the in the future. So we think that this is is pretty important.

A

Okay. So, besides this story, we went over a few of these on the last call and that recordings been posted in our on our wiki page.

A

Maybe I should mention one update to our mind map here. So let me go to.

A

The road map and open up a visual.

A

One item that we that we added here under the framework area or track is the graphical subscriptions story, so that's effectively was suggested by Paul, also in our no slack channel, and if we open up that story effectively. This is enabling a developer to subscribe to events that are triggered by graph QL mutations effectively, and so there's there's a reference to a write-up that was done in relation to Apollo, and this is but this on on the high level is I.

A

Think pretty straightforward right. Is it's a it's a publish, subscribe mechanism before for events, and then it needed it. You know we need to add support for this in the schema and the use cases are just subscribing to subscribing to events and it's kind of a many-to-many relationship. Here a single subscription can be triggered by multiple events and then also, conversely, a single event can be triggered by multiple subscriptions.

A

So I think that was the only addition that we've made to the mind map so far since last week. So back to back to the board, I'm gonna try to remember where we left off and we'll continue discussing those items.

A

So I remember talking about stock data. We I remember talking about this documentation, URL resolver. This is effectively just I, rename tasks right here, and so it's mark as a bug in a small issue at POC arm mutations. We briefly touched on that last time. This is just figuring out what needs to be done if anything, to enable mutations in the framework and depending on depending on what it is, it could be either a large or a small story, but there's a possibility that it was just work with the current implementation.

A

This one is the caching epoch, so we touched on one of the stories under that umbrella. This is an epic for check out coverage, so we won't touch on that.

A

Let's open it looks like we've got I think four issues here that we haven't yet discussed.

A

So this is a story to be able to return, resize image paths and I. Think the I think the purpose or the goal is to be able to query for dimensions that you need of a certain image and then be able to get a resized image back from from the server. So we had some. We had some discussion here, Paul kind of offered some of his some of his thoughts on this issue.

A

I think they've got a library that that they make use of, but his his biggest feedback was that this probably makes sense on the level of the general API, not not necessarily specifically for graph QL, so that other you know, Web API layer is like rest potential. You could take advantage of the same functionality which I tend to agree with so.

A

For now, did you have any more? Did you have anything to add to to the story from that from a technical perspective, I think we should consider it as an item, probably of like Paul, suggested general API knots, not in the specificity of graph to all I mean it should be exposed to a graphic you all if we implemented, but I feel like it'll, be valuable for footrest and others as well.

A

So we'll we'll work on actually, probably it could. The story can benefit from a little bit more details. So I can try to add. Those in next story is around query. Complexity. Limiting this story is under the security, slash framework improvements. Epic I think it's currently an assigned to a framework improvements, but it's in that it's in the spirit of of security. So it reads: I want as a developer.

A

I want query complexity limiting within graphical framework, so that my store is not vulnerable to attack by issuance of highly complex queries to my graph, QL server so effectively. This is a piece of the framework that would evaluate queries that are issued to it and if it passes, surpasses some threshold of complexity, then it would reject reject the query with appropriate messaging, but anything under the complexity threshold would allow to be to go through and processed by by the server and we've got.

A

As with most of these stories, you've got some acceptance, criteria, talks about functional test and, and the use case is specific to to the story. Yeah.

B

And also I would like to add that this feature is supported by bubonic's library, which we are currently leveraging, and that's why it should be straightforward to implement the support of query complexity. Limiting, however, as with any support library, we need to test it and make sure that it actually works. And that's why estimated size of the issue is medium and not small. But it might turn out that it is just a small issue and it should be pretty straightforward to integrate this.

A

Thank you that he has definitely helpful.

A

Okay, let's look with the last two looks like they're, both Markus. These are just bugs. Let's see.

A

It looks like currently the list we have a. We render a list of filterable fields or fields that you can that you can filter by.

A

But some of these that currently come back are not even returned by the storefront API. So we need to just take them out of that. That list that that renders the the list of things you can filter by contains some unnecessary entities.

A

So we would have a list there of things that should be taken out, so this should be relatively straightforward as well, and you can see it's marked with a good first issue and a small-size to be tackled.

A

Last one here again, as this is just effectively a bug, so the the purpose here is that currently we render some product attributes that are not intended to be shown on storefront, where the exposed on storefront at all. So you can see if all of these preferences or at settings for a product attribute are set to. No, it shouldn't, be, you know, used in product listing shouldn't, be used in product sorting or visible on catalog pages, comparable layer, navigation, search, results, etc, and so this these attributes should not be passed on to the storefront.

A

So this is just a story to make sure that that is, and that is aligned.

A

You I think we did a little bit more investigation here that we can that I can add details around. So some of these settings for product attributes are how they related to store trend. So I'll add a couple more lines of details here, but this I think the the spirit of the of the story should be clear.

A

All right, so we have now gone over all of the stories in the backlog column. This is again the column that that that contains more or less issues that are ready for for inclusion in a sprint or implementation, I think for next meeting we can. We can work on adding a few more down here from from the our general backlog column, but in the meantime, if anyone has capacity or is willing to, you know take on issues these. These are the issues to pick from.

A

We have 14, they might include a couple epics here which shouldn't count so maybe around a dozen issues that are ready to be picked up and worked on, and we from our side for for next time will work on adding more and I. Guess, there's there's a couple more. What is in progress and one is under investigation here.

A

Alright anything else, don't forgetting no good cool, short and sweet. Let me make sure that yeah, we'll post the recording on on the wiki page as always, and we will meet the same time next week thanks everyone bye thanks mine.