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 always assumed that client layer can only be accessed from frontend (yves, glue). Documentation sa

U040UTFTKS6
U040UTFTKS6 Posts: 5 🧑🏻‍🚀 - Cadet
in Slack General

I always assumed that client layer can only be accessed from frontend (yves, glue).
Documentation says: "The client’s job is to connect the frontend application to all of the surrounding resources needed for the frontend application to work. These resources include the Commerce OS, Storage, and Search."
This meant for me that it is not allowed to access the client layer from zed.
But on the other hand, zed must somehow be able to synchronize the data with storage and ES. Indeed you can find the using of clients (storage, search) in the zed Synchronization module.

Is that the architecture break?

Why I ask is, I need storage in zed and I don't know if it's ok to use the storageClient in zed...

Any Ideas?

Comments

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

    of course Zed use client to sync storage and search data...
    also for session etc...

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

    can u please post also the documentation link where it is written? thank u

  • U040UTFTKS6
    U040UTFTKS6 Posts: 5 🧑🏻‍🚀 - Cadet

    https://docs.spryker.com/docs/scos/dev/back-end-development/client/client.html#general-information

  • fsmeier
    fsmeier Senior Software Engineer & Developer Enablement Advocate Sprykee Posts: 1,071 ⚖️ - Guardians (admin)

    Zed can also use the client - however: be careful since a lot of client code is dependent on the session client and fetches the “customer” from it. This you can not use for your Zed Application Layer then.

  • U040UTFTKS6
    U040UTFTKS6 Posts: 5 🧑🏻‍🚀 - Cadet

    I see, but what about Services. May I use the client layer from services? So e.g. I want to use storageClient in my service.
    Is it allowed from architecture point of view?

  • fsmeier
    fsmeier Senior Software Engineer & Developer Enablement Advocate Sprykee Posts: 1,071 ⚖️ - Guardians (admin)
    edited November 2022

    ~I would say yes~, but let me double check

  • fsmeier
    fsmeier Senior Software Engineer & Developer Enablement Advocate Sprykee Posts: 1,071 ⚖️ - Guardians (admin)

    So Service has no access to Clients

  • U040UTFTKS6
    U040UTFTKS6 Posts: 5 🧑🏻‍🚀 - Cadet

    thank you for clarification!

  • U0208K3V15W
    U0208K3V15W Posts: 33 🧑🏻‍🚀 - Cadet

    Interesting topic. Some client also cannot use in Yves as well (QueueClient only use able in Zed for example).
    In my opinion if any shared code can reuse in both Zed and Yves we should move to service! What do you think @florian.scholz

  • fsmeier
    fsmeier Senior Software Engineer & Developer Enablement Advocate Sprykee Posts: 1,071 ⚖️ - Guardians (admin)

    @U0208K3V15W I would not directly agree with this statement. Service should be used for more state independent things. So more util things like date-formatting etc. It has no access to data sources itself but needs the data passed as argument. If it is about connecting to another “service” like queue or PIM then i would use the client.

  • U040UTFTKS6
    U040UTFTKS6 Posts: 5 🧑🏻‍🚀 - Cadet

    @florian.scholz
    regarding usage of client layer in zed:

    Honestly,

    I don't think the connection "zed writes to the storage" / "yves reads from storage" is convincing.

    At least teoreticaly not.

    In this context, Spryker is talking about separation of data and separation of applications, which in turn means scalability, for example. But this separation is not strictly enforced in this case.(imo)

    In order to remain strict in this architecture, sync queues should not be consumed by zed but by yves. (e.g.) (imo)
    In this case we would have only one intermediator between yves and zed. That is the Message Broker (RabbitMQ)

    Then we would first have the situation that yves has storage and search resources that zed does not need to know anything about.
    Just as it is solved in the other direction with the DB: Yves knows nothing about the DB and casually uses zed-application.

    Only then can we talk about a strict separation here, which actually allows us to operate yves and zed on two separate independent instances where the DB would only be known for zed and storage/search only for e.g. yves.

    Why I go into depth is this thought:
    Only this strict separation of layers would actually allow the client layer to be used only for yves -> (storage/search/zed) and not as it is now:

    Actually currently (imo) the client layer pretends to be used exclusively by yves/glue, but somehow also a bit by zed 🙂

Categories