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 -
Comments
-
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
0 -
that is also only partially correct
0 -
๐
0 -
it is you wording that is not accurate
0 -
maybe lost in translation
0 -
using spryker partially would make it correct ;]
0 -
no other way
<- is just not true0 -
ok
0 -
the client is meant to
<- is catastrophically incomplete0 -
if i do it other way, would that be still what spryker suggest to use ? would that be still spryker coding standard?
0 -
allows you to separate them to different domains later
<- follows an assumption, that most people (in my experience) do not start from0 -
if you have reasons to do it in a certain way, then Spryker will not stand in your way
0 -
we have good examples for really crazy adaptions
0 -
but then you also take ownership, ditch support for that bit
0 -
your base questions reads to me now like
0 -
why do we have arcihtecture?
0 -
why conventions?
0 -
why boundaries?
0 -
LOL
0 -
that's your assumption
0 -
it is an interpretation, yes
0 -
anyway I got my answer alrady and this thread gets too Offtop
0 -
dare i ask what answer you take away from this? ๐
0 -
thank you @UJN2JRU4F and @UL6DGRULR for providing your input
0 -
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."
0 -
summary: the only cost-effective approach is do it the same way, as spryker doesn't come with anything more efficient ootb
0 -
My 5 cents to this discussion, based on one of the customerโs project:
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.
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.
0
Categories
- All Categories
- 42 Getting Started & Guidelines
- 7 Getting Started in the Community
- 8 Additional Resources
- 7 Community Ideas and Feedback
- 76 Spryker News
- 929 Developer Corner
- 787 Spryker Development
- 89 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
- 26 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