Calling Developers!
We are reenergizing our code contribution process! Learn More

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..

Anyone want a quick discussion about project code structure? My team have built a few custom module

Options
U02P7B6K2LC
U02P7B6K2LC Posts: 121 🧑🏻‍🚀 - Cadet
edited October 2022 in Slack General

Anyone want a quick discussion about project code structure?

My team have built a few custom modules now… most start with a Glue Api endpoint… then access the Client layer… then ZED… then persistence etc…

The code is organised like this:

Pyz/
-Client
--Module
-Glue
--Module
-Shared
--Module
-Zed
--Module

So module code is split between the layers.

However… in the Spryker core… modules are organised like this:

Spryker
-Module
--Client
--Shared
--Yves
--ZED

So that all the module code is in one place… and the layers are under one roof.

We like this…! 😁

So for discussion:

• Is there any way to build our custom module in the client namespace in this fashion?
• How are your teams organising code?
• How are you sharing code between projects?
• What git strategy are you using in your team?

Comments

  • Alberto Reyer
    Alberto Reyer Lead Spryker Solution Architect / Technical Director Posts: 690 🪐 - Explorer
    Options

    The slightly different package structure of the core modules is to distribute them per module, including almost all code.
    Most modern modules only include the Zed, Shared and Client code. The Yves code is part of a module in the SprykerShop namespace and Glue code has an extra module suffixed with RestApi.

    So as long as you don't want to distribute your modules individual better stick to the structure in the project code, as this will show the clear borders and help you to avoid using Zed code in Yves/Glue and vise versa.
    If you want to distribute them individual, you could create a new namespace where you use the modularized structure as shown in the core and add this to your core namespaces (in config/Shared/config_default.php):

    $config[KernelConstants::CORE_NAMESPACES] = [
        '<YourNewNamespace>',
        'SprykerShop',
        'SprykerEco',
        'Spryker',
        'SprykerSdk',
    ];
    
  • UK7KBE2JW
    UK7KBE2JW Posts: 463 🧑🏻‍🚀 - Cadet
    Options

    And additionally you have to configure your structure also on pyz for twig, db, routing, etc.

  • fsmeier
    fsmeier Senior Software Engineer & Developer Enablement Advocate Sprykee Posts: 1,029 ⚖️ - Guardians (admin)
    Options

    I overlook sth or you made a wrong example of core code structure:

    spryker/core-module
    src
    -Spryker (equivalent to the Pyz folder in your project)
    --Client
    ----CoreModule
    --Shared
    ----CoreModule
    --Yves
    ----CoreModule
    --Zed
    ----CoreModule

  • U02P7B6K2LC
    U02P7B6K2LC Posts: 121 🧑🏻‍🚀 - Cadet
    edited October 2022
    Options

    Yes you’re right Florian. I didn’t see it that way. So in fact the code structure is the same in project and core.

    The reason for this line of thinking is the amount of modules in the project side. The B2c demo shop for instance has a long list of modules in each application directory and navigating the code specifically for the custom module becomes more difficult.

    It’s not a huge problem! 😁

    But just something we’re looking at simplifying internally.

    Also, we’re looking for ways of sharing our custom modules across projects and having version control for development and testing… for this we’re looking at composer to help facilitate this.

  • You can always create your own vendor modules, just as we have for eco, sdk, middleware etc.