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 -

13Β»

Comments

  • UK5DS29L2
    UK5DS29L2 Posts: 546 πŸ§‘πŸ»β€πŸš€ - Cadet
    edited September 2019

    It's clear to me now there's no other way in spryker than to use those HTTP(Client) calls because that's how spryker was designed and moving away from it means moving away from spryker

  • that is also only partially correct

  • 😜

  • it is you wording that is not accurate

  • maybe lost in translation

  • UK5DS29L2
    UK5DS29L2 Posts: 546 πŸ§‘πŸ»β€πŸš€ - Cadet

    using spryker partially would make it correct ;]

  • no other way <- is just not true

  • UK5DS29L2
    UK5DS29L2 Posts: 546 πŸ§‘πŸ»β€πŸš€ - Cadet

    ok

  • the client is meant to <- is catastrophically incomplete

  • UK5DS29L2
    UK5DS29L2 Posts: 546 πŸ§‘πŸ»β€πŸš€ - Cadet
    edited September 2019

    if i do it other way, would that be still what spryker suggest to use ? would that be still spryker coding standard?

  • allows you to separate them to different domains later <- follows an assumption, that most people (in my experience) do not start from

  • if you have reasons to do it in a certain way, then Spryker will not stand in your way

  • we have good examples for really crazy adaptions

  • but then you also take ownership, ditch support for that bit

  • your base questions reads to me now like

  • why do we have arcihtecture?

  • why conventions?

  • why boundaries?

  • UK5DS29L2
    UK5DS29L2 Posts: 546 πŸ§‘πŸ»β€πŸš€ - Cadet

    LOL

  • UK5DS29L2
    UK5DS29L2 Posts: 546 πŸ§‘πŸ»β€πŸš€ - Cadet

    that's your assumption

  • it is an interpretation, yes

  • UK5DS29L2
    UK5DS29L2 Posts: 546 πŸ§‘πŸ»β€πŸš€ - Cadet

    anyway I got my answer alrady and this thread gets too Offtop

  • dare i ask what answer you take away from this? 😊

  • UK5DS29L2
    UK5DS29L2 Posts: 546 πŸ§‘πŸ»β€πŸš€ - Cadet
    edited September 2019

    thank you @UJN2JRU4F and @UL6DGRULR for providing your input

  • UK5DS29L2
    UK5DS29L2 Posts: 546 πŸ§‘πŸ»β€πŸš€ - Cadet

    my answer is "I need to use Client-based communication to stay close to Spryker coding standards if we ever need this to be investigated and supported. It's the only reasonable way to make things as close to spryker packages as possible in case of core packages rewrite/update and further composer updates to take examples from if we need them to be compatible and keep up with spryker updates all the time."

  • UK5DS29L2
    UK5DS29L2 Posts: 546 πŸ§‘πŸ»β€πŸš€ - Cadet
    edited September 2019

    summary: the only cost-effective approach is do it the same way, as spryker doesn't come with anything more efficient ootb

  • Andriy Netseplyayev
    Andriy Netseplyayev Sprykee Posts: 519 πŸ§‘πŸ»β€πŸš€ - Cadet

    My 5 cents to this discussion, based on one of the customer’s project:

    1. We have a custom β€œbackoffice” SPA, 100% built in vue.js (a separate app/container) that is talking to Zed directly using Zed’s Rest API (the old beta). Important point here, that it is closed application, used for internal stuff only.

    2. We leveraged using Clients, when we had to switch from ElasticSearch to external PIM application, over it’s API. That step was just a matter introducing another Client. While interface stayed the same, Yves and frontend were not affected.