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

I am new to Spryker and have a General Question: How do we decide when to use Client, Yves, Zed, Ser

Options
U03RJQT5AN4
U03RJQT5AN4 Posts: 9 🧑🏻‍🚀 - Cadet
edited September 2022 in Help

I am new to Spryker and have a General Question:
How do we decide when to use Client, Yves, Zed, Service, Shared etc. I understand Yves is used for frontend funcitonality of a module and Zed for Backoffice part. But Im not sure if this is correct understanding.
The first module we are making is a common Class which would be responsible for API logging(Request and Response). This class would extend Guzzle Cient and will be used to call APIs instead of guzzle client. We want this class to be used instead of default Guzzle Client to have some control over API calls.(Example logging the calls) Where shall we keep the Class? IMO it should be in a client. How do we decide the best approach and folder.

Comments

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

    Shared: Information that will be used in the context of Zed, Yves and Glue, especially transfer definitions and constants

    Zed: Backoffice functionality and all business logic

    Yves: No logic, only rendering of data that is retrieved from Storage (Redis), Search (Elasticsearch) or Zed (through Gateway Controllers)

    Client: Retrieve data from Storage, Search or from Zed (using the Zed Stub)

    Service: Wrapped Libraries and general functionalities that are reused in Zed, Yves and Glue

    So in your case I would either implement it in Shared or even better in Service to provide a general HTTP Client/API service that is able to log request and responses

    So for your case

  • Chemaclass
    Chemaclass Tech Lead Spryker Solution Partner Posts: 213 🧑🏻‍🚀 - Cadet
    edited September 2022
    Options

    As a rule of thumb, this might help you 🧠
    • Zed -> Pure backend stuff. It communicates to Postgress (DB) and keep syncronise the data between pgsql and redis/elasticsearch
    • Yves -> The door to the FE. It’s the shop what the customer will visit. It fetches data from elasticsearch (searching engine) and redis (key:value db). The only exception that communicates to the posgress db is during checkout proccess. It communicates to external dbs using the Client
    • Client -> it’s what Yves uses to communicates to Zed/DB (via Stubs), or redis (via Storage)
    • Service -> isolated logic that should be agnostic from Yves or Zed. It could be called from anywhere.
    • Shared -> It’s for shared classes from anywhere in the project. Usually constants that you might want to access from your Config (and config_default.php), or the definition of your transfer.xml objects (that later you can find inside the Generated folder)

  • giovanni.piemontese
    giovanni.piemontese Technical Lead @ Löffelhardt Spryker Solution Partner Posts: 871 🧑🏻‍🚀 - Cadet
    Options

    @U015S0C0V29

    The only exception that communicates to the posgress db is during checkout proccess. It communicates to external dbs using the Client
    

    What means with the only exception ?
    Yves has no possibility to communicate with db, also during checkout process.

    Yves use always Client to communicate with db.

  • Chemaclass
    Chemaclass Tech Lead Spryker Solution Partner Posts: 213 🧑🏻‍🚀 - Cadet
    Options

    Totally 💯. Probably I didn’t express myself properly. I meant, Yves uses the Client to talk to Redis and Elastic for everything. The “only exception” where it communicates to the DB (also via the Client using Stubs) is during the checkout process.

  • U03RJQT5AN4
    U03RJQT5AN4 Posts: 9 🧑🏻‍🚀 - Cadet
    Options

    Understood. Thanks for clarifying guys. I thought Client is used for communication so it would be better to keep API logging there. But services makes sense too. I would use that.

  • U03RJQT5AN4
    U03RJQT5AN4 Posts: 9 🧑🏻‍🚀 - Cadet
    edited September 2022
    Options

    Also, which lib shall we use for generating logs. Spryker docs dont mention any. Upon some RnD, I've found spryker/log(https://packagist.org/packages/spryker/log) and monolog. But im not sure if they are used at application level. Am I missing something?

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

    @UL65CH0MC Just for completeness, there is a possibility that Yves reads directly from the DB (https://docs.spryker.com/docs/scos/dev/tutorials-and-howtos/howtos/howto-replace-key-value-storage-with-database.html), at least as a replacement for the redis storage.
    This will technically enable Yves to use the DB connection for other purposes as well.

    But it's not recommended and only meant to for cases with a low number of customers, but a high amount of product/availability/price/etc. data.

  • giovanni.piemontese
    giovanni.piemontese Technical Lead @ Löffelhardt Spryker Solution Partner Posts: 871 🧑🏻‍🚀 - Cadet
    Options

    @UL6DGRULR Yes I know this exception!!! Good that u mentioned it!