Magento GraphQL Community, 2 Aug 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Magento GraphQL Community Meeting, 2 August 2018

Description

Agenda:
1. GraphQL API returns rendered content for product https://app.zenhub.com/workspace/o/magento/graphql-ce/issues/134 (by Yaroslav Rogoza)
2. Work in progress [Mutations] My Account - Change account information https://app.zenhub.com/workspace/o/magento/graphql-ce/issues/55 (by Alex Lyzun)
3. Discussion of Show only active categories https://github.com/magento/graphql-ce/issues/139 (by Artyom Kozinets)
4. Improvement on store config by Vitaliy Boiko (presented by Alex Paliarush)
5. Managing shipping method on cart (by Misha Kotov)
6. Filter categories, discussion from ticket by Umar (Misha Kotov)
3. Architectural discusssion on cart schema mutations; Async cart mutations (by Alex Paliarush)
Host: Misha Kotov

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

Other than you started, recording okay start recording. Today we have reached agenda. We have at least seven items to discuss and probably the build a whole hour. So Misha today is our host, so I'll pass control to him.

B

Hey guys, we've got a got a pretty feature-rich agenda this morning. Thanks for joining this is our weekly graph QL community meeting.

B

Do you I'm gonna go over the agenda, or am I passing passing all right? Let me I'm gonna find the agenda again. Hang on a second.

B

Okay, we've got today, we've got some some work on graph. Ql API is returning the rendered content. Yes, laughs is gonna show that we've got some improvements on or thoughts around mutations and for changing account information. Thank you and alex is gonna, be showing that we've got some discussion around owing only showing active categories in the graphical API out of film. We'll talk about that. One vitaliy was working on further improvements for the config api. Is he I, don't believe he's joining today? So Alex did some reviews with him.

B

So he's gonna he's gonna discuss that item I wanted to go through the story that we have about managing shipping methods on card. We, we kind of put a little bit more details around that story this week. So I wanted to share that and then we've got a story that has generated quite a bit of discussion, which is filtering categories wanted to kind of iron out some details and some some some confusion.

B

There there's a couple different things to talk about, so will will address that item and then, let's see, you've got more discussions on card schema kind of advancements on what we've been discussing internally and wanted to share some thoughts around the schema and then the asynchronous carbocations. So I.

B

Will pass yes, lots about our rendered content story?

B

Hey guys, you ready yep.

C

I'm ready just share is my screen.

C

So well this request. So basically the idea is previously. If we request description or short description from a product, we get just raw value. So just the HTML, if it's there or just a plain text and it's okay for most cases, but in some cases we might have some directives inside of the rich content, for example, as for this product.

C

So you cannot do it directly from the editor. But if you enable to just plain text editor, you can insert blog widget template or so here and at the moment, in the main line, if you request the description or short description which similar approach you'll just get the same value as you see here, but on the front end, if we use such block, it's just a random block from a sample data. So looks not not very well but, as you can see, it's rendered on the front end.

C

So if you insert it somewhere in description or short description, it's rendered and the request was about to have the same behavior in response of graph to your requests. So if we request description or short description or any other field that allowed to have a rich content, it should be rendered.

C

So we use the same approach in the code that is used for front-end for templates generation, and currently we have a full request for that. We have a full request for product. We will have the similar request for category as soon enough, because we need to perform some additional actions in category resolvers and, for example, if we put a request for a bag, it's rabbit with idea, 30 and you can see among the description.

C

We can see a different sales block here. So we have all this content rendered all this HTML and not just the row value of this directive. So the same we have over here in the shell description block, so we have sales block rendered here and in that way, if you use PWA- or you just want to have the description completely rendered on your front on your side in the same way it like on the Jumbo store form, you can use and graph key.

C

All for that, so yeah I have just replaced the description, in short, description values for all values, with the rendered values. The next idea is to do the same for categories. Thank you. If you have any questions, let me know.

D

Yep actually I have a question. First of all, it is incredibly awesome to have this content much like like record, like a Content awesome now, which works only for famous blocks. If I am right, what about widgets and, for example, widgets, it.

C

Should work with widgets as well, I haven't tested with widgets, because I'm not sure if widgets are rendered in the same way on the storefront, we will have the same behavior in Baguio response. Okay,.

D

C

Believe it should work because I use the same method as on the storefront and if it renders this content different directories because I haven't tested it widgets but ability floor, awesome.

B

Thank you cool, any other questions from anyone on the phone.

E

Actually I hope. One question: did you have a chance to test use case when you do category query and then have children products and try to render a description and description from there.

C

No I haven't: do we use some particular resolvers for for this purpose for products in this case, I think.

E

So almost like we okay, this is kisses. Well, maybe maybe we can do the doctor, okay, I wrote essence as well. Thank you. Thank you for playing point man. Yeah.

B

It's good call-out, okay, cool thanks yourself. Our next order of business is to talk about the story around mutations, for my account where we allow the user to change their accounts. Information alex lism wanted to pass control to you, sir.

F

Everybody I'll share my screen, then it's desktop so I jumped in oh this ticket. Just yesterday here is live so with my account change account information.

F

It's also related to an other tickets, which is allow us to change the newsletter subscription and we decided with Misha to do it in scope of one implementation concern it's the same, call and I started yesterday was this part: will changing account information and Sharon I even moved forward to quite I guess so you can just show my work an example here we have a new mutation for customer update and I.

F

Have it's an example where it transfers the data like first name, an email in this case only goes to I just wanted to test that mutation works correctly, so they didn't found any any working examples.

F

One gentle cold with the transference, the parameters, I guess they know so in this case I hope I did it correctly and yeah. If you will just try it so generally, it's my account in Magento back-end and hereby authorized and received a beer talking for this user and yeah I can just.

F

Change the first name of the user- and it will be updated here also in a customer- account stay with an email address.

F

It also will be changed so yep, that's how it works. A bit of code, diving, I use customer graph, QL module, which is already there I added here. The customer update moon mutation type.

F

Currently, at first nervously medieval parameters as at ulta, just like star history, so I want you to test it and yep inside were solar. We have the customer altered education, so in cases a token is correct and if customer is out, the talkin is correct to chicken or another place, but here which I can use this if the user is logged in and here just getting the customer said in the email first name and saving it with charlotte point yep, that's it for now I'll proceed to work on it.

F

If you have any questions, be welcome.

B

So, just a quick, just a quick follow-up, maybe to implement the newsletter subscription field. You just add it to the same mutation and the schema, and then this.

F

Is subscribed the same as the get response? The get request for the customer.

B

Cool perfect, so it should not be much work right. Yep.

F

B

Awesome it's good stuff. We yeah I'm glad we're making headway in the in the direction of mutations. This is this is great because it allows us to allow client to build out. You know more of all the possibilities and, in my account, experience right I'm on the front end. So that's great. Thank you.

B

Cool okay. Now we want to move on to the next item, which was the discussion of what kind of categories we show on the front end around active categories, etc. So Artem wanted to leave that discussion. Go ahead.

D

He actually yesterday I found yeah yesterday and check it today. So current status present time I see on a front end. I can show you I'll show you the desktop yep right mmm-hmm. So here is an query and on the front end I see whole categories. No matter that sorry is it enable disable include the menu or so I see follow them. Even so, even today, yep yeah, oh God, so even right now, I see how them I would say. I would say we need to show only action categories.

D

That's a point: yeah.

B

So I wanted to expand on that a little bit, so there was I. Think there's another comment in at the bottom kind of asking whether this is really we should where we should be going so the just to just a frame. The discussion remember that graph QL API is a storefront API right, so anything that you should be able to anything that a customer can see on front-end should be able to be retrieved by this API. We don't want to expose any sensitive or back-end information that only the admin should have access to right.

B

So, in this case you know in active categories can be used by admin to perform certain back-office functions like create. You know folders, for our categories for promotions for for different kinds of kind of admin functions right, but we we should not be exposing those hidden ones. The point is to hide them from from the from the customer writer from the shopper, so we should not be. For that reason we should not be exposing them or showing them via the graph QL API.

B

So the graphical API should only be returning active categories because they're already seen on the front end by the shopper. So that's that's okay, but should not be showing inactive ones. Yep.

B

Cool, so the change, the change itself should be pretty straightforward right, it's just much. What is that modifying resolver.

B

And you, you haven't had a chance to actually to actually change it yet right item, oh.

D

No, no I'm, not working with gruffly I'm working with when your team and with every studio, I, see.

B

Okay, yeah it actually, the the screenshot from the venue theme showing the hidden promotions category. It kind of illustrates the point right. It should not be. It should not showing up on storefront. Okay,.

D

Huge is promotions, work out and share collections.

D

B

So one one point of discussion, maybe for for the team, is on a category. You can also toggle whether it's included in the menu or not so.

D

Actually, netsertive entourage from this option, including in the menu, only influence on a main menu, but not in a verification. Where is child categories? So in this case, if we even choose in include in a man, you know this category will be innovated mariculture.

B

Yeah so yeah exactly so, I wanted to I want to make sure that everyone's clear there that that setting should not necessarily affect whether graph QL includes that category or not so graph. Ql should only listen to the enable disable flag but not included flag right yep.

G

B

That's that has implications on if you're, here, the client and your building and your building your menu right from from this API, then you you have to you potentially need to pay attention to this field. And can someone remind me if we include this field today in our in our category schema?

B

B

B

So that's that's kind of a use case to think about right. We want to make it easy to use this API to build you so, okay, so currently it sounds like we. We return the field already: okay, cool Thank, You, Joan yep, it's a valuable improvement. Definitely, okay! All right! Let's move on here guys! The next item that we have on the agenda is improvements of the store, config story that Vitale was working on and since he couldn't join us well, we'll have Alex say couple words about it.

E

Hi guys, so, basically, this is the story which we discussed last time and we thought it was presenting me demo for this task like Ross name, and we had some comments like one of fixes, which was required was to have authorization done. We are talking and also we want to make. We wanted to make sure that we don't pass store in URL, so it was fixed.

E

Now, store is passed via headers and just to remind you that if you have some scope, relative entities- and you want to pass store tours over, it is automatically taken from headers and store manager is initialized based on that value. So you don't have to process it yourself and you don't have to add it to your all of the parameters. Just inject store manager into yours over and you can get actives to you if you need it.

E

The other point was to split it into multiple modules, and this was also done to improve diversity, because there were some modularity issues and our own request is. But we have one task with a functional test which requires store config fixture and we actually don't have it working, probably by test as normal.

E

So it works for integration tests, what it doesn't work with their tests, because in integration test it modifies application State, but it doesn't save the actual fixtures with other ways and in publicly eye tests it doesn't work because you make separate HTTP requests and if you would say, mark something some state from the test, it will be different. Basically, strategy will be different process and if you want affect the actual Magento instance.

E

So if you want to create some feature in roleplayx tests, in this case, you need to store story to database and igor malikov from Magento is right now working on implementing this feature for Google a functional test. And after that we should be able to merge this pull request. So any questions or what, without it.

B

Alright great thank you.

B

I'll share my screen. Next, if you want to stop sharing yeah.

G

B

Order of ordered items is to discuss the story around managing the shipping methods on the part share. My screen.

B

All right so I just wanted to quickly run through the story. We've we've added some details, so essentially what this? What the purpose here is is that, whenever a shopper checks out on the website, part of the one part of the steps right there you have to do is choose which shipping methods you prefer out of all the available ones.

B

So out of the box, so we've got things like flat rate shipping, we've got table rate stripping and, and then you have, you can have a number of live rates right, depending on who your carrier is things like UPS, FedEx USPS. This is this is here in the United States right, you can have other ones in other parts of the world, so the the story reads as a developer: I need to set and manage the selected shipping method on cart to support. Basically, my checkout activities right.

B

So the use cases that we come up with here are render available shipping methods on storefront. This is in order to display to the customer what what shipping methods are available. You need to present them with a with a choice right, and this is normally based on the provided. Shipping address second use case is set and be able to modify the shipping methods on the card. So setting a shipping method is effectively the customer selecting one but then also once they have selected one. They should be able to change it to a different one.

B

In case they want to do that. Third use case is request to currently shut, currently set shipping method on cart. So as you as you move throughout the checkout process- and you have already selected your address, you should be able to quickly resolve kind of a shipping. What you're currently set shipping ad or shipping method is, and then the last the last requirement there is to cover everything with API functional tests.

B

So as far as its kind of high level, what what you need to provide versus what output you expect in order to render the available shipping methods on storefront, what the customer need to provide is either a filled out address or if they're registered customer that has several addresses on file already. You can just provide us store a dress ID to the end point right.

E

B

How it works and rest yeah I think an arrest. We have a specific, separate end point for for requesting shipping methods by saved address. Id, okay and the output should be the list of all the available shipping methods right and then to set the set one set and add a new address or modify the set address on the cart. What you need to provide is the basically your selection right, your your shipping carrier, your desired shipping carrier code and shipping method by that carrier, and then the output would be still the same.

B

It would be you're currently created current with just the modified modified shipping method on that card and then to request what's currently set as the shipping method you simply can just provide. You can basically just grab that off. The cart object right, because the cart object is already going to contain those fields. So that's just a very simple graphical request to for the fields that you want from that object. So current cart is the input and the output is currently set, shipping methods or method giving, given that you requested that field.

B

So the kind of the next steps on the story are to figure out, for example, for for this use case right here. In order to render available shipping methods, we need to decide on what is the minimum number of fields that need to be provided in order to get two requests available. Shipping methods right so different carriers may request or may require different fields in order to return potential shipping methods. So this is this- is kind of the next step to analyze the out-of-the-box shipping methods in Magento and figure out.

B

What is the minimum, like common denominator, minimum number of fields that, across all shipping methods that we need to provide for this end point to work for all of them right? So, if any one, if any one of the calls has expertise or familiar with what those fields are potentially, then it could about. That would be they'll be great. Otherwise, when you all need to basically dig around in the api's for each carrier and figure figure out that those fields and.

E

One point for what the story is that initially we learned to have unified lead guys for customer and guests and right now you can see that there is potentially some divergence here like you can request shipping message by address or you can request by address ID for customer and ideally we should think how to unify it and do not have a live different. It guys so most likely. We should do this by full address all the time but like if you guys have any concerns about this. We can.

E

We can discuss so at least I would prefer not to have different it guys for customer I guess it will simplify client-side applications.

B

Yeah exactly so any any comments for use cases, or maybe something that we missed here, any other functionality that you guys think would be required in order to work with shipping methods. On the cart.

B

All right seems sounds like it's pretty straightforward, okay, so on to the next idea. The next item here is to discuss the filtering of categories and I'll just jump to that I. Don't know if I remember correctly, alright, so this story, we've had several kind of rounds of questions about. What's what what already exists, what we want to build, etc so just to clarify something, I think about the existing existing functionality.

B

As far as search criteria that's available in the service contracts we I guess we arrived at the conclusion that we do have currently search criteria available for categories, but.

E

B

List, that's right all right! So to get a used of categories you are able to provide a search criteria right anyway. The question is what kinds of fields are available to filter by today, but apparently that's not very, very easy to find out that list. We've we've come up with several here and wanted to basically implement that so Umar I know you had some quite you. You try to pick up the story and had some questions around how to how to proceed in certain aspects. Do you wanna?

B

Do you want to kind of ask your questions here and we'll we can discuss as a group yeah.

G

Thank you so much so. The first question is: if we go through the trend, query mechanism of fetching a category, we can only provide ID and then we can fish the whole category tree for that ID.

G

If we come to this issue, user should be able to filter the categories on the basis of name SKU or either anchor or something else right. So my question was my first question was: do we need to filter the collection of categories I mean, for example, there is a category which is going level to whose name is, for example, men, and there is another category whose name is women.

G

So if someone filters the category by like writing a Mian, so do we need to load the list of I mean load the list of categories, so the men and women should be on the same level or do we need to specify the ID of the category plus these filters will be only applied to the children for dead category like if, if you have specified men so- and it is one, for example, force level- and you are fetching a category which is on second level and its name is like clothes.

G

So if you are fetching clothes by providing ID, for example, 31- and it is getting the complete tree of clothes and in some depth it has a category whose name is men, so will it be loading only men and note other categories, or will this rule apply to the collection of categories.

B

So I can try to answer I, guess first and then we'll we can. We can discuss so. The the point kind of the purpose of the story is to is to be able to provide some criteria and then get a list of matching categories back right. So if, if we do that, then it seems like it makes sense to return, not just one category like we do today. So today's end point: has you provide an ID?

B

You get one category back and then you can kind of pivot to see its children to see its parents potentially etc and work with that one category, because because this is kind of like a search, you expect multiple entities to come back. We we have been. We have been discussing changing the send point, two categories: plural, exactly and then providing like like what you were saying.

B

Some sort of filter like we do for products based off of certain fields, like name like potentially level like potentially I, may need to add parent here, because I think that would be useful as well and then be able to. You know get a search result effectively of categories which will be, there seems like an array would be the way to go. It's.

H

G

I think so, if we are searching through a name and if someone has specified the level, so it means, for example, if someone specified men and in level he specified too. So it means that and he is using like operator in the search criteria. So it means that it should only load the second level categories which contains the men as a like text in the name field. Yes,.

B

Oh so it would be a logical and right kind of kind of like we do with product.

H

B

E

We can think like what would make sense here. Yeah.

B

It seems like so that is a query that you should be able to execute and get results back. So that's that's correct. It's as far as logical, ands and ORS. It should probably follow with products. I think there's an implied, there's an implied, and if you just list a bunch of criteria but basically.

E

We have to define nucular so right now we have special type in bronchial or filters like input type, and you have to probably introduced similar filter for categories and say: do you.

B

All need to think about that. That's that's good! I.

E

Don't think we need like.

E

And sozin, probably also if you want a shorter but filtering for sure,.

B

Yeah yeah, so we can yeah. We can discuss that I I know you know for large stores. It may make sense to be able to paginate.

G

If he specified some like only the name field and then all the categories should appear and within the results we can like get the level of Ted category plus if a user specifies the children, so the children of Ted can also be returned.

B

Yeah, so that's what I think that's what Alex was saying is that in the results, you expect an array of what we call today. Category tree objects which basically the the the the it's a category that you can expand to see its children, but the maton. The the category itself should be the category that matches the criteria, but then the children, I, don't think, should be filtered. So how I.

E

See this change right now, so what we have right now is you just provide ID and in response you get the cater, the category which matches this ID. Basically, all three under this category and after we implement this task, we can specify search criteria and get basically multiple trees. So you will get on top level. We will get categories which much search criteria and under each category you can potentially fetch the whole tree like requests and additional children. If you need to so looks like this, is the reticle again any comments. Cuz I think.

G

If, if we are loading like two entities, for example, just considered- and there is a category on the level two and on the third level, who is the children of the second level category right, if both of them contains, for example, ABC and I- am searching with the query ABC, so it will give me the result of the level two category plus level three category as well.

G

So if I am including the children in the query as well so in case of second I am already getting the third category as a children and in case of third I am also getting the children. So you can see these things can overlap between the children of poor.

E

Yeah, it's probably fine, because you're you're building like separate keys, so you are interested in specific categories. We should get by search criteria and then you can request like anything from that category and and three is basically proper to your specific category. So.

G

We need to. We need to get the list of trees, no matter on which level it is it only matters if we specify the level in input parameter, field, correct, yeah, correct, okay,.

B

Cool, let's see I can remember if there is any. Oh, oh yeah, one more thing on on this item that I wanted to discuss is I asked this in the channel yesterday and I've got one or two responses, but basically a filter filter for categories that is based on product SKUs. So the way the way the idea is that you provide to the filter.

B

You say you know product, SKU, X and then in return you get all the categories that contain Product X and furthermore, in addition to that, if you provide a list of SKUs, then as a response, you get a list of categories that contain all of those excuse that that was just an idea that we came up with. We didn't really get a whole lot of kind of real-world use cases for that functionality, but wanted to ask around to see if anybody, if anybody can think of anything, that this would be useful for I.

G

Think this should be the part of products and point right, so you can specify the SKU and in the like result, field you can specify the category and while in putting the product SKU, you can also place the filter like equal operator or like operator. So if the SKU matches, then you can get the categories of dead product. So I think it should be the endpoint of products, but not categories.

B

Yes, so you're right for for the use case of providing one SKU you're right, you can use the products query for that and just query the categories field, but for the use case of providing multiple SKUs I, don't think you'd be able to use that endpoint, because what you get, what you get in response is a list of products right and not, and here you get a list of categories.

G

All right so I don't think so. It is very important in this case because it doesn't make any sense right now like in putting multiple Eskie use and finding the categories in the real world.

B

Yeah, that's a good point, though, that for one SKU doesn't make sense, but potentially okay any does anyone else have thoughts on.

E

Extensive Gomez, oh, we can always add new filters. You can always add new fields if you need to so it's not a problem to address beneficiation it. Okay,.

B

Cool, if every it's, no one objects and I'm gonna go ahead and take this out, we can add it later. What I did what I did to adhere, though, is the ability to filter on parents ID.

B

So, if I wanted to, if I have this as a condition, then it would only return to me categories that have the same or the specified parent category. Does that make sense, I'm.

G

Sorry, can you explain it further sure.

B

So this is again, this is a filter for four categories. Right, so I can provide I want I want to search for categories that have, for example, a certain name, but also, if I provide a parent ID. Then I only want those categories that have the specified category as their parents in the tree.

G

B

It makes sense.

G

B

It's basically a condition that you can provide to look for I guess it would be siblings, sibling categories right that have that all roll up to the same parent. If you wanted to yeah cool I'm gonna swap out one for the other, all right, any other thoughts on this one from anyone.

B

All right, hopefully we- hopefully we unblocked you for now we can. We can take this into account. I made a note here. You know we can try to provide more more guidance, but really your products, products and products. Filters are probably going to be your best reference point for implementing this all right. So last item on the agenda, or maybe a couple, we have just some updates on determining the schema for the cart, object and I'll I'll. Let Alex talk about talk about that for a second, so I'm gonna stop sharing.

B

B

Suppose I should distinguish between the different Alex's on the call, so I'll call you guys: Alex P and Alex L.

E

So what schema for?

E

Yes, so actually I start the discussion about this mass meter and know we already have one initial proposal for basically initial draft for adding items to card even graphical mutations and I have posted the link in our graph collection. So anybody is welcome to join and review it, but I'll just give an overview in my ID, because it's just convenient to it here.

E

So we discussed like all these items, so I will probably skip this front section for now, and we also had question about a synchronous, server-side mutations, we'll probably get back to this after I, give overview for post-chemo.

E

So one of the main points was that we are going to have separate mutations for each product type and for each chip out step and for now you can see proposed scheme of four mutations for 18 sukar and we can probably start from simple products.

E

So what is proposed is to help first of all, like routers for all inputs and all outputs, and this will allow for potential extension aggregation and basically the reason why it is important for input, for example. Is it because, by default we cannot extend the list of arguments or shrink list of arguments from different model sake? I, don't think like merging.

E

Do will help here, but if you define special type, we have schemas teaching functionality which allows to schemas from different modules and in such way you can extend the list of arguments or I mean you can assign list of fields, but fields eventually become departments here and.

E

We request car ID in form of cash and we also request array of card items, so we always work with race here. Even if there is no current use case, let's say for configure walls and shell code at least I, don't know such as case in UI.

E

We have similar use cases for simple products when you go to customer comment and want to add multiple credits by school and specify a quantity for each of them, so it can be supported by this mutation, so you basically provide list of car atoms and each card item is represented by in case of simple product, SKU quantity and customizable options, so just to clarify how the decision was made like what fields are required for input.

E

You just imagine that you are customer on product page and you want to add specific product to cars, and you just need to instantly good input is required from customer to add this product and that's it. So. First of all, like you need to know like what school is. What's, who you are adding? How much of this product? You are eighteen, its flow, because it's possible.

E

This is not quantity and then, potentially, you may need to specify customizable options it specific. If this current product has any and custom options are represented as an eraser product can have multiple custom options like it's not in cheese, and in this case you need to specify ID of each option that is available for the product and select it value.

E

So if customer basically goes to drop down and select specific to option, I'm sorry custom option, so can the drop-down can be like texting, wouldn't be any field, but eventually it should be possible to represented as a string. So in we asked like what customer ID is and what value and in response we should be able to get any data of the cart. So it's actually discouraged to fetch the whole cart object. But if you need specific data, you should be able to get in response.

E

Ultimately, in response of the mutation, this current object will be card. Type will be extended from different parts of the schema. So, for example, we will eventually have here like shipping, my cells and payment methods and all information that is applicable to Cart buttons. Coco, not int investigation, we just have items called items, so we are adding card items and we show how we can get our items in response on the card. So when we will be grading, schema for, say, alien shipping methods. What specifying shipping methods?

E

We will also extend card schema with a devotee to fetch, select the chicken method, so carte items are in like array of atom interfaces and for each item you can get idea of the item. You can get quantity.

E

So it's basically like one item in the shopping, cart and you can get any data from the product associated with this car item. So you can potentially dig down and get like anything. You need from images is a good example. Yeah, like images like product title product URL, which you can basically use to to render existing shopping experience and separately.

E

We will need to get Rice's and one on options which we can see. That was to say that okay, storefront application, like java application, for example, can take information about prices from product and then somehow calculated based on discounts based on quantity. But this is probably not the safest approach, because in this case we will split price calculation logic between begins and storefront. So it's and that's why, for now discard prices is very limited.

E

It's not how it's supposed to be eventually, so we want sure we should be able to get any prices which are about the product, but this process should be calculated for cut item, so you should be able to get like price information and you should be able to get public press information. You can get from interface, but subtotal, which is taken into account discounts.

E

Potentially it has taken into account. I wanted T on the items added to like a specific product. So let's say if price of product is like five dollars, subtotal can be say: fifteen. If you have three products of the same type edit to so this item will be extended and now then we have like simple item so and its implementation of item interface. So you can see that all product types will have these fields.

E

But if item is represents a simple product, then you may also get customizable options and why customizable options are not part of our generic interface because they aren't available for our group products. For example. That's why it's not relevant to put them in a generic interface. So all product types may have custom item interfaces.

E

So then you can get like a customizable option. So it's an array and potentially you can get all selections which customer made while adding simple product to cart. And here we can get like selected option edgy option label. Then you can get like option type say the drop-down. No, it can be so that it can be like notice where and you can also get a list of values.

E

So well is an array because you can have multi select, and in this case you need to provide multiple selected option values in case of drop-down, for example, it will be just array consisting of one item and you can also get sort order to instantly how you should rent it like what order should be used to render selected options and same for value. So you can get value.

E

Id value label, value price and say: okay, option value, price and again sort order, because you, you may roll that and you need to regulate proper, and we can also take a look at some other types. So this is the most complex one because it contains generic right here. But let's, let's just go, make like one by one and we have vector Minister. Do you have anything else on the agenda notice? It was that the last.

E

So we also have mutation who I didn't want or products, and the idea is the same. We have like wrappers, but then there are some customizations that say here. So you have bondo item which, in addition to school quantity and customizable options, first bundle options and one of the options basically represented. So in case of bundle product you can have ID of the option. You can have a number of items added and potentially you can have multi select again for one though like if you usually spoke to select about.

E

Sometimes you may have noticed that that's why value is in right here and just as a reminder. So basically bundle product is when you have, for example, different kinds of random, different kinds of hard drives, etc, and you want to assemble your computer, so you can select, let's say one of car drives or you can select it right and you can specify quantity for each of them and the same like for around. You can select type of RAM you want and it can have like different parts potentially.

E

So this is a new state for a new product and in the output. So if you want to get account information here, life is a consultation or we will introduce separate query to get card information. So again, you can get customizable options and you can get bundle after bundle options and such bundle option I can have like label like. Is it like rank, so it will basically be like RAM.

E

In this case you can get type, so it will build same mode select and you can get like selected specific products which are selected for RAM and again you have short order and for every product which is select from this multi select of different gems, you can get like quantity. You can get basically title which is label and you can get price of a selected item and again you can have sort order just for display purposes.

E

So in configurable, it's similar to simple by the class configurable options and configurable options are just ID and value because, like it cannot be multi select so which configure go. Option combination basically is represented by simple product, but eventually you must have select in configurable, and in this case you can say like what is configurable option ID and what is selected value and value is in because it is also not arbitrary string.

E

It is just a specific option lock and when we display configure about projects, products and card, you can get also selected considerable options again ready and for each option. You can get option label well available and IDs of the options so for the notable product you can get the notable links in addition to what you can get from I mean set in all the buildings. In addition to what you can set for simple problem and the notable links are represented by IDs. So it's just a list of ideas.

E

Potentially you can sell, you can have one global product, it can have multiple files, Odin Lord and it's possible to set that each file is sold separately, but it will be like still like same global product, and in this case you might have multi, select and thriving. It's like array of select clinics, basically you specify which files from this product you want to buy and in most cases you'll probably do just one item, but it's possible to have it like it's more item and when you display the mobile product items, we basically say links label.

E

This is just a configurable way to say would say downloads much attention to it, and then you also specify specific links which customer selected so to be like green candy and label for display purposes in shopping cart. You can specify which things to swipe. It probably also need to add prices here.

E

And then we have gift cards, so forgive cards. You have sender, name recipient name, I, give got moment, you have message and you customizable options and you can fetch same data back.

E

Group products are very similar to simple products, and the only difference is that it doesn't support customizable options, and it's why we need just imagine it that.

E

Simple we discussed and virtual product has it's basically the same as simple: it doesn't have weight, but it doesn't affect interface that much and the only reason we have it just a syntax sugar to to make it clear that, let's say, if you can specific product type, you will have specific mutation for the prototype. However, it's probably possible to with a head usual product using simple product mutation and will probably work.

E

So when it's not actually I also wanted to get back to one item which is key, so we have couple minutes it's about a synchronous, server-side and mutations mutations, and we actually had discussion regarding this internally and here you can see some discussion like meeting notes from from the discussion about so horribly believed that if you implement a synchronous, server-side implementation, if you complicate developer experience for client-side developers, because you will have to say, send requests to add product to card and then you will get some operation ID in response and you have to pull similar to get status like.

E

Is it done it? Is it done? If it's done like you, you just get four spoons and then you can get to some cases. When you say you add product in one step, you implement optimistic, UI and assume that it was successful, but they don't get response. Then you go to the next step and you start selecting with a shipping method, and then you see response from previous step say that sorry there was not enough quantity of the product.

E

You cannot go next and then, like you, I have to figure out like how to process this exceptional situation. So basically you is becomes much more complex and according knowledge, this is not the most so just to confide, maybe like the reason behind the synchronous. Server-Side intimidation is just to improve performance and to prevent bottlenecks in case of, let's say, spikes from user cycles.

E

If you have spikes in activity on your side, you may get basically down, and if you implement a synchronous, server-side implementation, you will just put all queries to queue and then we just can process it like gradually. You will get deterioration on the experience, but it will not be like several down and we believe that most of these cases should be fine without the synchronous operations, and only several like larger merchants may may need this, and you can probably do a synchronous, graph, QL implementation, similar to what we did.

E

First, if you know that we have rest implementation in Washington on separations, with the help of most way Alexandre zone and potentially implement something similar on framework level for graph gel. And if you, if you need to and cannot burn implementation, and we are implementing it as extender of graph here- synchronous, server-side limitation, but just to remind you- can still do a synchronous, queries from client so yeah. Basically, if you have any comments on this completely reach out to me directly, all right and graph kill channel.

E

A

Thank you Alex. We actually out of time so some participation, you can ask your questions from the chat. So let's continue discussions in this.

B

Was our first full hour meeting so thanks guys for for all the work that you've done, that needed to be discussed so very, very glad to have so much activity on this project.

B

So thanks a lot, everybody I'll see you guys. Next week, I'll see you guys on the chat, yep same I.