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..
can anyone point me at a doc / explain why spryker decided to use "glue -> client -> gateway -
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.
Comments
-
https://documentation.spryker.com/glue_rest_api/glue-rest-api.htm -> even though its quite short see "why did we introduce it?" section
0 -
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).
0 -
@UMT6U55RD I'm asking about the additional layer, not glue itself π
0 -
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
0 -
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)0 -
what bothers me is that it uses URL call and not PHP class/method call
0 -
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.
0 -
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.0 -
i think i got the misunderstanding
0 -
what bothers me is that it uses URL call and not PHP class/method call
0 -
this is because yves and zed would usually noit exist on the same node
0 -
they are (for many reasons, some of which stated above) independent applications
0 -
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
0 -
does that shed a little bit more light on the matter, @UK5DS29L2?
0 -
@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)?
0 -
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.0 -
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)
0 -
the concept of maintaining both applications in a the same repo is called MonoRepo and comes with certain organisational advantages
0 -
running yves and zed should not happen on the same node (though that is technically possible).
0 -
oh I'm sure it does, but that's not the question here π
0 -
ok, can I deploy JUST Yves code? no
0 -
no -> mono repo
0 -
throretically you could strip unneeded bits in your deployment pipeline
0 -
Adapting the client, you could run yves entirely against a different backend
0 -
even directly against the database, thus bypassing any business logic you might have in place in zed
0 -
it breaks encapsulation
0 -
but if you have a use case, then i would actually be happy to see a demo π
0 -
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 ?0 -
yes
0 -
a very general answer π
0
Categories
- All Categories
- 42 Getting Started & Guidelines
- 7 Getting Started in the Community
- 8 Additional Resources
- 7 Community Ideas and Feedback
- 75 Spryker News
- 924 Developer Corner
- 783 Spryker Development
- 88 Spryker Dev Environment
- 362 Spryker Releases
- 3 Oryx frontend framework
- 35 Propel ORM
- 68 Community Projects
- 3 Community Ideation Board
- 30 Hackathon
- 3 PHP Bridge
- 6 Gacela Project
- 25 Job Opportunities
- 3.2K π Slack Archives
- 116 Academy
- 5 Business Users
- 370 Docker
- 551 Slack General
- 2K Help
- 75 Knowledge Sharing
- 6 Random Stuff
- 4 Code Testing
- 32 Product & Business Questions
- 70 Spryker Safari Questions
- 50 Random