What are the Slack Archives?

It’s a history of our time together in the Slack Community! There’s a ton of knowledge in here, so feel free to search through the archives for a possible answer to your question.

Because this space is not active, you won’t be able to create a new post or comment here. If you have a question or want to start a discussion about something, head over to our categories and pick one to post in! You can always refer back to a post from Slack Archives if needed; just copy the link to use it as a reference..

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

UKMHZV8LX
UKMHZV8LX Posts: 69 πŸ§‘πŸ»β€πŸš€ - Cadet

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.

Comments

  • Ievgen Varava
    Ievgen Varava Sprykee Posts: 154 πŸ§‘πŸ»β€πŸš€ - Cadet

    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
    Ievgen Varava Sprykee Posts: 154 πŸ§‘πŸ»β€πŸš€ - Cadet
    edited April 2020

    what's yours approach though?

  • UKMHZV8LX
    UKMHZV8LX Posts: 69 πŸ§‘πŸ»β€πŸš€ - Cadet

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

  • Ievgen Varava
    Ievgen Varava Sprykee Posts: 154 πŸ§‘πŸ»β€πŸš€ - Cadet

    so you got a multi-repo project?

  • UKMHZV8LX
    UKMHZV8LX Posts: 69 πŸ§‘πŸ»β€πŸš€ - Cadet

    No, only one

  • Ievgen Varava
    Ievgen Varava Sprykee Posts: 154 πŸ§‘πŸ»β€πŸš€ - Cadet

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

  • UKMHZV8LX
    UKMHZV8LX Posts: 69 πŸ§‘πŸ»β€πŸš€ - Cadet

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

  • Ievgen Varava
    Ievgen Varava Sprykee Posts: 154 πŸ§‘πŸ»β€πŸš€ - Cadet

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

  • UKMHZV8LX
    UKMHZV8LX Posts: 69 πŸ§‘πŸ»β€πŸš€ - Cadet

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

  • UKMHZV8LX
    UKMHZV8LX Posts: 69 πŸ§‘πŸ»β€πŸš€ - Cadet

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

  • Ievgen Varava
    Ievgen Varava Sprykee Posts: 154 πŸ§‘πŸ»β€πŸš€ - Cadet

    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
    UKMHZV8LX Posts: 69 πŸ§‘πŸ»β€πŸš€ - Cadet

    Thanks. Any Spryker dev who is willing to comment on this? πŸ˜‰

  • Andriy Netseplyayev
    Andriy Netseplyayev Domain Lead Solution Architecture Sprykee Posts: 517 πŸ§‘πŸ»β€πŸš€ - Cadet
    edited April 2020

    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
    Andriy Netseplyayev Domain Lead Solution Architecture Sprykee Posts: 517 πŸ§‘πŸ»β€πŸš€ - Cadet

    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
    Andriy Netseplyayev Domain Lead Solution Architecture Sprykee Posts: 517 πŸ§‘πŸ»β€πŸš€ - Cadet

    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
    Andriy Netseplyayev Domain Lead Solution Architecture Sprykee Posts: 517 πŸ§‘πŸ»β€πŸš€ - Cadet

    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
    U0134CBTUKS Posts: 42 πŸ§‘πŸ»β€πŸš€ - Cadet

    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
    UKMHZV8LX Posts: 69 πŸ§‘πŸ»β€πŸš€ - Cadet
  • Andriy Netseplyayev
    Andriy Netseplyayev Domain Lead Solution Architecture Sprykee Posts: 517 πŸ§‘πŸ»β€πŸš€ - Cadet

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