Magento GraphQL Community, 20 Dec 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Magento GraphQL Community Meeting, 20 December 2018

Description

Agenda:
-) [Architecture] Focus on Checkout. Checkout workflow scheme (@Alex Paliarush)
-) [Quality ] Current metrics, ideas, quality roadmap (@Tom Erskine)

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

If we imagine to graph QL community meeting agenda is quite short today we're light on attendees I, think because of the holidays, so merry Christmas and happy holidays and happy upcoming new year. I think we're gonna, be we're gonna be gone next week. So I think this is the last one for 2018 been a great year for us happy with what all we've accomplished- and this is you know, we've done.

A

We've done a lot, so very cool working with you guys now for today, we've got agenda posted by Madeira, just two items, one on architecture going to be presented by Alex here and we're gonna be focusing on the checkout flow and kind of state transitions of accomplishing the checkout flow from the high level, and then we've got a discussion on quality that will be led by Tom, discussing metrics ideas and just quality roadmap and the equipment.

A

So we can make there so without delaying you any more I'm going to pass word to Alex to discuss the checkout book.

B

B

Basically, what we are trying to achieve right now is make sure that all our mutations and queries for checkout actually compatible with real life scenarios, and for that purpose we started drawing a schematic version of our checkout and like we, we just have request/response, like sequence, which will eventually allow us accomplish, pull checkout, and we are just making sure that everything is compatible, that we don't end up in situation when one request returns, some response, which is not compatible subsequent.

B

It's a mutation, and we have already found some issues which we probably have to address, and it's good that we are doing it now, because some of endpoints are not implemented yet, and we can just like I. Just I was schema before even start an implementation, and this is probably the best way to to do it to avoid any unnecessary rework and how we can verify that. Actually, our graph here is compatible with real life scenarios.

B

Is we can just look at existing cell limiting and basic guess, check out scenario, and you can see what kinds of fields and what is the sequence of action usually is used when we do check out and just make sure that you can accomplish the same with our graph here, and so the first step is usually adding something to card, and then graph key obviously have to create card first, and you get this cart ID, which you use for all subsequent queries, and it's important that it is hashed value just to prevent, put force like a jegging of cards by users.

B

So you you potentially aren't able to get us idea of any other cards in the system. If you use this cash with you, so you get this hash, which is acting like your session on store phone and since our graph key is stateless means that you're, basically, you don't reserve any state between queries and we don't rely on any like PHP session mechanism. So this acts as your session basically session ID and you operate with this ID for all subsequent queries up until the point.

B

When you place the order, so just step is usually adding products to card hey.

A

Could I ask a question there yeah sure, for even one so you're saying it acts like a session ID, but with certain settings you will, like the cart, will be preserved for a shopper across different sessions right those this more like an ID of a cart or is this like this is not going to change when the customer like across customer sessions right or is it going to be different? Almost.

B

Like it will be the same cause, we store internal cart, ID, which is just regular numeric value, and we have my pin to this hashed value and previously, when you like, performing just regular check out over here, but actually we use the REST API is here as well like on our checkout and domo. Specifically, we used REST API and we use like same mechanism so I'm sure we even use regular ID at the moment, watch constant, like previously before refactoring UI components and using REST API.

B

We were using some checkout controllers and everything just regular ID, but now I assume that most likely, if you start session, but actually it doesn't make sense to like switch. But if, even if you do that, if you do like partially invest, partial and gradual, it will still work because this, my opinion is shared between Raskin graph kill. Potentially, you can do like one request in graph: kill one invest, but this is not we're trying to achieve eventual. So this is just.

A

This is closer to an obfuscated and card ID. That's persistent, then, like it's a shorter alert customers, yeah.

B

It's like a replacement for session, basically, because you need to have some identifier who was a like one request which another like correlation ID. Basically, between request.

A

B

This is what it is, so it's not a real session. We don't have session PHP session started from the camp when you use it ID, it's just ID, which is taught in database, and it is actually identifying specific what record in battle base tells me and I believe if you just start another like, if you create another empty card, your existing card will be disabled because we at the moment, you can have only one active card in the system. So basically that's how it works yep.

B

Then you use this card ID and you add some items to card, so we have.

B

If you followed us previously, we have multiple mutations for different product types and for now we are focusing on the simplest possible flow, just to make sure that we can accomplish check out with a simple product, check, money, order and, let's say free shipping, so the most basic payment, shipping and product type variations, and then we can, as Misha described on previous call, then we are going to add support for online payment methods and all kinds of like shipping methods, as well as.

B

So, basically, you add product to cart, and then you end up with some fresh. It's usually looks like this, so it's like starting page of Chicago and what we can see here. You are suggested to enter all your shipping information shipping address and you are also presented with some shipping methods which are not tied to specific address by default and then, as soon as you fill out, more information I don't have any enable.

B

But as soon as you fill out more information, we do adjust requests in the background and we can fetch more relevant shipping message which I, like applicable, to your address, which you select, which you specified and to achieve that. We actually need to have get available. Shipping methods like available shipping methods field on this query as well, and it is actually possible to do because what happens in all cart, related mutations and queries. You can get cart object. A full cart object in response.

B

You can get like whatever you want from the card and in this example, we are not creating available shipping methods and like this is not possible to render like we've provided. But what you need to do you just need to add additional field like available shipping methods we need to add to previously, and then you would get ability to render like these shipping methods along with the form and then, as soon as you continue filling out the form we'll just do some collision background and video.

B

We will actually use this end point like set shipping address on car, so we will be updating shipping address on card and then in response we will get like full list of available shipping methods, including those which are relevant for specific addresses that should be in our anyway yeah this will. This will be ready button graph key all remember, like you just specified in this form and.

C

B

Doesn't matter like, for example, selected shipping method is an object and method is an array button, graphical syntax? You just specified in this format and you don't care if this array or not, but in response.

B

So this is sample response, I'm, not sure, like I, believe we don't have this endpoints implemented yet, but we are just trying to work through schema and in response you will get an array here for the reduction methods and you will get an object here which is probably like empty by default like it doesn't have any values, but as soon as you select something oh, maybe we need to provide that people value it. So as soon as you select something you will be providing selected, she can mess up here and all available relevant shipping methods.

B

B

So then, let's say you select shipping method and then we are presented with a page where you can select your billing address. You can select, you can set it. Okay, I just want to use my ship address, but this is just how storefront is implemented. Eventually, we will have to submit, like all the data anyway, but basically you're, presented with a set of available payment methods available by default, as well as billing address, and to achieve that, we need to use available.

B

Even addresses.

B

Well, we'll find payment available payment methods. We should use it like own steps and Bob. So this is one of the information that we just get from analyzing all this, because this is like a draft at the moment and if you have anything back, you can go and check this out on our wiki in Graf PLC project. Basically, on on that page, we just get available building message and payment methods and you can fill out your billing address and then eventually you are set in payment method on card.

B

You are getting some response, like whatever you want from cart again, cause all mutations on card. You can get full data to card data if you need to, and eventually you get mutation population order. So as soon as you select your payment method, you fill out your billing information. You can skip place order and what happens in this case.

B

We just provide our card cash card ID it provided for place order mutation, and it will do place order based on all data which you provided previously for the same card reading.

B

They were so queries from community regarding. Why don't we just implement one invitation to perform checkout, and we have actually discussed this previously, and the idea is that, first of all, we want to perform step-by-step validation. So on each step, usually in UI, you don't have checkout in one click, because that you have to unless you have all data stored previously, and that is fine.

B

We can still perform like multiple graphical queries, with all data which is stored for customer, but usually we'll say, if you're a guest, you have to go through steps or, if you're, a new customer. You have to go through steps and you have to specify your like billing address shipping address all that information, and usually you want to get feedback on whatever data is invalid immediately, and for that it is better to have like step by step, end points or step by step mutations, where you can just submit the next step and get immediate feedback.

B

If something goes wrong and you can correct your information immediately and in the future, we also have an option to implement kind of one-click checkout with one graph here. Oh really, and it will obviously be supported by separate resolvers and it's still possible to do it, but this is not the main scenario, and the biggest issue is that is that all they that have to be voted in and once we will just get like with my buttons will get a bunch of errors at once, which is not user friendly mission. Would you like now.

A

That's that's accurate, so we've talked about yeah all these possibilities, but remember the thing to keep in mind is a graph QL as a storefront API, and so we are trying to like a primary goal is to mimic the actions of a standard checkout flow which, like I, was saying it's not normally, it's not just the one click like.

A

If it's one click, then all the information was already available ahead of time like payments and shipping etc, and you must have already performed those operations and perform the validation on that input data. So if we you know, if you already have that data, then it will be possible to place the order, obviously with graph steal as well. But you know the flow of setting those values and validating them needs to be supported by these endpoints that we're designing.

B

Ok, so if no questions really can we wanted cool thanks all right done. Ok,.

C

Ok great, so what we're talking about here is our quality plan for graph QL as we move forward into the new year and we have began running code coverage metrics on graph queue focused on the API functional tests, and this is what it currently looks like see. There's better coverage in some areas than others, and- and we can drill down through in these. This is a tool we'll be using going forward, so we can drill down in and see exactly where our task, coverages and that'll be very useful.

C

We can expose this data as well and periodically so we can see where our gaps are, but in terms of what we actually want to do with this. So what we can see from this is, we are in quite a good position with graph QL. This is not something you get to send. A lot of projects is that we can aim for 100% code coverage M for API functional tasks for all our operations and mutations. We want that in both pause on negative scenarios.

C

So it's not normally something you'd said as a quality part, though the way this is being developed and the importance of it I think that's something we should aim to do. We use that code coverage checker to do so, along with some other tools, so that code coverage and we'll be tracking.

C

That internally will also report on that monthly and to show a trend of increasing coverage and I will also be looking at that more frequently to identify gaps and prioritize this and and write some of that automation coverage so that we can see an increase as we go forward, and we will also be in the new year exposing some tooling for the community. So right now we're sort of testing and writing API functional tasks as PRS come through with the focus on say, whole order flows, and this checkout flow that we're looking at not.

C

We want to define that and ensure that we have 100% coverage for at all, as it goes through and we'll be using some tooling to do that, that'll be revealed with the community so that we can track and report on they in this meeting. Every week where we are what coverage flows, we have what issues are in progress, not so right. Now we don't really track that, so we will going forward in the year and that's a tool.

C

That'll be visible, possibly something like exam hub or hip tests, that's to be decided, but we will see the backlog to do items what's being done, what's being delivered on, so we can see our coverage increasing. So that's the general plan and it's a short one. I they'll, be obviously implementation details of this in the new year. Do we have any questions about what that looks like about our goals or what happy to go ahead and say we would actually like this fully covered and we want to track a week by week.

C

Does that sound good everyone.

B

A

I mean it's a it's a it's a great cool to have, and it's good to be in a position where we can actually shoot crit, it's rare that you can but I think it is achievable in this kiss cool. So what do we if we? So if we say yes what's, this is this all sounds great? What are we, what are we expecting and um I guess like there's holidays and whatnot? But what are we expecting to see a month from now so we're looking.

C

At that tool being available and that will truck a backlog, so it's the initial battle of from this coverage graph, what we haven't covered and so what would get us to our current state of a hundred percent and so a backlog of that of items that need to have API functional tests.

C

That'll include code, that's covered here and negative testing or code there's already covered by positive testing, so there'll be a backlog and a board that I can burn down and, and so that'll be the first thing getting us to a better state of where we are right now in terms of coverage and then items attached to or in line with MPR's and issues for our two three one, two three two scopes that show what that testing should be specifically. So again, we can mail that into our definition of done.

C

So as we deliver features and as we accept them, they contribute their correct code coverage via API functional. But the first thing we'll see is this tooling available with a backlog of items to get us to our current state to get that number and we'll track the trend on that Oh.

C

Sounds great and then probably end of the month, we'll do another full coverage report that everyone can see.

A

All right any questions about this tooling.

A

Awesome, ok, anyone have any other questions that we're not or questions or topics that were not on the agenda.

A

Nope awesome well cool. Well, then, once again later strappin holidays and we'll see you guys here yeah, you two guys have fun Phoenix here.