Magento Architectural Discussions, 14 Nov 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Magento Architectural Discussion -- November 14, 2018

Description

Topics:
- Remote Code Invoker Design Doc, #37 (@AlexMaxHorkun )
- Frontend Technical Vision (20min, @jedmao)
- Standard Promises, #42 (15min, @AlexMaxHorkun )

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

A

So, let's start, let's start them from. Let me start from work staff and what changed and then they'll moved to the discussions. So I was already announcing it in the chat in the sectional, but just in case, so we changed a little bit the way how we propose topics for this meeting. So before we had all the meeting notes. You know wiki and you can see all the pages, but now you just simplify everything and to make it possible for anybody to submit a topic.

A

I I will be creating the issue for issues for each meeting, and anybody can submit topics here in format of topic, then, ideally pull request. If you have and time time that you need, we have speakers name as well, but I think it will be unnecessary if it's problem like usually it will be just the author of the command and I will post all the notes in all the notes in the in the topic see that's some small changes that we have there. Let's move probability topics and we have Alex a gherkin here.

A

So maybe you can. You can start out stop sharing my screen.

A

A

A

We don't hear you if you are speaking.

A

Yes, we can I, don't know if it's loud enough, but I can hear something.

B

Let me see if I can adjust I.

A

Think I think it's fine. If you just speak loud enough, so you.

B

Can adjust it anyway? Okay, so I wanted to talk about remote holding Walker once again, I have updated the document quite a bit. My goal was to provide more examples mm in my points and to try to structure as a document a bit better. So it's more obvious that basically consists of two parts. One is just description: abstract description of a mechanism that will be used for inter communications, between models, it's just functional requirements and API is an SPI.

B

It doesn't suggest a certain implementation and the other part is actually describing some implementations options that they have.

B

So here's an explanation about this so first angle, not to point out that maybe was not so clear. Is that no matter the implementation? We still need certain mechanism to handle our communications like, so they would look like this.

B

So they wouldn't look isaacs, so we wouldn't have to set headers minority to take care of retries macrinus manually. Every time like we still need an entity and in walker whether the implementation is based on restful, api or whatever, and the first part of the document. This discourages that this is what I think proxy service would look like using Walker. So we just specify note ie that we are going to contact services name.

C

B

Method and argument that we want to pass, we get a promise, let's roll it I think even this proxy services can be generated automatically, but I haven't touched that topic I think they can be written manually for now, so here I described how right in a proxy model will look like. So we create this clause from implementation of service interface in the XML. We specify this preference since and note that wouldn't have this modest implementation. We just have a model proxy, then it wouldn't have default preference and we will specify it here.

B

So when we're looking for source interface, we will get service proxy. So.

A

Let's, maybe a stop on the proposed interface first, so I agree that we will need some way of some kind of framework that will help us to make calls to other services right, but on the interface you still propose to invoke certain PHP methods. You just want to make them remote right and another way is to still to just have web api that we have but to implement a framework that will help us to do what could to invoke them or to call them in the easy easier way right.

A

So you mentioned that we don't want to have to set headers in every time and so on. We want simpler, wise, so I would agree with this part, but like calling PHP method is a different part for me, which I think more questionable.

B

No yes, because in PHP method, since writing the implementation right here, phille, the closest the interface we're implementing and the method name- is submitted in dimension like if we were writing microservices application from the start. We wouldn't have this information, so we just use any URL here. But since you already having this information, I, don't see the point to state a URL right here. So even the implementation it can use a URL it can you use restful, Web API URL? That will be fine found through configs, but I.

B

Think this interface or interface should just require class and method, because really it's what we want to do. We want to call a certain class and s method, and we already know the signature of it, because it will be this interface. We will help in every node.

B

You will have model like model name API models in every node that we have I, don't see the point to state a euro here.

A

But the URL will be so like if you it will be more coupled with the implementation, with the nose like if you use rest, you can theoretically use any technology behind of it. If you use I, don't say that we are moving somewhere from PHP, but still, if you want to work, a specific class with methods will be more coupled I'll.

B

See again, we will always have this interface, but we have to have it because you'll have proxy as an implementation of that interface. Even if you choose to create this micro service with different language, the way Anton describe this room, always like model name, a bi model that will contain these interfaces.

B

This is how the local service will look like it will just use this service without knowing whether it's actually a remote or not just regular way.

B

Right so I already explained why we can just write proxy methods differently. Whatever time we need an abstraction so.

D

They're like on this part, this part I, have a question. I think we should not handle retries in application. It should be responsibility. I was a service, mesh and I. Guess as I understand things like a service registration, service, location and routing, retries load balancing, and you should not handle this in Magento, it will be done by as a service mesh.

B

Another design document describing said service mesh because I didn't.

D

Think it was in the design, duct.

D

E

Do we don't need to describe the design of service part, because the design service area lashes is a responsibility of service mesh implementation? We just have to mention that who use their business for heritage.

B

Again, this part of the knocker description it it's an abstract one. Res mesh can be used underneath like these functional requirements, they apply in.

B

Personally, by what I have read about stress measures, they are required when it has the need to write different services with different languages or at least frameworks, but from my understanding, I will always have Magento.

A

B

Use a point: another thing is that as much like, you said you should handle load, balancing but I think our cloud solutions. You have no.

D

It's more, it's not complicated when we deploy services.

D

We don't want service, know about other services, because some said mrs. Wilfer you new services will will be added. Instead, services should not know about other services, so there should be way for a service to register itself and like something should track.

D

Ip addresses and ports for for the services and also like load, balancing and and tries very also and.

E

There is no, there was no any mention anywhere that there were every service of implementing with implemented with Magento. There could be different services.

B

From my understanding in your document, you describe that all services would be registered in Magento by kayvyun Auto IPI, a.

E

Module API is just is just a peach way of communicating the API of service in another service, but the implementation of that service can be can be running.

F

E

Different can be implemented differently in different language with different APIs. So the important thing here is that we need to decide what the dance, what the transport communication by under it miserably, so that so the module, for example, when the module checkout wants to talk to the catalogue to get a list of products from the beginning of the design of service contract contracts that works today in magenta accepted them its current design. It says that module checkout should have an API of Matt module catalog the installed, and so it has this API.

E

It has signatures, it understands the times, so the the decision was made four years ago to make it the interfaces explicit and present them a speech benefits.

E

What's the underlying implementation of the communication, it might be rest, it might be not rest orientation, but it doesn't matter that much for how that API is implemented on the on the service on the service itself can be different language. The important thing that it's represented for Magento food services that want to consume that service, it's represented as API module with a PHP, the API interfaces, I.

B

Think it furthers my appointment about not having to use your early hero like you're, registering services by making interfaces and methods. So I think I understand your point.

B

As I've said this functional requirement and this part of the document can be applied to a service mesh restful web I believe whatever they.

D

Manipulate the service mesh, this.

B

Is functional requirements of how communications between services should be handled? What one short point does it have way it can be applied by service? Mesh has to have unique IDs for calls to track them. It has to have.

B

E

Fairly clear that we probably need to split, we need two separate documents. I just think about topic for the problem we are trying to solve. The problem is bigger than invoker. Then the problem with this document is that it's called invoker, but its scope is bigger. It's trying to solve part of communication, not full communication problem medication in services, so you purchase some of it. That's why there is so much discussion, so it's I think it. So let you split the first we have.

E

We have service isolation right, so we decided conception that we won't put the data. Now there is a sub problem to that communication between services, so in the general document for communication within services that describes how services, while talking to each other parts of that and in that communication we have to mention they talk about things like what do we use for communication? Do we use service measures that we do not be a service mission? If you don't use service mesh? How do we?

E

Where do we put the logical, sorry, twice, circuit, breaking and time outs and stuff like that? And one more part of the document is in service in both service activity, whether it's using rest URL, whether it's using API module.

E

But so we have to remember that for today, the day by default, the except that approach is API module. That is how service contracts are design. We can change it now, but we have default solution, and so my point is that let's here focus on on the invoker site and that's even what locks in approve the document and then maybe change it later, but more dispassion is required and despite a more structured description is required for overall communication. So we have service a and we have service B. How do they talk? Other questions?

E

Are we have service a and it wants to execute two requests in parallel service, B answer you see, how does does it do it and as part of so and one reads, the bill answer those questions like okay. So how does communication happen? Is it synchronous asynchronous? It's part of that? It will allow us to reason better about how the invoker should look like, and but if we need promise library and what promise library do we need, if we need one do we need an event loop documentation.

E

Who knows what framework for location some, because it's very wide topic and I think we're trying to resolve it from very small site, and they did more. We discover the deeper questions we touch. Let's first touch the bigger questions and then dissolve the actual implementation details because they invoke the dot design involved of invoker's implementation. The tile of communication problem might be a.

B

Print, so this part of the document is to an abstract one. It doesn't touch communications too much so.

E

So my proposed so my proposal on this document after we just move it move it toward to this service isolation folder make it so, let's, let's keep all of those documents that relate to service communication and service reservation in one folder star directory structure. That is a folder services, relation move it there. Let's, let's keep it there. We might not share another order. If you don't might be my match this document we will edit it later, but let's switch focus a bit the words fire, a bigger question of communication.

A

You know I think we need to qualify.

A

Here because I think rest, api powers.

A

Possible this communication: is it correct.

E

Yes, fever right, but but oh it's under patch I see he has two to two proposals today right and both make sense, but they only make sense if, if for specific designs of communication sounds so the more we is the more we talk about the service reservations, the more we understand that we might want to review the communication model today and we might want use a lot more communication than the rest API. It's there and service contract and rest exposing service contracts.

E

Rest API allows today right, so we so to propose to Alexander's of Allah grants. Proposals depend on the communication, design, I.

B

Don't see, especially the promises.

B

A

We agree that we want to break it down right and move to relation folder.

A

E

We like, if someone, if anyone wants to create a design on communication, you can either create a sub document or as a sub section of service isolation design, so that documentary the world don't feel free to to create food requests to edit. That document itself.

E

A

Agree on what documents we expect and what we are ready to March I want to know something.

A

And stories communication.

A

E

Least, specifically, a lot of so this functional requirements that the workcenter described here. A lot of this functional requirements should be moved to to communication documents. They're not part of there is not a question of invoker at this, so you can you can you can find out these couple topics that you want to the documents in here in this functional requirements.

D

Do we agree? Sit-In Walker will be masking a type of communication where it's synchronous, asynchronous.

E

Again, it's a good question to answer. I answered part of it in the service service reservation document, where I stated that we are, we don't want to mask the type of communications of an ideal world. In my opinion, all the services, all the services are decoupled in place in end time, so remote communication decouples behavior from in place. If communication is synchronous, they are still coupled in time. So we want to have other communication.

E

Are synchronously have services decoupled in time, but if you have a synchronous communication and then mask it with synchronous API, you still have that coupling, because you still did you still have dependency so I would I would I, don't think that it's a good idea to mask a synchronous communication with synchronous again, unfortunately, all almost all Magento service contracts were designed to be synchronous, calls.

E

And again, and that's why I think we should be moving or generally, we should move. It should be moving and should be designed for synchronous communication and that's why I like some of some of the proposals here, especially I, think it's important. It will be important for us to introduce some work to decide what a synchronous communication we want to do what, when promises fibery. So we want to build and that's why, by the way, what's under I I understand what you say that you say that it doesn't depend on communication.

E

I, disagree, I, think it depends on communication. Most probably will we'll need prompt design, but but let's first agree discuss the overall communication, how it happens in more details because I only touched it Apple times an hour, but it requires a lot bigger research and a lot bigger discussion and when we have the general agreement Harvey to communication. Only after that, because details like promises.

A

D

Documents before women are.

A

Smaller documents right for specific topic and understand you say that first, we need to review communication and agree on how we do communication.

B

E

You can you can move both promises and and false promises proposal and- and this proposal moves include service isolation and merge them to keep those documents mark them as mark them as the stuff, like version one iteration, one of the design, so that people understand that, so it won't still be discussed.

E

A

Let's, let's break it down and let's discuss, let's have smaller parts so that we can agree to something and much what we agreed to.

E

That's a good point also and the send the window I just want to minimize the amount of work in progress. All of our open pool requests are working progress and can support coming the way to confuse them. We want to. We don't want to keep. We don't want to refuse the request because they'll, probably most probably make sense I said, but let's keep them as they. Let's have something to iterate. Let's say that this is the first iteration.

E

It makes sense for separation, let's match it, and then, when we have a clear picture and clear your document or part of services, relation document about communication, we'll say we'll come back or create a pull request towards those document of promises and and that's my proposal, but you guys decide how you want to do it. I.

A

Would know if you can split it into smaller parts? Maybe you can you can do it and like keep keep this pull request Aziz. So this is the base information that you have and then have smaller, pull requests into like in in the services, isolation, folder, something that we will be able to discuss again and merge. Maybe just your work with me, eager and anthem, or just ask questions in the intellect channel, so we can not wait for the next meeting but discuss as you go with this document.

A

I don't know, I would rather keep it keep. It is an open pull request button or something that we agreed to. It's gotta be smaller. It.

B

Would have to be closed sometime if it's not going to be not a lot of examples and points here is that I would not open it to smaller design documents.

B

Declaration, Oh, I, think so smaller ones.

B

Because they intersect with different different topics, the examples I provided.

A

Okay, let's, let's discuss maybe after limiting I, think you'll agree that we need to split and we'll need to figure out. What we do is this blue quest right? Let's maybe discuss separately what we do.

B

But my next topic promises I, don't see how it depends even on this topic, I just.

A

E

Doesn't depend on this topic.

F

Communication I.

E

A

Wanted to ask I, don't know if you can let a lot Jade go before you, because he'll need to leave lighter if you, if you can, if you can sleep yeah.

G

I was gonna say that it's I only got about 15 minutes now. Let me share my screen.

G

A

G

Let me get rid of the.

G

Okay, I, don't know how to move the zoom stuff or the yeah there's some stuff out of the way, see it's getting in the way of my tabs. Okay, so.

G

There we go so yeah. This is the technical vision that I had set up I just wanted before getting into it, show this header of this article here how it feels to learn in JavaScript in 2016, still pretty relevant today, there's just a plethora of technologies to to look at it's very difficult for people to understand which ones to choose so I think this is.

A

Just click and hold left mouse button and.

G

There we go. Let me get that off there we go okay, so yeah, there's already been people reaching out to try and figure out like how to ramp up new JavaScript projects, and you know this is what they're faced with they don't really know what to do. So.

G

This is more of a general document as to what technologies to use and why and then we can kind of fork off this idea for specific projects, because every specific project has its own architectural requirements, but I did want to point out some key components: they're pretty important for front-end applications in general, like portability, I've, noticed a lot of people building components in such a way that they just can't be used in any other environment than that one, and you know just keeping in mind that we might be interested in having certain components being used in different environments.

G

Different pages stuff, like that right so extensibility is, of course, a huge magento factor. You know being able to extend a component I think that word is a little bit abused currently in Magento, because, like our current extensions, don't really, in my opinion, extend anything they more just allow you to manipulate existing things. It's it's violating the open-closed principle. So you know this is more of a extensibility concept that I wanted to emphasize, and maintainability has a lot of facets to it.

G

Human readability code review stuff like that that we can actually make adjustments to things without being too thrashing with everything, consistency, performance, accessibility, that's pretty important, I, don't know that we focused too much on that in the past, but there's some some points to hit on that one internationalization productivity and quality. So those are pretty much what I'm focusing on here with most of these decisions down here, but just to start with react, because that's a pretty popular topic right now.

G

What kind of things is react gonna bring us to the table right, it's going to bring portability because you can have it run in mobile environments, pretty much any environment that you want in terms of JavaScript and you know performance. It's definitely way better than some of its counterparts. Productivity I'll, hit on these points here, so without just reading this document out loud I.

G

Don't I. Definitely don't think I have time for that. But you know, let's see.

A

Is there anything that.

G

Yeah, is it not already public or oh you mean like.

A

G

This public I already already pass it off with with Andrew and fixed his points I wanted. Also to how does that Lynn weigh in he was planning on it just to kind of see if we can align I'm I'm, seeing you know examples of the PWA app in terms of their technology decisions as to how they affect future projects as well. So I would like to get him to weigh in on some of that before making it public, but it doesn't look like he's jumping on that, so maybe we can just make it public. Let's.

A

Make it public and we can I, think you can find people in communes. You can also look at it. As you mentioned, the AIDS I think it's really great document use a lot of references. There.

G

Yeah, it's basically just consolidating this whole thing and kind of focusing on the parts that are relevant for a modern application. Just at a very high level, we've got react type script: we've got the Adobe spectrum components called out for a reusable component library and just a guide on like downloading third-party packages and what to look for. Sometimes people need some guidance around that because it can be a tough decision, see there's a whole bunch of links in this document.

G

If you've noticed, there's just hyperlinks everywhere and I go into Styles a little bit with CSS modules, which is what we're using in the sales channel, client repo currently, and also how typescript can leverage those CSS modules and, let's see yeah another thing. I wanted to talk about was code, climate I, don't know if we have an account or anything like that for continuous integration.

G

Well, we do have Travis CI, but for code climate, it's more of a Quality Score, given your code, if we were able to sign up for that, we would get better insights into what we're actually committing with our code and if we're actually hurting things with complexity or if we're making things better over time, give us more visibility into that I. Think that would be ideal.

G

Mm-Hmm but let's see at a very high level, though I wanted to see the react component library browser support wasn't too big of a deal. There was one thing that came out with browser support which is polyfill to I/o, and that's a really cool technology that allows us to basically get the best of both worlds like we don't want to incur a performance hit on people who have modern, browsers right. We want to give them the best experience without downloading all this extra crap that they don't need so polyfill.

G

That IO allows us to do that, while at the same time having outdated, browsers download only the things that they need nothing more in the way that they do. That is with with browser testing so that they can actually do a server-side. I shouldn't say that so they can actually just pull down the only the scripts needed.

G

They know what browser you're using and they deliver exactly what you need so they're using browser stack to do various tests and to make sure that certain features are working that whole test suite against it, to make sure that those features are available. For each browser and then there that's how they're determining which scripts to give you so I thought that was pretty great, see business yeah so does anyone? Does anyone have any specific questions about any of these high level topics? I can dive into a little bit more or concerns react typescript, Adobe Spectrum.

G

You want to hear more about Adobe spectrum, there's some stuff to say.

H

Okay, I have a question regarding performance testing. They have any documentation about this. No.

G

I didn't hit on that at all performance testing. Now.

H

Okay, I think I can.

G

Add a session sure, okay, yeah so I can add that, but it's not in this document currently.

F

G

Me, let me add a comment there.

G

Now are you talking about performance testing at a like a unit test level or something else? It's specific.

H

All right, for example, a component we need I, do like unit or integration performance testing, but from magenta seem at all I need. We need to test I beam, all process, so how I read it browser how every action is per performance basis and we need to see how to exist, integrate some measurement and methods in our work to easy test performance. So.

G

Fortunately, just already provides that out of the box, if you, if you're, if you're talking about like complexity and render performance stuff like that you're gonna be able to do some just snapshot, rendering with shallow rendering and also you can. You can go step further and do some integration, tests and whatnot, but just will tell you certain tests are running slowly. So as long as we focus on more of a full coverage strategy, we'll be able to see that in our test reports, it'll it'll show up readily. Like you know, this is taking too long.

G

So if we kind of get that for free in some ways, but if we're looking for something more third-party to plug in that will give us better insights in the performance, I can do a little bit more research. There.

H

One thing I expected: we need to track performance without databases. Some process like.

G

Make sure that that future, the future code isn't making performance worse, you mean something like that yeah. So that's another thing that I think code climates gonna give us is mostly it's it's about complexity, right like if the complexity gets worse over time, we'll know about it. So I think that's an important point to hit on with quality. Maybe I can add a few more blurbs of texts about that, but I'll also do a little bit more of a dive into performance testing, see if there's something third party we can.

G

We can plug in that'll, make that more more obvious from even without using code climate, just from a purely state testing standpoint. Okay,.

H

Thank you, yeah.

B

This performance is.

F

B

Will use like our web app ice containing business for just.

G

Right yeah, so this is it's a front-end tech vision. It's nothing about the backend, so in terms of API is I. Think I briefly touched on that, but I didn't dive into it too much about.

B

We have to test not only performance of like rendering elements, but whether that they I say used efficiently are.

G

Used efficiently, can you can you elaborate on that a bit what.

B

G

Additional night scene.

B

Makes too many requests unnecessary like too many requests right.

C

Yeah should be just as well, not just rendering.

G

Well, yeah I did I did hit on business logic, so I was actually fighting for a business logic repository that's separate from any individual projects so that we could reuse that business logic across projects. You know we can. We can put as much as we can in API services layer that would be ideal, but also having a business logic repository that's written exclusively in typescript under percent test coverage. You know just being able to have that as a separate business logic.

G

Layer I think, would be a good way to test those things in isolation without the components that use them specifically right.

G

Does that satisfy your.

B

Mostly, if those business logic repositories, there would be just wrappers around Weber pickles right.

G

Actually, no, those, no it wouldn't because the business logic repository wouldn't seriously wouldn't be doing any I call calls at all. That would be more the responsibility of in the case of react. It would be the responsibility like Redux actions, so yeah we test Redux actions. Basically, each action has like a single request, maybe at maximum but having multiple requests.

G

That would just be calling the same action multiple times, so it probably gets into complexity again a little bit, but yeah I don't know to what extent we would be able to test for that. I'd have to give that some more thought.

B

Because even like reduce actions, component may use actions and efficiently again, according to many actions, I'll.

G

Write that in this in this comment here the components over use actions and / API calls so I'll do some more research. There.

G

A

My dear a populist topic and you publish this document, people can add as a pull request to all people and people can add more questions. Probably when.

G

You say public, you mean to the architects repo.

A

G

Yeah I'll do that.

A

One may be moved through the next topic, so we have just 15 minutes left yeah.

G

I got a step out for the fronton guild preparation, CEO thanks.

B

Again, this document describes an API and the bit of implementation, but these promises and talking about they don't rely on how we're going to implement communications services or in Hollywood it's just where API for any a synchronous operations, I think if everyone's okay with it it can be merged. Now that further discussions about distributed magenta, okay, my reasoning behind introducing this standard promises is why control set future service contracts with most likely be asynchronous.

B

We need to think about using standard promises.

B

Requirements, I think that promises should not support for origin because it may look confusing I described it here it you can read about.

B

So the API have promised to have a method that accepts a callback. It will receive a single argument.

B

The result of execution, otherwise method is not a method which will be which they receive callbacks and would be those callbacks will be executed only when there is an exception that occurred during the synchronous operation. Those whole box will receive only single argument, instance of so.

B

The most important thing about the standards that promise can be used in his synchronous versus asynchronous.

B

This is required to prevent bubbling of having to use a synchronous operations without an exclamation apologies.

B

Basically, when you write one methods, it uses a promise and there is no way to wait for it when you have to return another promise and it just snowballs all the way. So you need to have a way to wait for a promise explicitly at some point to actually be able to return a value, not just another promise.

B

So, actually, in ghazal promises, weight methods, unwraps a promise, so it returns values that would be given to them all back and throws an exception that would be given to otherwise and I propose. We do not do that weight matter, just waits for a promise. To finish it doesn't return anything. It doesn't throw an exception. If something went wrong, so you would have only a single way to get the result and get exceptions.

B

To avoid confusion is to set all bucks for salmon. Otherwise,.

B

So we would have default callback for otherwise methods. So if an exception occurs, it would be just as wrong if no explicit, otherwise callback is provided so API. Second KPI should be divided to two interfaces. One is for a basic interface that were done otherwise, in rate. This interface is for client code to use like when the multitudinous a promise. This is what current code will be, using the way to provide go back for positive result, for an exception to wait for a promise.

B

If a comeback has already provided an exception will be thrown again to avoid confusion, and another interface is for a code to create promises.

B

It extends a previous interface, provides automated to resolve with a value that will be given to us on callback and to reject a promise with an exception that will be given to otherwise callback, implementation and I. Think our promises should be wrappers around causal promises. It's a well-known library. It provides a way to reuse the promises synchronously if you want to it, provides the weight method has other stuff like forwarding other tooth, but we don't really need them.

B

Why? What I want to use this library, particularly because it provides the way to use, processing, Chronos li, and it is well known and mature library, as simply we will just work fine indirectly, we are early already using it in magenta, I.

B

Also looked into react, pH pieces when they're usually provides some libraries regarding a synchronous operations. Their implementation for promises is based on promises, a standard which does not provide a synchronous way to use these promises, so it doesn't fit our needs also cause. The promises are used in a Muslim, SDK I, don't know. I was just googling whether someone has any problems with ghazal promises, I, don't think commencing.

B

A

Guess, that's it can you add links to the documents or just add, link to the ghazal promises, just don't Google about to go directly to that link and then about react. Php. Just to add note that you considered it and like why you didn't choose it. So we have it in history. Okay,.

B

Oh another point I went to hit is Anton said, like we may have event-based limitation of networking between services. I send Jenny request immediately getting response that it's accepted as an Wagin, a service that you called to call us back assume these promises can be used with that approach, just fine that they would be resolved when when we do receive that go back for simplicity sake, rising these promises should be used as response types for synchronous services, no matter how they actually communication with each other, because again, they provide both ways to consume them.

B

Second, as asynchronous whatever you want, and another stinker I forgot to write here. It was pointed out to me in web designer topic that it will be good to have utility just one rep. His promises with this simple well having a class that provides default, then default otherwise, and cause wait and then actually returns the value. That is the result and throws an exception. It was about one simplicity for third-party developers to use so if they don't want to make their quota synchronous, I can just use that utility like when they receive a promise.

B

Rep and it just returns, the value throws an exception. I think it will be useful.

D

D

What what is what are the benefits of making a synchronous operations synchronous? Why would we use this promise.

B

Would return them? That's my shot, but any personal separation can return them and they don't. They can't be used both synchronously and synchronously, and sync, it's crucial to provide the way to use them synchronously as well, because if you can explain these here, if you don't have a way to wait for a promise, then you can't return a value like from a method, but.

D

But this is benefit of a synchronous separation that you don't need to wait for the result you can just send the request and move on. You don't need the result I'm just trying to like understand. Why wait? Why do you want.

D

B

Like one service B process, there could be like 10 calls.

F

Cronos we make them are synchronously.

B

But then we want to return certain values.

C

B

A

So I guess, while you're asking about that eagerness, we can use it, for example, for a transition period when we will be still when we will still have synchronous interfaces.

A

If you have a synchronous interface in the API, yes, you may not wait and you will use promise as for a sync operation and you do not write your returns, for example, I, depression or whatever, but, for example, we might have a transition period when we will be still using those operations synchronously or like as I understand. It's just it's just a feature which is provided by by this implementation by the interface. But my.

B

B

Required this intermediate process, but some point yeah.

D

I mean I, understand the sense of functionality I'm just trying to see where, where we would use it for which operation and have multiple operations, as is, do we need to handle distributed transaction and if he hasn't have this habit would handle distributed. Transaction I mean it makes sense in isolation. But what is the real use case for this right now?.

D

Performing the separations- and you say: have you saying that these separations should not developed in the transaction? Only in this case it would work, and this is limitation or would does it mean actually.

H

In our technical vision, we have statements that all of our sales are should be a synchronous yeah. So, but we cannot do it immediately, because all.

F

Kinds of drones and.

H

We can make interface that looks like I suppose, but pork synonymous by n from this promise interfaces is builded. For this, though you don't know if actually the kata, synchronously or and synchronous, you used promise, and if you create you in this way that.

F

H

Can you from synchronous calls join us API I.

D

Yeah I understand this. On the other hand, the masking type of communication is anti pattern. You should be able to know whether its operations in Cronus are synchronous, but this might be a small concern but I'm just still trying to understand which operations like we would make synchronous and they would want to keep it.

D

Which operations we would make a synchronous and would want to make synchronous tag temporarily.

H

And when you use it, I see from the separation.

H

H

D

What would you make place in order also essential illness? All.

H

B

Some chrono separation doesn't.

C

B

It some cross just wait to finish.

A

I need to run to another meeting and we are running out of time. Can you discuss? Maybe we see grant add more like more use cases, more specific use cases and I, don't know I didn't hear any other concerns about this document. Anton mentions there that that you need to look at other libraries, but you already explained that so I don't know. If nobody else will be adding more commands.

A

Can you just sing quiz eager on what can be added to the document, to make it more clear, and probably we can one with it unless somebody else adds more.

H

Questions I can small comment. It's white bait method don't threaten the result. Just wait.

B

F

Yeah I didn't like I, said.

B

H

Method feel their.

B

Weight confusion. Let's say you have provided you have received the result, but then wait. Alpha returns the result which you may have already processed.

F

A

H

F

A

You please add it to the document as well. So that's good that we discussed it will not be asking the same question again: okay, let's wrap up the meeting. Thank you all and Alex. Please update the document. Sync was eager to add more to it and I think and then ping in our channel and slack and I think you'll be able to proceed with it.

F

A

Thank you all and see you next time.