Magento Architectural Discussions, 25 Jul 2018

Previous Meeting

⏯

youtube image

►

From YouTube: Magento Architectural Discussion -- July, 25, 2018

Description

Topics:
- Allowed HTTP methods for Actions (Oleksandr Gorkun)
- GraphQL schema for checkout (Alex Paliarush)

Meeting minutes: https://github.com/magento/architecture/wiki/July,-25,-2018

A

Okay, so this is a architectural discussions meeting and let me just start from introduction of some new process that we have right now. So, first of all, we have a general contextual repository and main purpose of this repository. There are two purposes: one is to involve community entities into our discussions, so we make the decision based not only on our internal understanding of the magenta and its usage, but also on the community, and the second important purpose is to to have the history over our decision-making.

A

So in the future, anybody can go and see why something is implemented in this specific way. So there is a readme file which describes how the process should work.

A

What how the workflow looks like and basically in in most cases it will be targeted to the magenta core teams, but any proposals from community are also welcomed and note one note is that which is also described here on this page- is that most likely the priority will be taken will be given to them proposals and design documents which support some specific projects which are already in progress or which are about to start comparing to propose to proposals which are just about something that may happen in future, and nobody knows one.

A

So it might happen, though, if will be a lot of attention to some specific topic. Definitely we will be looking to that.

A

Also on the wiki page of the repository you'll have a link of all the meetings that we will be taking. The meetings we'll be bi-weekly for now and I will be sharing with the community, as well as our internal teams on one which should happen and how to join.

A

So, that's just an introduction, and now, let's, let's go to our topics, I think Alex Andres on the call, then I'll stop sharing. So you can. You can start.

B

A

Like in general, this those meetings will look just the same as what we already heard internally. It will be just.

A

B

So my proposal is to limit our controllers actions for processing only certain HTTP methods in the query to waive them just called eSport. Yet I.

B

Want to do this because of security considerations, it's really actually really common vulnerabilities that we help. We forget to.

B

Case-By-Case limit our actions to shorten actually most likely to a post method and thus some security, validations being the bottom can be bypassed.

B

Another reason is because actually, when someone writes the controller's, they do have some certain particular method in mind, but it just so happens is that we don't have a declarative way to stage them. I I'm, not entirely sure, but I think it's a legacy of some framework one and it's not really intentional.

B

So I supposed to do this. Like this, we create child interface of action interface, which will have a single method which will return, allow it of tgpd methods run in front controller. We simply check if much power attraction in currencies interface. If it does, we compare coolant, HTTP method, and if it's not in the list of cloud, we show page not found page also, it is really important to try to cover existing controllers.

B

If you already have I propose to do this by making some sort of lager that each time when an action is dispatched, you will look. We which much TDP method is used for that and then run just the whole suit of functional tests and based based on the information that we would receive just automatically implementation of HTTP error action interface towards the controls that we have information on I know it won't cover all actions, but it's something I think it'll be enough.

B

There are some concerns about this proposal. Already granular man thinks we should follow HTTP standard and return 405 code, when not allowed method is used. My reasoning behind for using 400 page his consistency like when we in Web API, we actually return 404 when they can't find a URL for contested by method. Also before before this, when purchased Kim moon was fixed in similar box, it would also return for a whole page.

B

Also, we have the whole mechanism regarding page not found in CMS to allow content managers to customize them, and if we start returning in 405 page for this, we'd have to come up with similar mechanism. Guidance in hundred managers would know what the hell is. 405 just a bit more confusing.

B

Another concern was that.

B

Having a method return, a list of.

B

The spot, HTTP methods is not that declarative that we should use marker interfaces instead, but I think that's not a good over year, because there are a lot of treatment methods exist, then, maybe for some reason: community you need some custom method and you don't. We wouldn't have an interface for that and we have to create like 10 marker interfaces, instead of one musician go method.

B

I don't know I'm, not a fan of that idea to smoke empty places.

B

My single, that's it oh well, so Roman pointed that we can do this validations, not in the front controller, but in router.

B

But currently we expect multiple router implementations to be active. I seen that it's more secure to be validated RDP method when we have already action matched because otherwise we'd have to put the same validations to each router or create a plug-in that's executed after the router as much or something like that.

B

C

Son Tom just propose proposes to have to have wind in the face for each HTTP method and marker interface right. They do not have any any methods, it will just mark.

D

Okay, yes, so let me clarify, but so I think in this specific situation we should not. There is a set of statistics that will bring us to the right solution. Well, just follow some checkboxes of being integer, so either the type of even method, request methods I metadata for for for an action if the inherent property of a match.

D

In my opinion, yes, because can it be dynamically changed, so this action now it can process post requests and now we can so which currently process by default it processes, post, requests and now I can dynamically decide that it processes delete requests. It is scenario possible.

B

B

D

Talking about, yes, can be action that can process two requests, but it's metadata. It's an inherent property that is defined when action is created. It's not defined dynamically, so I estimate the probability of such actions to ever appear and such least valid need for such dynamic behavior of defining what actions and what methods and action can process in run time is diminished. Probability is very low, so from that perspective we can say that this property of request myself an action, is started, so it means. If we have a word static.

D

We can already say that any language construct that introduces behavior is probably not a correct approach, so we can say, if probably for wrong instrument, adding a method implementation that will give you a list of actions is probably not the best, not the optimal approach. It don't be that we do it's not dynamic. We don't want to be dynamically. We wanted to be study, wanted to be defined and described. That moment on the action is great. So now what so?

D

That I just follow the simple logic, but from that perspective, I, don't like the idea of using method here right. So what the ways of describing action, metadata action, metadata, statically the way we can do some configuration, it would be overkill. We can do annotation, but, as alexander mentioned correctly, we don't use annotations here last. Why why I have annotations? And we also have we have you son started or we can use marker.

E

D

From perspective of so I choose here between effectively between static variable, a constant that will contain list of methods and market indices, I choose personally I, don't have strong opinions, but I choose percentage mark interfaces because an action, a type of action like that, a method that is result by action is the inherent property of energy. It's a part of type of action and, if I here worth type I prefer to use interface to mark that problem.

D

So this is my simple logic and that's why I think we should that I would vote for marking, but definitely not for dynamic, not for dynamic language constructed not suffice.

B

I'm not strongly against that. It's a valuable option. I just think usually a marker interface suggests that we are some different ways for processing that was I. Keep it all stock shouldn't face any precise differences on the get auction. Yes,.

D

B

We don't process them differently. We just need to compare them.

D

Compare comparison is actually processing them differently. If, ideally, they would have different if you would follow HTTP stand up in design of our actions, which would be extremely breaking change for now and not needed, because since we are moving towards web it yet, but if he followed HDTV standard our actions that process different HTTP methods would have different signatures in their execute method, because HTTP dictates what actions can have, but across body. What can't have what actions can tell request by the dictates of what types of responses they can return?

D

So if he would go further I'm just except fellating, we would have them absolutely different types of actions. So that's why that, in terms, the market interfaces is a small step in that direction. But it looks, looks like the correct, let's type, the correct, directing direction, but not too big and not too great.

F

A

The talks like it will produce less amount of code.

D

Yes, exactly and it's very elegant and simple way of marking objects. It's really you.

E

Don't you don't create.

D

Methods, you just add an interface, you can market the market book and you will never have a switch statement to check. Okay, give this section a post. Let's do the second section is get well there's no unit you'll never have such as an example. Mentioning comment, because that.

B

D

Would bid help mm.

B

Scott, when they validate no.

D

We will not be have the school, because our validation will always depend on this request. Type. Every request will have a method right, so in your front controller or outer than whatever you decide to implement this, you will have a method right in your request and you will get the method from from your request right. So, for example, you will get have some code, like request, get messy and you will, depending on you'll.

G

D

For request for every request, you'll have an interface and you will get you look up the interface that you'll be looking for and the only check you will have you you'll have. If this action implement this interface and if not, you will return four.

E

Or five and.

C

D

The master type that Roman gonna suggest right. Well, we know we know switch. You will not be trying to look up all the all the negative direction in.

B

That case, the map should be an extendable. Somehow and yes,.

D

It can be extensible in the sub silicate to have it extensible, no problem.

B

Lessons that should be just.

B

A

B

Said it should be up to volt? Do you use marker because I don't have a strong opinion? I lost a lot liable.

C

Okay, do we also want to change to return different response code, four or five instead of four for.

A

Like the ideas for reform.

B

That was a question.

A

The question is two things to resolve here: one is whether we use get loud, HTTP methods, or do we use a marker interface and another one is about response code, whether be a concave es, four, four four, or do we use four or five, as proposed.

C

Do we want user friendly, page qualified.

B

A

B

um Just use invalid URL and come for election that actually exists, but it's not processing get. Oh.

A

What a valid user will get this page.

C

Well, it user unlikely you'll get this page only if there is a problem with extension.

C

A

Most likely this will be a user that wants to break Magento, we'll try different URLs.

C

So you see, listen, I, don't.

A

Know four or five sounds reasonable for this, but okay, let's finish probably first we would use methods the method or marker interfaces. Understand Anthony's, for the marker interface was opinion.

C

Mark interface, probably a little better.

A

So it's under you are more for.

A

Okay, I, don't know any personal like the interface more as because it's just will be easier to use simply by.

C

And why do like method, one more time, Alexander's I.

B

Don't want to make an interface for each or switch me matter that exists and I think there are maybe some cases when it's dynamic, maybe not to limit people.

A

It supports multiple.

B

It can support multiple methods, even.

B

H

I mean demonic is.

B

Actually, against the rest, one gift card actions that support both get in post, like when it has a certain parameter, its supports post and doesn't sets again that's Bob case, but maybe.

A

It should be break broken down into multiple directions, so you know I think like if you mentioned that you don't feel like it's not really my opinion. I propose to go with marker interfaces, looks like more people I. Think it's a good idea.

H

I

This there is actually exist. One more option is just a our wrote in dispatch system and provide some mechanism just to place an action file next in class and some particular braised pleasure to declare what HTTP method should be. So we now just the class name to two zeros, and then we we may have compose some folders subfolders to declare a cheeky PMS, but just like.

A

It will be harder to implement and much better and.

B

I think we should be moving away as much as possible from by convention system.

G

A

C

Of having a constant instead of interfaces, that I can see is that we already have constant for specifying resources in in controllers.

A

A

If you have more time, we can come back to the story about 404 or 405 like why you don't have or don't want to have 405 here, because it will not be user-friendly. But we.

B

Have a separate at McNeese and because, when we're using Web API, it also, it turns 404.

B

It will be about the same.

A

B

Course it's not a static. It's four or five.

B

Four or five over the parrot to the scope of.

F

This in the big guy is the difference is that you have same URL, but you can have some methods implemented. Some others not implemented, and this were like different routes- are identified by a combination of HTTP method, plus route, and here, as far as I understand, you will have like actioncontroller URL, which is unique for specific actions and usually you're not supposed to have same URL for different actions.

B

Horrified would make a better case for both pieces forever behind this I just wanted to give in system again.

I

Actually say that method, head and gap should not be, it always be allowed. So this is like probably the saying that we should not use it for for bidding, get message on some actions.

J

I

404 would be more appropriate.

H

A

I

Found a link to the dogs.

A

Okay, well, the link is also agreed that we will you go with marker interface and 404, but in general, proposals is good and just really useful. All agree: yeah, okay! Thank you.

A

The next topic is from Alex model of care.

B

That's under, could you please stop staring so I can sure I, don't know what on second, okay, stop my description.

H

J

To move your cursor to the top of the screen and the control will appear.

B

Some guy disabled it one time and now.

B

My business combination.

J

Disconnect sounds restorative laptop.

B

F

Ok, I will probably start talking on this topic so far when I can share it. So for now, if we don't have like final proposal, but we have work in progress and since we believe this is pretty important piece of design, we wanted to get early feedback and I.

F

Basically just give you overview of some decisions that we believe are good, but.

F

Share my screen, but we would like to get your feedback as well on this.

F

So the background is that we are working on graphical mutations and queries for checkout, and the idea is that we should be able to complete your code flow using WebGL completely and there are multiple questions: how to design and decompose those endpoints to make them minion for users, and also we should take into account some specifics of graph kill and for now I would like you to focus on like this section here and I will just go over some items, give you different alternatives that we discussed and the alternatives that we believe is the best one.

F

And after we get some clarification and like most opinions expressed on this topic, we will be able to work on specific schema for all these queries and meditations. So, first of all, I'm sorry focus on this one. So, first of all, we'd like to have separate mutations. So for somebody who doesn't know like what mutation is it's like command in Rafael, so anything that doesn't meet a state is query in growth, kill anything that modify state is mutation. So, let's say adding products to cart or certain ship mass of each mutation, getting current information.

F

It's a query, so we would like to have separate mutations for each product type, and this will be used while adding items to the cart. Let's say if you consider product query endpoint over there we had single interface like product interface and it had multiple implementations, posit interface for different product types. However, graph kyo doesn't support polymorphism and interfaces for cases when you accept it like as argument for mutation, for example, so girl kyo differentiates the different types like regular types and input types. So for input types, you cannot respond morphism and so far.

F

We believe that the best option would be to provide different types input types for different product types and use separate mutations for adding different product types to the card. Why that important? Because, let's say simple, products can have custom options.

F

Configurable products can have configurable options and custom options like group products can have these group options, and so basically, we have different set of fields for different product types, and it is just inconvenient if we try to get everything to the same type and then first client to decide on their own and glands.

F

We don't have any support by draftkings schema, so they don't have what a complete problem like working properly they may end up is enrolled combinations of fields, so would say you are not supposed to send like Wanda options and configure go options and same request.

F

If you separate this, we can create nice strict types and you will get autocomplete and why is all see why we believe this is a good idea, because if we look at pwe scenario, you will be making this add item to cart from usually like from for details, page and the product of space. You know the type of product you are currently viewing, and it means that you can trade some map on JavaScript and basically to to say if my product type control type is configurable, I will use.

F

Like add configurable item to cart method, so this is like one of the most important points so far like. If you have any questions or comments with discuss now or you can give them back later,.

F

Okay, so the next point is that we want to have uniform end points for guests and customers. This is just for convenience and right now, customers and gas are differentiated by presence or absence of authorization header and basically, if you have valued customer token specified header, then you know the business customer.

F

Otherwise we assume that the user is guest and we believe it should be possible to unify these interfaces. It will be just easier for everybody and we will not have like special endpoints for customer special on points for guests, like you have in the rest implementation, so you will be able to use some types so.

D

So framework you mean that framework well, based on television talking define if a customer is logged in an envelope in, but if the actual service contracts or points operation that are executed and that octopus, we are required to execute our Coulter disputed action are different. The framework should be able to identify to differentiate different actions for single graphic, an endpoint right, yeah.

F

Yeah so we already have example, the simplest step here was to implement like create empty card, a mutation and I believe it was already implemented by some community member and what we do. We just look at user context. The user context is identified same way as it's done in rest. We just look at header and we initialize user context and then from user context.

F

You can see user current user type, so it can be like admin integration customer best and if it's customer you can get customer ID and based on this resolver can decide what the service contract should be invoke like if we assume you service contracts, but.

K

I guess card, as this has much about, is this customer card or grass card, so yeah I believe we we can manage them in the same way is our difference.

D

By the way, if that's already know.

F

This is as I mentioned, this is work in progress and you can notice that this is like an architecture project. So as soon as the document is done, it will be publish to this architecture.

F

D

Legit and have at least a branch of at sit back there and create a pull request, gets it back. So just you know it's easier for me, for example, to read stuff yeah.

F

I was going to do that soon, but first I wanted to write like initial version of schema, like proposed schema and for crazy, quick to create the schema. We need to get answers for these items and, if you have like, if somebody notices that there is something wrong, it's better to give back now before we spent all the family, like did great, entails for the schema for.

D

Great first iteration of schema, it's random and what I'm saying is it's hard to? You know to get it so quickly and don't have.

E

D

Time here to dive into that, but we have something to read and that's.

F

Couple days, so the next point is that we want to create separate mutations for each concept. So alternative is to create one huge mutation, these lot of optional fields, and then, let's say, if you provide shipping information, we will save it. If you provide like a payment message, we will say that if you don't try it, you will not save it, but this is this seems to be like really complicated and most likely in in in the most scenarios.

F

We will have to do this step several anyway, because usually customer first as products then like goes through a glitched out step except right. Now we are going to have like create empty card, ID items to card and all other other steps that we usually do a check out separately.

F

At the same time, graph Keo allows to combine several mutations in one query. Basically, so you can send just one query to Magento and all the mutations which you specify will be executed in sequence. In case of graphical queries, it will be in parallel in quest in case of graphical mutations, in sequence, to prevent rest conditions between your mutations and that's. Why it should be possible threat to create empty cart and then send all the data still in one graph kill query, so it should work and at the same time we wished.

F

You can create new and point find like sometime in the future. We can create and want to create order in one hope, if you decide that we want that, we can do that, but so far for regular checkout flow. We believe that it's better to to separate the steps and it will import granularity and if you also make every step cleaner and interface, will be more usable and friendly.

F

So any suggestions of insurance on this item.

F

So and the main reasons are like first of all, use cases usually have like different steps. You know don't normally create carved and populated in one request, because let's say to get valid shipment options, you need to populate like your address and items and and basically initially, if anybody doing that, but it should be possible if you know exactly what your shipment options, correct options are, etc.

F

It's really possible in fugitive with ordering one okay, anyone on mutation, but you can ensure that it's good populate, but as I mentioned, you can still combine some steps in one. If you know how to do that, I mean if you're flowe, supported by.

D

The way, please, please don't forget about general design guidelines about.

D

F

Operations in the work: that's can you mute, please: okay, I.

D

I guess I I, guess I think I know the giant called so the please do please make sure that we have all operations are impotent and all so.

E

They can process.

D

Multiple like entities per protocol, so, for example, you can have multiple products to card by one call and.

K

That sort of interruption we has is discussion internally and we didn't find any case when we have to add item to cart in bulk. So we don't have such user scenarios and this slow.

D

We don't have them today, right but general guideline and that's I, don't think! That's something I.

E

D

Now that's a technical guideline that without and I think we all should read it. If you don't to forget about it, it's a general guideline that all API should support.

K

In general, yes, okay, let's discuss this separately because we may find some specific cases related to checkout process. Hey.

E

This is Misha we we, we think we did identify some scenarios where you can add multiple products to to the cart at the same time, like an example is ordered by skew in my account and understand.

D

I want to emphasize that the design guideline that was added our technical guidelines. It was specifically added there because it you know we did a mistake in the past, where we didn't take into account when we designed api's for the scenario that being very efficient for us. In that current moment, right.

L

D

In future, the future cases eight guys can be used by our agent by our developers in the way that we're see now, that's why they have to be implemented in a way that will support a performant performant, multiple actions, including customization. So, for example, if you add thousand products to cart, you don't.

E

D

Don't dispatch a thousand item item at the Picard events, you dispatch a single event, items added to part: that's just I'm, just reminding you why we why we that design got out there and if we have the design government, if it's published, we cannot just go in a single in the single design, decide that we don't follow it. If we.

E

D

He's saying that it doesn't make sense, we first have to go and change our Constitution our technical guidelines, and then we can change the true and not apply the tool on some specific design, I, just reminding you that the process, how it supports the work you cannot ignore. What's written in technical guidance, I'm, not saying that your knowing is here, but please don't forget the future. Okay.

K

Okay, so maybe we have to take a look at it shows it's everything really government is right now, by the way about capitation for cards may violate graphically restriction, which says it's. We cannot use interfaces for input types so right now, as this design proposed us to use a different types for each type of product. If we want to support bulk operation for add to cart' operation because of graphic a limitation, we don't have to use the same type for all product types. This is my concern.

F

So if you do it like in current design and make different in point, so we can potential except like in this version. It is like accepting a single item, except for group like it was. The idea was to have multiple items accepted for group products, but for everything else, just single item, but we can. We can do it like multiple items for specific product type in one request and then you can have. You will have to split. Basically in your in your client side, you will have to split it like what say.

F

Five simple products will be in one request and then five configurable in another request, and it will be like single graph kill request, but on the server side it will be different resolvers which will causes those, and my concern is that you don't be able to have like single single event in this case. Like Anton. Does it make sense to have it included, as it make sense to have same event like single event for all product types, I.

D

Don't know might be its requires more time. Just you just requirement it's a performance requirement, but you might have different events or different products, I'm, not sure if that would be a good solution. Think about it. Okay,.

A

So yeah, let's move on, we need to think about ball coverage, though all.

F

Right and one more item is that we need we plan to have hashed IDs for cards and third items and all those card related operations. If you remember how it is done in rest right now, if you are customer, then your ID is just regular ID from database. It's not hash to anything. If you are guests, you have cached version of that ID, which is preventing just guessing ideas of different customers, and here we would like to have probably unified approach, and we would like to have hashes for customers as well, like any concerns with.

A

Them do you mean.

F

Magenta because it's a breaking change in rest, but we can do it for graph chaos and graph kill. You have just hashes also time, so it will be still extreme time in in both cases. But we believe that it is better to crash ID just in case for security reasons, not expose IDs prosecutor.

K

And I believe for extension developers, because behavior will be the same and nobody will need to main text. Is this customer card or.

K

A

I'm, just thinking we can look into whether we can change it. I.

A

K

Say this is good, a good point to put this decision to check out technical, even, but you assume you'll be able to break this functionality at rest. We go to this.

F

Ya suppose it's from Mossad I can show some skin, but probably it's most likely you'll have to discuss this couple more questions and then we will create a new version. Should draft of schema and publish it.

A

L

Have one more question: do rotations allowed to define some dependency on each other or some order, because you, for example, you can send payment method before addresses gonna set.

K

Basically, in same time, it will be part of one domain object and, if you'll be able to make this order in your implementation,.

F

The sequence of resolvers invocation is defined by yeah.

K

But we have a very flexible solvers and if you need to specify the order for implementation, you can do this. So no nobody limits. You is to write custom resolver, which knows exactly how your shopping cart should be start. Okay,.

F

We can discuss it. Obviously you can, you can create like custom implementations but as far as I know. Currently it is not supported most likely it will work, but there is no guarantee that you will get mutations processed in the same sequence that you send them.

A

F

You have any other questions or suggestions feel free to reach out to me directly or participate in discussion in several days when you publish.

A

Thank you better.

K

A great document.

A

Anything else to discuss today you don't have anything on the agenda. Don't okay, so I think then we are done for today. Thanks all for joining, see you next time.

K