Magento Architectural Discussions, 12 Dec 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Magento Architectural Discussion -- December 12, 2018

Description

Topics:
- Service contracts technical guidelines (@paliarush )
- Updates to service isolation proposal (@melnikovi )
- Checkout service - early draft (@melnikovi )
- Workarounds for blockers described in MDE Project Structure

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

A

I would want.

B

What I saw there was a proposal to switch from the current required Jas runtime, which we're cute that mm-hmm sorry audio problems are hard, so the proposal from Kirill was to you swap the require Jas runtime, which were currently on an outdated version of with a different implementation of the required Jas runtime, which supposedly has a similar API with I, believe it says some missing functionality, but I didn't look what that functionality is the the important parts of that for me, were the motivating factors of why we would want to swap a core piece of tech like that.

B

The reason I saw from Kirill were an open issue that the the async stack traces from requirejs were difficult to debug, and the other note I saw was that there was a performance improvement. I have some open questions on those things, though, because I, just if we're gonna make a change to a really core library, like that, I want to make sure that you know the performance. Winds are really there and that they're worth it. And then, if that were the case, we would need to figure out what the risks are.

B

As far as API breaks.

A

Okay, so you're looking at that, so you could apply some questions and then you'll see him wondering it or not and roll it is for for next minor release of magenta right. It's not something that you would change in a forum I.

B

It's probably dependent on how backwards-compatible it is.

B

Like if it was fully backwards compatible, it would be fine, but I'm I mean any entire rewrite of a library I'm skeptical by default. That will have complete api compatibility, but we should be any music.

A

Look at that, actually we don't have any other topics. I know that Alex was mention talk not so.

C

The description.

A

Okay, I didn't see that okay, so do want to talk about it.

C

Our guidelines- this is request to our damn dogs and specifically I'm, currently working on addition, guidelines specifically for service contract layer, and we can just go over all items which most better there and if you have any questions, we can discuss them later or you can just start participating in discussion and I already have a bunch of comments there and I addressed some, but not all words yet and hopefully, by next week, we'll merge it. So.

C

So, first of all, it talks about location of interfaces. They should be placed in separate API modules, which is not common at the moment, but you have examples in MSI. It means that if you have my module, then if you want to expose a pipe I will keep air for this module. You should create another module, called my module API, and this will allow easily switch implementations of the whole module. And basically, if you have some other modules which depends on your module, they will depend on this API module only.

C

They should not depend on implementation module directly, and this will allow easy swap of these implementations.

C

Service interfaces, which should be exposed as far away P I, must be placed under this directory. So it's like my module API, then again, API service and service data interface is replaced under API data. This is under discussion of the range of options, I'll say to remove API completely, but we can discuss it and for now, API is left here, because, first of all, they already have all modules with a pad directly to probably be easier for people to understand it.

C

Even in API module you have API directory and then it means that its public, API and second reason is an API. Module may also contain let's say models and what will go into model and they actually fall in same approach has done in MSI. It was also discussed order for some time before implemented this way. But what can go here is some trivial implementations like chain and composite, and they will be set as default preferences for specific API.

C

Additionally, it may contain something that should not be exposed as a reply, or it doesn't make sense to be exposed as for API.

C

Usually, it means that this, like a PSU, actually be SP eyes, like service provider interfaces or basically extension points, but we don't want to name them explicitly as SP eyes, because it might lead to confusion for most of developers who don't know what it is, and we believe that it will be easier if we will to understand that if you have a path- and this is like through public API- have the model, you should use it as a client.

C

And then, if you have model, then probably this is something that you can use to extend functionality of.

D

Excuse me so I would like to go back to previous four six, four one two, so this would be a breaking change right, also Wi-Fi, introducer folder. We.

C

Are talking about new module phone? We are not talking about refactoring. What's.

E

The point I understand, but.

D

What's the point.

D

C

The point is actually because of this items and exciting, because arbitrary Direction item can be allowed to improve code structure and at the moment we usually have API. And then all services are infrastructure under this bed directory and we have data for data interfaces. But if you allow hierarchies, then data will just get lost among other directors, and it was.

F

C

Usually visible.

D

I think it's one of those things where we should stick to what we decided before, like.

C

You don't want to have hierarchies or I.

D

Think it's question I mean I. Would I would personally like our case, but we decided three years ago. I wasn't I, didn't like the decision, but I agree to that majority decided to have flat structure for service contracts and majority decided to put service contracts in API, folder and data data interfaces to beta folder service contracts are fairly new in magenta lifetime concept. So I wouldn't change that behavior, but.

A

Like any document an agreement agreed, it doesn't mean that it is this I, don't know if ooh yeah.

D

A

D

Don't I don't see a good reason for that I mean I.

A

Think what Alex just explained the data folder is just sometimes.

A

Many things in one module: yes,.

C

So currently, tea won't be lost, because this is the only directory under API. Was it woman? No other directories are usually allowed or it is not recommended. I'm, not sure. If there are any technical limitations against arbitrary directory structure. No because position you can do any nest and energy was to work.

D

Let's start from the folders yeah.

C

The strong reason to introduce.

D

Set, yes, all nothing like all same old, same argument still that were there three years ago, when the decision was made to matrix flood, they still have nothing change right. Now we change our opinion.

A

My background, what were the reasons I was not.

D

Even worth that and a developer can open a module and immediately see all operations or all interfaces in that yeah, for example. Yes, so you can immediately see all operations that we can do that module exposes.

D

That was my argument to the decision was made years ago, because some more people liked it on structure right.

C

That there is actually one more point by structure is important. Now, because we want to allow single operation services, and it means a number of services will grow even more like we can see that even without single person services, we have like a bunch of them inside.

G

C

The catalog, but still- and if you allow this like single operation services like we already do in MSI and like we believe, agreed like for all new implementations, then you will have like x 3 by 4, so I believe it will be just easier to read if it's like structured but I would not refractor any existing implementations because I don't think it's.

C

D

Will just introduce one more way of doing things.

A

What is this limitation needed limitation of structure.

D

It doesn't matter that much now right, it was decided. Also. His contacts were implemented this way. So now we need a super strong reason to change it, because so because we will have some, if you change it will have somebody's.

A

Are you sure that everything is implemented in that way like MSI, for example, all.

D

Modules are implemented, is flat structure.

G

D

Can check it, but it doesn't matter even if was not implemented. This way didn't change a lot, but but at the same time we do not add new restrictions. We just loosen existing restrictions that.

C

D

The problem everything is polluting, Magento, we have so many different ways. We have so many different ways of doing things that it's like every time you open a new.

C

Module, which is something different.

D

C

That's your fall. This approach, I can't approach mm-hmm.

G

D

Have to stop at some point oops if there was a strong reason to do this. Okay and again, I'm I want to emphasize that I, like the approach of having structure more just but I, also like the approach of being of stopping doing changes. If, if changes are not absolutely required, so here, I think the consistency is sticking to made decisions should be there.

C

Could you please leave all your comments, also in the document, so for history? Sure, ok, so the service interface structure, methods that have similar purpose must have similar I'm.

C

Sorry, methods that have similar naming must have similar purpose, and basically it means you shouldn't have to method safe, which behave differently even in different services, because you should not be confused by knowing let's say how catalog works, you should not be confused if you go to some other module and it has similar modules, but they behave completely differently and it can also be true for I'll, say partial update.

C

Let's say if you have some saves in one modules which do replace strategy and some others which do like watch strategy like this is already confusion which you have, and we should probably avoid it and behavior of methods. Names similarly, should be similar.

C

Services must only operate on scalar types and service date interfaces, so this is current restriction because of a baby ice I'm, not sure like. If any concerns about this one service contract should not be used for read, scenarios on storefront and it's more only on storefront.

D

Muted, so the previous point: what other types could they work with? Okay, I think I understand so no known the API interface visits and non-diet types cannot be used in service. Bouncer. Sorry, yeah.

C

So if it's non non data, interface or scalar or array of those, you cannot use it.

C

Interfaces right, yeah yeah, so you can use scalar data interface or array of those.

C

So we have more exact like list of arguments here we can probably combine mm-hmm.

A

C

I would be grateful. She was kind of like some common.

C

Service contracts should be used only or they should not be used for storefront scenarios and graph kill should be used instead for storefront.

C

So do this right, we discussed at this part of for the television.

G

C

Shows interface should declare single public method. That is something new that we try to promote right now, and the idea is that we have less dependencies when we injected say service interface for some operation we have less dependency injected phone and he'll more granular interface, so it also promotes single responsibility and interface. Segregation principle and the names should be as verbs for now. We had also discussion how we should handle.

C

Should it be now, let's say, stock source link the litre interface, oh, it should be stocks or delete, conferred and so far I believe majority inclines towards verb, and the only exception which we decided to offer now is repository for convenience and repository must be limited to card operations and all other operations should go to individual service interfaces and repository should have card operations, including get list, so crud should be done on singular entities.

C

Contract should should not apply presentation, therefore modern to return data I believe that's obvious, because they are not part of presentation. Their.

C

Service interfaces represent main entities and can reference related data interfaces, so it means that if you have customer, you can have links to customer addresses understood to be honest, why this point is important.

B

C

Was migrated from some previous discussions, anybody.

C

If not I'll, probably just.

C

Service data interfaces must not contain any business logic, they should be presented container of data transferable over the wire and all business logic should be moved to services. So it basically means that our data interfaces should be just data transfer object and they should be just dumb objects with at the moment, getters and setters, but I believe we are moving towards some illumination setters as well and making them immutable.

C

Strict typing is enforced for services and data interfaces, specifically under API directory like under model I. Believe it's not enforced and I'm going to expose it as well. Italian. That's why we don't have framework restrictions and I know. Public component is the point here and what we specifically along with color types, allow that interfaces.

C

We allow one dimensional indexed arrays. It's also important, because sometimes people try to use associative arrays and they didn't work all the nested arrays. They will also not work because they will be properly translated into would say, soap, object, notable scalars and data interfaces also loud, but just now is not allowed and too recently, I believe a Massiah project implemented. Support for void. I still have some questions in discussion like how it's supposed to work in the big guys, but oops like it is already supported.

C

Okay, so then service contract should support much data whenever possible. This is again new direction, along with granular interfaces. We also want to make them like watch interfaces.

C

It means if entity is processing or, let's say, saving some entities instead of making it safe one entity, we should always support array input and in such cases, customizations will also expect array and they can be written in more efficient manner and insane for our implementation. When we operate and watch, we can do, let's say, singular or a single insert into the breeze.

C

Instead of multiple requests database and same for customization customization may perform one operation, one I'll say in certain database for all entities instead of doing it, for each individual and and what retrieval must accept, search criteria and return search. Result like like it is like it is now for all get list operations.

C

All services that modify state must support us in transition. Okay, so this is probably something that we are going to remove cause. We still had more discussions and I will replace this with statement that on service contract level, we operate synchronously, but we will add ability to do a synchronous invocation where our synchronous for API or in the future. We may also consider implementing some asynchronous in water on HP level 2 this execution, we our message queue.

C

So probably we can skip it for now.

C

Data objects returned by service contracts should be fully loaded to ensure consistency.

C

This is currently a problem for get list operations and they get operations on repository because get returns, full object and get least claims to return for, but not all, data is loaded, usually and I believe our direction is that we need to return fully loaded objects, even in case of collections or in case of like lists of object.

A

C

So what I mean I would say if you look, if you look at actually, we can take a look.

A

For the get least, which belong knows that it's not yeah.

C

Yeah, so basically here you have I'm sorry. So, let's again you have category interface as a response and then at least.

C

And then here in search criteria, you'll probably also get.

C

But basically you will also get same as a result of get list, but you never know that at least doesn't actually load all attributes and it's confusion.

C

So the idea is that it doesn't matter how you get the data you get it like get or you get it vague. At least, if it claims to return category interface, it will be full particular interface object.

C

Okay, so then something related service implementation.

C

So now we say that also is that interfaces must extend from extensible data interface unless it is not desired in case of well the objects, for example.

C

It's not mandatory on framework level, but I believe you want all our entities to be extensible. That's why we have this.

A

Most should if you say that there is an exception.

C

Okay, yeah: can you leave this comment? Please I suppose we can extensible. Data interfaces must inform hierarchies.

C

For example, if you have my interface, which extends extensible that interface, there must be no other interface which extends my interface, but otherwise all of these interfaces in hierarchy will share the same extensible object and you will not be able to create one extension to build one of the objects and the other extensions before the other, and we already have such problem for product attributes and category attributes, like those objects, are extended from catalog attributes and because of this like, if you create extensions built for product, it will automatically appear for category and vice-versa, and you cannot support it anyhow.

C

So that's why you must not do this.

C

Service, implementations and plugins for services must not rely on any storage. Specific integrity features like foreign key constraints. I believe this is also clear.

C

Replace strategy should be used to persist my entity field and attributes child entities and relational enix.

C

So this is probably shouldn't be joined with the statement that you should promote entity, because this is related to it doing, update operations will be I should use patch, TTP method and action controllers that accept, and it is should to loads and first and then no request data on top of it and provide full data to the service, and this is something that currently doesn't exist. I, don't believe you currently support patch.

C

First of all and second I'm not sure how can we do preload of data in a framework really full, but in action controllers it makes sense so and I believe the government alo was one of the proponents of this item. Like best, do you have any ideas like on this one.

C

So, basically, what it says that you should not load entity in service contract like preload it, but you should throw the before actually and walking. Service contract and service contract should get like full object.

D

C

What do you mean preload? So if you would say say category update and you want to update this category name in your API. You say you send just category name and category ready and what this statement says that Web API framework should reload category object. First then apply name on top of it and pass it. The service contract service contrac should get full object.

C

Because, currently we don't have such capability and currently it's service, contract, responsibility to preload, object and then merge should say updated date. On top of it.

G

C

Then did you get yeah so does it.

D

Make sense yeah.

D

G

D

The dimension of action of controllers- you get rid of them.

C

Yeah, but we still have them for some time and you should say: okay, we can discuss it later. So if service method needs to return, modified version of the argument, original object must not be modified and you should basically create a copy of the original argument and return modified version of it basically done modified copy.

D

Actually, sorry so.

D

So I, wouldn't to get back at the previous point, I I would I would disagree in that we should not end it. So basically what it says you find the student correctly is that a service contract must not expose patch API right, I. Think so. Yes, so I wouldn't put that restriction to a service contract. If it says update something it, we should support the ability to update to do partial update for entities you.

C

Can also live commentary balances because, like.

E

C

Discussed it is a criminal abuse and.

C

Should not apply ACL rules, two methods were returned data again. This is migrated from previous discussions, but I believe what it means that a CEO should be applied on the babyís framework level or HD applied on current action controller level and not on service level.

C

If multiple data scopes available within one service call only like entity vision, one scope should be modified, so you should not have service contract which will modify, let's say product and also use simultaneously. It should be scoped like it's. Your question be scoped and then exception. Handling service must not throw exceptions, define this part of like as a layers, but instead they must drop like lower layer, lower layer, exceptions into service contract layer exceptions and only throw those attached.

A

So, as I mentioned in the comment, I think this, like this one, duplicates what we already have. We have it more generic okay.

C

A

Layer should throw its own exceptions. Okay,.

C

I know probably just remote and believe: that's mostly it. There is also one addition to what technical vision is, and we currently have just one technical issue, but I believe we will have more of them and I will just briefly read it and if you have any concerns, so imagine technical vision is a collection of documents that describe desired state of Magento product, so key phrase is desired state. It may not reflect current state each individual technical vision document relates to a set of modules, logically grouped together.

C

So usually we have a set of modules like will. Sever will be I related modules, which can be grouped together and I, believe it make sense to create technical vision for the whole group, not for individual modules, let's basically what it says, and individual documents typically describe components place in a system so like what is the relation to all other subsystems, its architecture, extension scenarios. This is also a believe important for to understand how this component was intended to be extended, because extensibility is central park like because it takes central part in magenta.

C

This viability should explicitly described all extension scenarios and also list of invariance just must be preserved at all times during component refactoring or extension, to ensure consistency and what it means. We should state a list of restrictions which were taken into account during initial design and implementation of component, and we need to make sure that, with all future modifications, we will still go over this environment least as checklist and make sure that we don't break anything that was originally intended at least unintentionally like.

C

If you want to change some invariant, it's fine, but we should at least make sure that we are not breaking something accidentally and I believe that that is also important to list it explicitly for each component and purposes it like. If you have any questions we can discuss.

A

Good any questions, not if not you can move on to the next item, so I just wanted to ask about how specifically should add topics to to the discussions as it's mentioned in the ticket. Please add them as comments and what it gives is and I can understand who who is going to speak about it, because when it's just add it as a list, I don't know and also please add timing.

A

So, let's move to the next one updates to service isolation proposal. Is it eager?

A

E

A

And we have one more topic eager: how much time do you need I.

F

Think for this one they need five minutes and for the next one, probably 15 years.

A

F

So, updates to this to service resolution proposal, I added a couple more. A few more items to general design principles. First item is that each request must have relation identifier. So later we would be able to I identify request that a part of the same flow, for instance, if we have add to cart operation BFF.

F

What would send the request with correlation ie and to one of the services or to multiple services and services may communicate to each other, and then they will be passing to chassises correlation ID and when we need to debug and see and find logs for all of the.

F

Requests for all of the parts of they said to cart the quest you would be able to find in a data files and by this correlation IDs. It will be passed every every service, so then service match I must be used for communication between services and responsibilities of serious mesh would be routing load, balancing.

F

Talked about all of these items, I just added them to this. Also services must not manage session operation have to explicitly declare our required arguments in those have a mesh with the best. In the request.

C

Actually have one question regarding correlation identifier: is it supposed to be somehow done, but like managed by framework and not exposed into service contract interface, crap.

F

Possibly, yes, we need to think how we will be implementing it. I see so far, three ways how we can implement it. One way can be passed as a header. Another way it can be passed in the URL and short way.

F

It can be passed as a part of as a data, but but we have to have to decide which way we want to use the printing on it may depend on the protocol. Services will be using for communication.

C

It just looks suspicious if it, if it's part of data, because then we will have to introduce breaking changes into all our service contracts, which I believe is not desirable.

F

Maybe not all because service contracts, what we need to keep backwards compatibility for is what is exposed on the BFF. Everything behind a BFF technically can be a new API but yeah as a data. It's probably less desire. Adoption I, think is better with obstinate Eric. So far is I seen it in the euro, but I didn't dig deep enough. It's it needs to be researched, but I thought that we can add this as a funnel and decide how exactly to do it later.

F

Alright, so this is our update for this document. Then I wanted to give an overview of very early draft for the check out service, and it contains I described some of the design, suggestions and solutions to existing problems. In this document and communication, communication, monolithic, checkout service.

F

Okay, this is better.

F

And communication between and communication is check out service and the manolito our services. If we decide to separate multiple services, so service should have its own core config data that would contain setting specific service service was API that modify settings since the kinetic data and no should edit in settings in soccer, but the base settings for BFF or monolith or for individual services.

F

We are a remote cause, so the idea is that admin would be able to edit settings in one place just like he couldn't lead us, but some of the settings will be local configuration and other settings will be settings of different services, but I think for for configuration.

F

It makes sense to have this core config, that and on each service, because we will still have different scopes and the the form what we need to store in the database doesn't doesn't doesn't change. I didn't see that the change so make sense to keep it services service should not have knowledge about stores website. However, as a service, some services store.

F

This information is the data. For instance, a quote contains information about a store and check out service stores. A quote it makes sense to.

F

It might make sense to do validation, that we have correct store, Pest with visa quote, but on the other hand, if we apply this to stores- and we would need to apply this to a lot of other data, for instance, products Co, so I would just proposed to not not to have.

F

This validation admitted basically check out sir. We should not have any knowledge of existing stores or websites, and it will be passed. What is he sent to him? Then? We have directory data country, city states that have two needs to be shared between multiple services in the future. The suggestion would be is to move this to two configuration right now would store it into that evasive. If it's in the in the configuration, then we can reuse this between multiple services and this data almost never changes, so it might be okay to keep it in.

F

It might be better to keep it in the configuration, as opposed to have a separate service that would contain data's. It almost never changes under.

A

Configuration which configuration XML.

F

A

You specify it because, for example, we have system configuration she stores in database like core config data that you just mentioned, using.

F

F

Let me denote very quick.

F

Operations that are currently per item, I need to be.

F

Need to be grouped and done for multiple items at once to reduce number of course.

F

Princess when we even the load collection of quote items we would for each of the items. We would load inventory information to to make sure that all of this item still in stock and they exist in the correct quantity in in the cart- I mean this correct increment.

F

So this, ideally we get this information for all of the items in cart and all at once, because we may have a lot of items in especially in b2b. Shared interfaces like princess product interface needs to be moved into if a modules about compatibility.

F

Modules and the world named after it configuration for extension, attributes moved to adults.

F

This may not stay assess because there are problems with sharing interfaces. Product interface in the catalog have one meaning in checkout service. It has definite, meaning not olives. Product attributes needed in checkout.

F

For instance, images are not needed in checkout service and the way in the way is that interface implemented also its its challenges, because some of these interfaces are models that have dependencies on resource models and she want to initialize the resource model. It will be loading information about evey attribute, for instance, if it's, if the same so there are, there are some some challenges and you probably would not apply to all of the interfaces at send.

F

A BFF should expose I'll quote and other services that we would separate API of the quote, and the service is that we would want separate and work like a proxy for costs to maintain backwards, compatibility for a Web API, now, communication between monolith, application and check-out service that we are separating. So this is this is a current state of communication. When we aid in product to cart, you know it will send request to check out service and support service.

F

You will be doing all of this cost of different modules in it magenta in in monolith application. We have total in total about twenty three calls on open-source commerce will add one more cow, so I did some I did some analysis of the skulls amongst calls and needed, and.

F

I'll sort about some optimizations that we can do like princess pass customer with all of the data as argument, so the g-code service for customer remove.

F

Remove inventory checks.

F

Potentially, what we do, we do inventory checks every time we load code, so we can display message for each of the item in the shopping cart, whether it's still in stock and whether it's the quantity has correct increment, so potential is checked, can can be nothing to be performed on on a record load, and maybe this could be separate operation, but I did not.

F

This decision can be relatively easy done. This I have a state with some of this optimization supplied. This optimization is not applied yet.

F

Totals totals may be calculated after adding product to cart in a separate operation, and this is also something that is not applied, but we may want to consider it. Total should not be calculated on each cart. Page load also not applied, but need need to consider because we may need to. We need to calculate Auto when.

G

F

Changes or when product data changes and if none of these changes and we need to calculate total on the cart Lord, create service photo loss calculation to reduce number of calls to BFF its implemented later in the second diagram group. Cost is the same service.

F

Some sense that we can consider, but I did not account this in I did not. I did not implement this yet in in this in this diagrams, because it can lead to share in a state which might not be good after active. So this is a optimization that I apply to receive this kind of communication.

F

As you can see, we have one two three four five six about some seven calls, and it could be, of course, more or like couple calls more couple, calls less it very, very rough estimation, but we could pass customer as argument. We can aggregate some calls.

H

Why do work with duplicated API of inventory.

F

That's a good question: I need to know, I need to use new I started this prototype.

F

Like before, we released.

F

F

So this is this: is the state that we can get two V's, some basic optimizations, as you can see there is, there are still quite a good amount of calls to the monolith application.

F

If we, if we move total service, it would allow us to eliminate one call to to multiplication, but with these totals we will have to move also other services because they will be making calls to multiplication and in in that case it.

F

So I also looked at the place order operation by complexity.

F

It's similar to it's similar to it card. It's it's only it's higher actually, because we need to it. We have the Lord quote multiple times in in place order operation, and there are some some additional cuts- a number of course number, of course more, but we can probably reduce a number of calls here as well. I didn't investigate this yet, but.

F

So, transactions as.

F

Water service still part of the BFF. After after this, after this iteration, we didn't need to worry about rolling back order.

F

F

We need to, we need to roll back. We may have a case man. We submitted order and order submitted successfully, but after all the order is submitted. We need to update code basically deactivate the code and this operation may fail. So if the, if this is the case- and we just need to retry quote operation- I- didn't look, I didn't describe how this can be done here, because this is a concern that is general and applies to all. Services should be described.

F

The separate is the same as reporting and assess the questions that still open and not to be investigated. So format of of the data API receives is different from the format service contract contracts use in some cases, hydration extraction for certain entities triggers interaction with with the database code. Reuse problem should be reuse as the same interface on the different services.

F

The represent conflict probably have to do this visit when I did product cart product.

F

Oh, this problem is applied in many files.

F

This is quote items, whereas files should be stored should be should should should they be stored on the BFF or like the preferable way. But more complicated said in this files, then.

F

There are some.

F

Some api's it needs to be refracted and eliminated.

F

F

Yeah there are some repairs, it needs to be refractor it and maybe eliminated. A product model is very heavy. It has a lot of data set, is not service.

F

But a lot of fields are not part of that in places.

F

I think it's so this is the draft of what I have please. Please leave any comments or concerns.

A

Ok thanks again, yes, oh please, please take a look and back ok.

A

H

Had once brought subjects just to clarify whether we can use workarounds for the MD design or not I, think 5 minutes would be sufficient. This.

H

So we have multiple projects which are which are going to use the MDE project structure, which we have already documented on the architecture for the terrain, and unfortunately, some of the blockers are pretty hard to fix. We've spent some time investigating whether it's possible to fix it with limited resources and deliver the fixes, but apparently the first one. The amount and place load inside or outside of the project seems to be slightly bigger than it was expected. Initially, this this whole thing makes more blocks the delivery of some of the projects we are doing.

H

For example, we are looking to use this project structure for the Adobe analytics integration and for the Japanese localization and potentially for the multi-source inventory. So multiple projects are looking to integrate this and well. The main idea was to make sure that nobody is hardly against using the workarounds for now before the fixes are implemented in the core. So currently, what we're doing is supplying project repositories with the short manual which describes the installation flow for the users and testing showed that keeping the extension at the magento documents route is working.

H

Fine, so and no other modifications, apart from composer, consider necessary to on the system. It's slightly effects, developer experience, but it's nothing too major and most of the problems may be mitigated by configuring, the ide which developers using so yeah. This is pretty much all I wanted to share. Maybe somebody has thoughts on why this is impossible or if it's, if it's okay, for us to proceed this way until the the solutions for blockers are implemented.

A

Finally, this approach, if it works for for your project and for the final solution, are you still working on looking to like the final solution, or do we need to? Did you.

H

Know, I'm pretty sure we're gonna need some additional resources coming from other teams to fix it, as as we usually thought that only templates are affected, but actually lots of file system operations which are performing throughout the core are affected as well because file system it usually takes the document routes as the route for retrieving files, and this causes a lot of confusion when the extension is outside the project route. Okay,.

A

Do you have any document or any artifact that describes all the issues that suffice to I.

H

Face some issues and stop looking for more but I've updated the I've updated one of the blocker tasks and zero I have to take a look which one, oh just a second yeah I have dated one of them with the with information I found so far, but it's possible. That's not yeah.

H

These points like three and four at least, but it's possible that the scope of work is not limited to these points, because I've stopped the investigation at some points when, where I discovered that's well, it's pretty much impossible to pull off this fix just with limited resources.

H

If nobody has any any obligations and then we'll be proceeding with workarounds for now,.

A

H

A

Anything else, if not, let me just what interesting. Let me reiterate once again that when you add the topic, please add it as a command like, for example, that I did so in that way, I can see who is going to talk about it and also a duration like how much time you need. So you can understand what you need to switch to the next topic.

A

So that's one thing and the second, so we will skip our next meeting because sure the W will have winter shutdown at that time and next meeting will have on january 9th. If you have any specific topics that you want to discuss earlier, feel free to do the madhawk and just I, don't know find people you want to discuss with feel free to ping people in AB design and slack channel any other questions for today.

A

If not done thanks everybody and see you next time, thanks.

C