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

UPWG9AYH2

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 …

Alberto Reyer

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

UPWG9AYH2

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

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

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

UPWG9AYH2

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

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

Alberto Reyer

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

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

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

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

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

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

Maybe i tend to always find the bad examples …