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

Hello, assuming having a Client on Client layer with several methods … how to “reuse” this client on

Options
UPWG9AYH2
UPWG9AYH2 Posts: 509 🧑🏻‍🚀 - Cadet
edited August 2021 in Help

Hello,
assuming having a Client on Client layer with several methods … how to “reuse” this client on both Zed and Yves layer when they behave the same but just differ in few configuration stuff?
For example an Oauth token client for an external auth provider generally behave the same for spryker frontend but also for spryker backend … they just have a different redirect URI for example … so it depends “who” is using the client
I would prefer on yves to get a “frontend oauth client” and on backend some “backend oauth client” holding already the correct configs for the both use cases … but doing this means copy things to two different modules, or doesn’t it?

For me, i dont see a neat solution to have two clients which just differ in few config stuff …
• its not possible to add another client in the same client module -> getLocator()->module()->client() will always resolve as only one client
• having two modules mean copying all the stuff and just change the few params
• adding a “context” to every client method (to decide for a appropriate config) is not really a neat solution to me^^
• also adding a duplicate client method like doFrontendStuff() and doBackendStuff seems not really a good solution to me^^
Do i miss something? 🤔 Cant resolve this thing at the moment but it might be that i overlook something important …

Comments

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

    Client is meant to be used on Yves/Glue side, for Zed you should use the appropriate facade.

  • UPWG9AYH2
    UPWG9AYH2 Posts: 509 🧑🏻‍🚀 - Cadet
    Options

    Is that really true?🤔 That would mean something like a client that is fetching prices for the yves frontend from an erp has to build up its complete logic again in backend in facades even if the client do something similar? Honestly, it does not sound practicable to me …

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

    I wouldn’t build a client which is accessing an ERP, but rather build a component in Zed, which provides a gateway controller and is than accessed by the related client. This way the logic accessing the ERP and transforming the data is only on Zed side.

    There are two reasons for this:

    1. Logic should only be on Zed side
    2. Yves (and therefore the client) can be put on a server which is in a DMZ while Zed is running on a server which has a higher security level
  • UPWG9AYH2
    UPWG9AYH2 Posts: 509 🧑🏻‍🚀 - Cadet
    Options

    There are several places, Zed is accessing stuff via clients … sessionclient, storageclient etc.

  • UPWG9AYH2
    UPWG9AYH2 Posts: 509 🧑🏻‍🚀 - Cadet
    edited August 2021
    Options

    Client is meant to be used on Yves/Glue side, for Zed you should use the appropriate facade.

    Okay, then lets imagine i want to have slightly different behaviour between glue usage of the client and yves usage of the client … same problem to me🤔

  • UPWG9AYH2
    UPWG9AYH2 Posts: 509 🧑🏻‍🚀 - Cadet
    Options

    I mean, it must be possible to adapt behaviour somehow without copying the most stuff

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

    There are several places, Zed is accessing stuff via clients … sessionclient, storageclient etc.

    In the official Spryker resources? Then the separation has changed, but this might be the case as my opinion on what to put where is almost 7 years old 😉
    And the statement above is only a personal opinion, as I’m not yet an official Spryker member.

    different behaviour between glue usage of the client and yves usage of the client

    Then the client provides data which is enriched in Glue or Yves, depending on the case. If I understood it right, there is a different config value which should be used depending if Yves or Glue is the calling application.
    So I would return the Yves url by default and overwrite it in Glue by the according config value (could also be the other way around, this is to your preference).
    Your question was about Yves & Zed, so you could adapt it as well (Zed Facade returns the Zed redirect url, on Yves side it’s overwritten with the Yves redirect url).

  • UPWG9AYH2
    UPWG9AYH2 Posts: 509 🧑🏻‍🚀 - Cadet
    Options

    So I would return the Yves url by default and overwrite it in Glue by the according config value (could also be the other way around, this is to your preference).

    But thats the problem … how to tell the client who is actually calling it and choose the appropriate config? 🤔

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

    Don’t do it in the client, but in the component calling the client. Those component will be in the Glue/Yves/Zed namespace/application and therefore only has access to the config of this application.

  • UPWG9AYH2
    UPWG9AYH2 Posts: 509 🧑🏻‍🚀 - Cadet
    Options

    Sorry, i dont really get it^^ in the component that is using the client, usually there is a dependency that do something like. …getLocator()->myModule()->client() … cant be configured here (?)

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

    Let’s assume we speak about an Glue Controller which in the end returns the response including the redirect url.
    There are several layers in between the controller and the client, sometimes called response builder or reader, one of these will get the client injected and call a method on the client. This one would be the right place to replace the redirect url by the redirect url value from the Glue config.

    Glue/Yves:

    • Controller
      |-- Reader <- inject module config & replace url
      |---- Client <- will only return a default value, contains no logic
  • UPWG9AYH2
    UPWG9AYH2 Posts: 509 🧑🏻‍🚀 - Cadet
    edited August 2021
    Options

    Thanks for you insights … honestly, i am totally confused about everything regardings the client roles and it feels like programming everything for nothing and doing it completely wrong again …
    i mean, looking at this
    https://github.com/spryker-eco/oauth-azure/blob/master/src/SprykerEco/Zed/OauthAzure/OauthAzureDependencyProvider.php
    Zed module but session client as dependency … finding something like this suggest me, clients are also intended to be used in backend … for me it would also make sense in kind of the definition of a client … more or less “the portal” to everything outside spryker or a common piece of code to use on different places …

  • UPWG9AYH2
    UPWG9AYH2 Posts: 509 🧑🏻‍🚀 - Cadet
    edited August 2021
    Options

    Maybe i tend to always find the bad examples …