can anyone point me at a doc / explain why spryker decided to use "glue -> client -> gateway -

UK5DS29L2

can anyone point me at a doc / explain why spryker decided to use "glue -> client -> gateway -> backend "
and "yves -> client -> gateway -> backend " flow? At this point it looks for me like an unnecessary overhead/bottleneck with no clear advantage over simple json backend controller response.

UMT6U55RD

https://documentation.spryker.com/glue_rest_api/glue-rest-api.htm -> even though its quite short see "why did we introduce it?" section

Alberto Reyer

I can’t point to the documentation, but I was part of the decision back then 😉

The idea behind the client layer is to share the same call among yves & glue and reduce duplicated code and do the necessary steps to convert transfer objects into json.

But why the hack do we have gateway controller?
The answer is almost the same, the steps to create transfer objects from the incomming json is always the same.
So client & gateway layer (if I should call it layer) are there to translate from/into transfer objects so we have a standardized API Interface we can program against.

What I don’t get in your question is why it looks like a bottleneck. Do you mean to have a Zed (Gateway) request for each Yves (Client) request? Normally all calls which are made independent of the current customer context (like Product Detail Pages) should only receive the content from redis.
All other requests, those who will create a request to Zed, are either context bound (e.g.: getCustomerPrice) or write requests (also context bound).

Using this schema does allow to have all data which is accessed often to be put into redis and therefore be delivered very quickly. Such data is mostly accessed very often but the update frequency is a lot lower then the access frequence (e.g.: product data will be accessed very often, but in comparison a product will not be updated this often).

UK5DS29L2

@UMT6U55RD I'm asking about the additional layer, not glue itself 😉

UK5DS29L2

@UL6DGRULR

What I don’t get in your question is why it looks like a bottleneck.

because it does another URL call within which means the server needs to respond twice with the same content under the hood

UK5DS29L2

let's say I'm asking glue (one request)
then glue is asking zed (second request same request content as above)
then zed responds to glue (first response)
then glue responds to me (second response with same content as above)

UK5DS29L2

what bothers me is that it uses URL call and not PHP class/method call

UK5DS29L2

example:

• I'm using a browser to see shopping lists so Yves controller handles that (and thats OK)
• CartToShoppingListController calls the client
• and client does another HTTP call to another controller within the same codebase (which is zed gateway controller)

I was always taught that controller calling another controller is a bad practice, but using a HTTPClient to get the data we could easily get ourselves raises my eyebrow. hence the question.

UKTSRTD5M

I would start the argument with citing https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering - as this is a layer of indirection. So it comes down to two aspects: Firstly what is the purpose of the indirection? And secondly is it suffering from "too many levels of indirection"?
To the first point i would respond it's a separation of responsibilities. Yves (and the same holds true for glue) is serving as a frontend provider to the customer, Zed is serving as a "E-Commerce Middleware". The first is mainly about presenting data to the customer. Most of which is accessible without calling zed (e.g. product data via search or redis). Zed is responsible for business processes, and loosely speaking, access to the database and external services. This decoupling introduces the possibility to either swap out or add different frontend - services. This is indeed what happened as glue was introduced. Or allowing different services accessing zed directly (without going through Yves and even the public internet in our case).
But then the question remains, is it worth the overhead of another http call? For us at least, i would answer with yes, it is. Because the more time-critical pages / calls are served from Yves directly, without accessing zed. And on the other hand the calls to take the roundtrip Yves->Zed>Yves are mostly ones which are slower and more complex anyway. Hence the overhead is not a problem most of the time. But this general principle may be violated on a case-by-case basis. For example we bypassed zed for a specific ERP-call where performance is critical and moved the related business logic into a client directly.
But in general the separation of Yves and Zed and the "rpc" - mechanism for us makes sense and is worth it.

Unknown

i think i got the misunderstanding

Unknown

what bothers me is that it uses URL call and not PHP class/method call

Unknown

this is because yves and zed would usually noit exist on the same node

Unknown

they are (for many reasons, some of which stated above) independent applications

Unknown

it is not a sub-call within one application, but an api-call to a different application through the client. the source of the requested data should usually not be relevant to the requesting application

Unknown

does that shed a little bit more light on the matter, @UK5DS29L2?

UKTSRTD5M

@UJN2JRU4F: Is there a general, more complete discussion / documentation available? Perhaps it would be worth writing it to enhance the understanding and therefore acceptance on the developer side (i saw this questions discussed several times now)?

UK5DS29L2

it WOULD if Yves and Zed were truly separate, independent applications (let's say like E-commerce system and PIM which you integrate through API) but Zed and Yves are shipped together, strongly depend on each other and are by no means separate applications. They may have separete UI, that's true, but i would never call them independent applications (because of composer.json contents).
THEN (if they were independent applications) it would make sense to implement the client class between them that's fullfilling the request-repsonse validation role that makes sure you're both sending only expected payloads (Spryker transfer objects) and getting back only expected responses (also Spryker transfer objects).
within same codebase however (because Zed and Yves can request Zed/Yves namespaces as they are both loaded by the same vendor autoloader) using slower http communication, whene there is faster, more performant way of calling the method directly, looks like a bad idea to me.

UK5DS29L2

unless that's just a small brick on paving the way to completely separate Yves and Zed which is a work in progress? (would make sense to use client between them NOW)

Unknown

the concept of maintaining both applications in a the same repo is called MonoRepo and comes with certain organisational advantages

Unknown

running yves and zed should not happen on the same node (though that is technically possible).

UK5DS29L2

oh I'm sure it does, but that's not the question here 😉

UK5DS29L2

ok, can I deploy JUST Yves code? no

Unknown

no -> mono repo

Unknown

throretically you could strip unneeded bits in your deployment pipeline

Unknown

Adapting the client, you could run yves entirely against a different backend

Unknown

even directly against the database, thus bypassing any business logic you might have in place in zed

Unknown

it breaks encapsulation

Unknown

but if you have a use case, then i would actually be happy to see a demo 🙂

UK5DS29L2

simpest usecase example:
let's say I want to fetch all products. I don't care about validation, just raw json response.
can I call Zed myself without using glue / yves ?

Unknown

yes

Unknown

a very general answer 😄