Hello 😉 does anybody has experience with big store setups, for example with several dozens of stores and its extra logic in it? I really like the idea of the codebuckets but I could think of, that it won’t make any sense to have everything in one repo, since it tends to be a monolithic approach in the end (have any code running on any instance). On the other hand, duplicating logic or multiple repositories to maintain is also something undesirable. Whats your experience with it? Cheers

You can have your own "core" sort of by adding your namespace to

$config[KernelConstants::CORE_NAMESPACES] = [
    'SprykerShop',
    'SprykerEco',
    'Spryker',
    'SprykerSdk',
    '<YourOrganisationNamespace>'
];

Thats something that came already in my mind, but whats the content of these custom core, when everything in the end is a customization for different stores? would it then be “storewise” core namespaces?

We have a pretty big store setup (16, 20 more to come), but as we host the all on the same plattform (AWS region and account) and a set of stores use the same features/implementations we rather used a feature flag implementation to configure which feature is active for which store.

but yes i see it as a solution for anything that applies in a general way to any store … the identification whats common and what specific might be the hard part … also because the role of “common” and “specific” can swap at any time when the project raises

The idea of multi cores was more based on the hope that agencies will create their own project independent modules that can be shared either among projects of the same agency or even as sort of open source among different companies/agencies. As far as I know there was only one company that used that concept (https://github.com/fond-of)

If it makes sense to separate project and your own core depends heavily on question if you will deployed independently (e.g.: 2 different projects using the same self written core)

The first question that arises is if it makes sense to split it into multiple projects at all … so whats the indicator / edge for this? b2b / b2c is pretty obvious, but region wise? When the features differ n% from each other? … on an extreme scenario for a b2b example, there are 20 european stores, 20 asian stores and 20 usa related stores and every store has for example an own checkout flow, so 60 code buckets … using code buckets but would mean to deploy every of the other “customized” checkout modules also to the instance, even it will not use it … don’t really know if this will really work out on a long term

We pretty much do the second approach, everything is configurable. But this works for us only because for now it does not differ that much (e.g.: checkout is pretty much the same for now). It's hard to give a general advice here on how to split properly as it has a number of indicators that have a different relevance per project. Legal: • can code legally be shared among stores • who is responsible for maintenance and bugfixes Build/Deployment: • Is adapting the build and deployment process feasible to only load the necessary modules (e.g.: is every store/project independently deployable and has it's own dependencies?) • Are the hosting regions already separated? Development/Code: • Is the higher effort of splitting, maintaining and integration additional code worth it? • Is the higher complexity understandable for the whole team and considered for onboarding new Colleges? This is far from a finite list, only a few directions to consider. As an example I already did two projects with a lot of differences between stores (1. stores are something like a different branch for example a store A would serve customers that buy anything around windows, another one B would serve customers that buy anything around sanitary equipment. 2. A store is a country based branch). 1. Here a separate core with modules makes sense, as there is a lot in common between A and B, but they are deployed independently and have individual features that are not common on top. 2. Here the functionality between different stores is almost the same, it might be that Store A does not have Feature that Store B has, but Store C has both features. But all stores are run on the same plattform and to utilize the resources as much as we can every Yves/Zed container can potentially serve any store. Here the code base has to include all features and we decide during runtime which feature is active, depending on the store and the configuration per store that is served by the current request.

These are very valid points to think about. Thanks for that summary!

yeah we run multiple stores in one installation. When we started there wasnt any multi store concept available and many things was invented by us.

That hasn't changed that much. There is a concept in the documentation to run multiple stores in the same installation. This is fine for a few once, depending on how many products, articles and categories each store has and how big the data is. But we still had the same experience. A lot had to be invented by us and especially performance wise it's a nightmare, as Spryker in his core will fetch all attributes for the concretes/abstract of all active stores at once during the publish, which obviously does not scale at all. Another one is that every container can only serve one store by default, there is no possibility to change the store that is currently used based on the request. Sure this can be implemented, for example by adapting the whole routing in Yves and always transfer the current store when Zed is called from Yves to set this properly. So multi stores in the same installation is possible, but will take a good amount of work to optimize for, which need to be considered when going this road.