Magento Architectural Discussions, 18 Sep 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Magento Architectural Discussion -- September, 18, 2019

Description

- GraphQL custom attributes container
- Changes in product pricing GraphQL schema

Meeting minutes: https://github.com/magento/architecture/issues/273

A

Just one item.

B

You should see proposal now. Can you see it.

B

Okay, so the proposal is related to custom attributes in graph QL, specifically like AV a tribute, and the problem is in some gentle installations. You may have tens of thousands of Eevee attribute and those attributes usually belong to thousands of attribute set and just to clarify so attribute set, is representation of specific product type, so, let's say t-shirt will have 100 set.

B

Shoes will have different attribute set and if store is seven thousands of different product types and it's possible that there will be tens of thousands of be attributed defined by merchants in the store and the problem is when we try to search products in catalog. We do not know in advance what attribute sets those products will belong to. So when you search for the read product or some other keyword, you never know what kind of product will be presented in results and also, as you may know, graph kill doesn't support like get all fields.

B

Types of queries like it is in wrap. In the rest, it is pretty common to say, give me all product fields in graph kill. This is kind of anti-pattern and it is not supported.

B

So you have to explicitly list all fields in the query: the fields which you need to render eventually- and this is verbal for us because since you don't know in advance what fields we need, because we don't know what good sets will be like in response, you have to list all possible fields in the system to be able to render, let's say all applicable, IVA tribute for search results and as you as you can see in case of tens of thousands of attributes, you will get the query which will have to list all those attributes and it will be pretty heavy on bandwidth and really size will be huge in this case and by the way so I didn't mention.

B

How can you get all those ten thousands of attributes of the dynamic? You can use introspection on product interface since currently released all IVA tributes infrastructure in product interface? You can get a list where introspection, but, as I say like it is not solving the issue completely because criticize will be huge in this case.

B

So proposed solution is to introduce container called custom attributes and it will contain array of attributes each attribute. You have code and string value string value is actually JSON encode into an encoded value of custom attribute. So in case of actual attribute value, beam of type string. You will just get string because gesture on college student is a string in case of array. You will get just json encoded already.

B

It's also possible that there could be some objects. I, don't I, don't believe we have any Eva tributes as object by default, but it's possible that somebody will create custom attributes represented as an object, and it should also be supported without any modifications to the schema.

B

So flat representation of custom attributes in product interface, category customer or other alien entities will remain intact for now, so you will be able to query all attributes. All custom attributes is in container or you can explicitly list all necessary fields, and in this case you will get type check by schema and it is just better for performance and it's necessary to keep in mind that we're in all attributes like with this container may have performance impact and that's why basically graph kill, does not you'll command. Heaven get all data by default.

B

So this is a proposed solution and also some alternatives which were considered. One is persistent, persisted queries which is not implemented yet, but we have talked for it and persisted clearly. Basically, there are like two different varieties: one is server-side persisted queries which are defined by admin and serve as white list of allowed queries for this specific gravity or API.

B

The client will have to know hashes, which map to specific queries and then client sends hash and server identifies what query was expected to be executed and execute this query, this type of persisted queries solve those attacks, plats and basically it potentially prevents execution of heavy queries, because admin of the of the side decides what queries are allowed on. The specific mention, for instance, second type of persistent queries is client side persisted queries. This is when client sends query initially to the server and server gives the client cash for this.

B

For this query, so server persists, client, defiant, query and just generate some cash and on subsequent queries, client will not say valence and the whole query. It will send hash as we can see for the problem described here.

B

The main issue is that the client has to send P, which query list in tens of thousands of attributes and in case of client client-side, persisted queries. We can avoid this for all subsequent requests, so it will still be a problem for the first request, but for all subsequent various, the actual request will be replaced with the hash.

B

Additionally, to improve to improve flexibility and a lot of support for complex structures or custom attributes, we can introduce type like over here, so it will be custom attribute and then field called type, and it will it's possible to give some hint to the client how exactly to decode the value received in here. So if we want to support some own objects or other complex types, it's possible to extend the schema for now, I, don't think we should do it. Probably we can extend it later. If you have some relatives cases for you.

B

Additionally, value of custom attribute like this value. I can have more strict type, so it can be not shrink, it can be say Union or some other type again, it's possible to consider this later. But if somebody has use cases which definitely require Maastricht type here we can, we can consider it and the last option you had was to eliminate flat structure, listing all custom attributes under product interface directly and other evil entities and completely rely on the containers from now.

B

We believe that this will cause they've, experienced degradation and that's why we do not want to go this route and we also don't see how we give any benefit for production deployments, because if you do not query those fields, they will not be fresh. So basically, whoever needs container. They will use container where, when it's specific pill strictly defined fields, they will use those fields.

B

C

Offer custom attributes we want to return all attributes.

B

Water tributes you want to return, an extra doesn't make sense, because if you know what attributes you need, you can query them directly, and this case is for client, which needs to render all applicable a via tributes on another product, page or actually. On category listing page.

C

Cont in Magento admin you can specify that this attribute is visible.

B

And it will remain the same, but I thought you. You mean to get subset of applicable attributes for products, so that will not be supported for now, we're not going to provide any filter, say: okay, one of the options could be to have filter over here. So we can provide arguments for custom attributes and say give me just color, but again as I say, it doesn't make sense because you have access to color by in the color field director.

B

So if we decide to eliminate flat structure for attributes, then it's possible that it will make sense to have some filter over here. But for now, since we do not remove structure I don't see, why would it make sense.

C

And why be name is like custom attributes, not just a tools.

B

Actually, this is a good question. It's probably coming just from how we named it internally I believe it's even better to name it somehow the dynamic attributes or we can come up with a name. It's.

B

Actually, you're welcome to give you a suggestion in this proposal and you can say: hey whether there is some potentially better naming or client or it's better to keep existing naming convention system service implementation.

B

Yeah, maybe, but again feel free to leave your comments.

B

D

His calotype for violators.

B

Yep, so that was that was one of options we may consider introduced.

B

So if you have specific proposal and times you can I personally believe.

D

Just some different reason out, but it's too too broad that looks like that. We don't have other good.

B

So what okay is talking about is this statement which alternatives considered. We can actually talk to double team, and I am team, will be the first clients or this and see they need type if they I just don't want to introduce fields, if we don't actually need them, and it's much easier to introduce new fields later than to duplicate it and remove it. If you don't need it. Okay,.

B

It should be easy.

E

B

I just throw this proposal a coffin, our.

A

Could you add real scenario like you described in general, both because I understand you're, trying to solve the problem or product page right, probably for product listing it's not applicable in product listing.

A

D

Actually is a problem here, that's you don't know.

A

You're not going to.

B

B

C

C

C

E

D

Problem here is you don't know which attributes you have to request? In the same time, we definitely know that our products as usual do not have as so many attributes. So we are pretty safe. We don't want to return millions of actually this parish. In the same time, examples it's a tree mentioned deplete. You cannot predict attribute set of products as you'll be returned by yourself. Oh.

D

Let's keep everything straight forward, have exactly the same variant, exactly the same behavior for this thing and and PGP.

D

Responsibility of render and.

A

How, under a mouse renderer.

D

But it is okay to declare to request metadata as for me, this is not okay to have a dynamic credits, because.

C

Product page on produce page, there are no such problem because if you know.

B

C

This functionality, pressure for listing this person, probably is not for product page for profit, especially always can just request all reverse filter in the way you want and for one product show it's distributed in the way you want.

B

Apply more strict rules for attributes like to have to to pay attention to this flag, using lists and using product list if you use it by default, means that for product page, which is going to use the same query, you will not get all attributes correct, so you will get restricted by that use in product listing.

B

There are actually two ways how to resolve it. One is to use metadata, separate metadata services anton mentioned, and second option is to include metadata in response for attribute. We can also consider that option.

A

In general, I think just.

A

Scenarios that you want to cover the Kristin problem, product page right and maybe at least a high level, how? How the client record scenario and look like in the client yeah.

C

And statements that we don't want to show all attribute only with options so on start front, yeah.

D

B

Fun but looks like we also need some metadata right to differentiate between category and product page. So what do you think about including metadata into response directly?

B

Does it make sense or attribute innately, whether whether to show it in product listing, for example, I.

D

Disagree: v6 because these attributes motivate a you always know that this is not something that can be changed frequently in case we. We will move this data into this container. We lose this possibility and we always will have to perform some logic to ET Achebe's metadata. At the same time, it will increase the size of response significantly because with each API Goods, we will have to the tool man sound flex.

B

Discussions for advanced search, so we need to figure out what Hills should be rendered on advanced search page, and we also need some kind of metadata query which will which will allow to return all applicable fields. So we might have one video there and then we can probably have not a query for getting attributes applicable for product listing page.

C

Yeah I agree that we definitely need some additional service to retrieve information about the table. If you don't help.

B

So we have, we have a service, but the current service requires you to list all attributes which you need metadata about. So there is no service which gives you a list of attributes applicable for advanced search. You cannot do that at. It is in coverage and also.

A

B

I said, like we can add another query for getting all attributes applicable for product listing, then we can catch result and we can. We can build category page based on that meta data and response of this custom attribute container.

C

Okay, but when I say attribute, attribute entity or value of attribute for product.

D

B

Attribute metadata, it is actual matter that it's not value its metadata properties of attributes and here obviously it is actual value.

B

Okay, so I will add more use cases. I will probably also have to describe those additional metadata endpoints how they will work together with with this custom, attribute container, make sense, yep.

B

So probably, then that's it and feel free to leave any comments in this proposal.

B

A

Alex I added some notes to the meeting.

E

A

Guess that's all.

D

Actually, a hill one: this is changes to product pricing, schema such changes neurology approved by product owner. But let's do by now final review to make sure that's everything. Every city is taken into account.

D

I believe we had such discussion in the past, but this is just a final summary of what we discussed so instead of having one single price for a product interface, which is a store form to the presentation of products, we are going to introduce a price range. This range this.

D

System to values, this is obviously a range between a minimal really of product and maximum.

D

For the prices, because we need this information to to show it on store phones, a minimum and maximum price is a particular example of a month under price which is pretty similar to what we have right now is the red word, price, fine, authorised discounts, and it's for the taxi, as my difference is with an exist and representation of product axis. This is absence of adjustments.

D

We discuss the situation is ng from certain architects and profit all now we we agree this for all cases. As we know NAB system, we never want to really show such information in case. If merchant setup.

D

Diffraction is set up between food prices. They will be automatically included in case if it close, as this works from United States, they will be excluded. There's only there's only adjustments as we have to show with this for the price. This is other taxes which we and we will like in like taxes.

D

Because our current implementation allows you to set up a several fix for the taxes. This is array array of amounts visible. The label is and label of attribute, which represents particular particular dixit product types.

D

So it means you may see we duplicated a price old price. We duplicated price adjustments, as well as in arms and poorer prices. As additional reason for this that's right now we seem that significant number of our merchants are reducing other languages in PHP and is usual say they generate some object representation while interfaces. As a result, all our dynamic namek announced preaching problematic for them to support us. They had to originate here.

D

Our original eight objects each time each time only, for instance, edit an attribute which will add a new and you fixed products, but this is exactly the same problem. That's Alex described several minutes ago with customizable I believe additional improvements. As we have here discounts. We are returned information about discount.

D

As a result, we do not force a storefront application to perform. Such calculation o product discount that it owns together percent of discount and real amount, so planted in the price should be even more straightforward than it is right. Now.

D

D

Do you have any questions.

A

D

Is exactly fix it for the taxes? Because, as I mentioned before, we don't want to show a real taxes separately, because our application doesn't show them separately.

A

D

Oh you're right.

A

Is will the precast product you need to protect rice field instead with a price range with the Brigadier price field? Instead, we have tear prices.

A

And did you goes with your prices.

D

D

Price is a limited number of changes. Actually, this is array of final price, which is exactly the same as final price of of a product. Also, it has a quantity and.

D

Provider possibility and there are differences between the regular prices and finally,.

A

Okay, but first there is prices.

A

Okay, we have aa it's duplicated, but why asking price tiers? So we have to price enterprises, because the cricket.

D

E

D

This case I believe we can match, and it believes this bullet rest of us here for a for a while.

D

I don't know, thank you.

A

For the tape, I'm still recording and see you next time.