Hey, I have a code design question. As per this article

UKMHZV8LX

Hey, I have a code design question. As per this article
https://documentation.spryker.com/docs/ht-extend-inuse-core

Bridges are for core-level only. If you use them at the project-level, you are doing it wrong!

Is this a general rule, that should be respected in any case? We use them at project-level and it really helps in some situations.

Ievgen Varava

the idea behind bridges in core is to remove direct dependencies of modules on each other. AFAIK projects does not have this issue so there is no practical use of bridge modules there

Ievgen Varava

what's yours approach though?

UKMHZV8LX

We use bridges to decouple modules in project-level the same way as on core-level.

Ievgen Varava

so you got a multi-repo project?

UKMHZV8LX

No, only one

Ievgen Varava

then it sounds like an overhead to me. What do you achieve with such decoupling within same codebase?

UKMHZV8LX

The same as with vendors: Modules can be removed or changed with a minimum of pain regarding depending modules.

Ievgen Varava

so you create bridge module for each custom module you add into project?

UKMHZV8LX

No, only for modules, that need functionalities of another module. So basically we end up with only a few bridges in the end.

UKMHZV8LX

So as I understand it is deemed unnecessary overhead, however not a design fail?

Ievgen Varava

for your own code there are no strict restrictions, you can have as much abstractions as needed. The article suggests direct usage of facade methods when core functionality is overridden

UKMHZV8LX

Thanks. Any Spryker dev who is willing to comment on this? 😉

Andriy Netseplyayev

Ievgen is one of us 😉
Having “Bridges” on project level and enjoying them - is a sign of over-engineering. Same as introducing interfaces for every class. How often on your project (really) are you expecting to change Products/categories/put_your_module_here with something else?

Andriy Netseplyayev

in Spryker core the goal is to keep everything decoupled and flexible because we have hundreds of different customers with their unexpected needs, but on a single concrete project the goal is usually the opposite - you take what you need and couple it together.

Andriy Netseplyayev

On practice, you need to evaluate the following: extra-complexity which is coming with Bridges and additional abstraction layers - hits code readability, debugability and clearness. Which means more error-prone code with more time spent once you need to change it. As an advantage, you can replace one implementation of a module (in theory) with another one..

Andriy Netseplyayev

my experience and practice show me, that the best approach is to keep it simple and as much readable as possible continuously refactoring the code once needed vs. introducing extra layers of abstractions.

U0134CBTUKS

Similar question. What about the -connector modules which we can find in spryker vendor? Should we use same structure in our codebase or is it an overhead also?

UKMHZV8LX

Thanks @UKJSE6T47 @ULSLLNL7K

Andriy Netseplyayev

@U0134CBTUKS similar to the bridges, you don’t need to introduce connectors on the project