Alokai (previously Vue Storefront) reposted this
Co-founder & CTO @ Alokai | Modernizing eCommerce frontend-first, without risk | MACH Tech Council Member | Forbes 30 under 30 | YC Alumni (W21)
You won't have a successful composable project without a separate integration/orchestration layer. One of the selling points of composable commerce is longevity. The promise is that you'll be able to quickly experiment with new technologies, iterate on new ideas, replace the current vendors with new ones, and remain flexible even after many iterations of changes. Monoliths failed to deliver that promise because they mixed all the domains and integration code within one system. This approach accumulates technical debt quite fast to the point when developing anything takes more time than it's worth. Without a separate integration layer, you will always be doing this. The glue code will be spread across different parts of the system, especially the frontend, which will slowly become slow and hard to maintain. A separate layer responsible for managing connections between systems in a structured way ensures that separation of concerns is protected and that systems can scale independently without coupling. This is why all Alokai (previously Vue Storefront) projects come out of the box with an orchestration layer called Alokai Connect. We never offer Storefronts separately because we simply do not believe that this will be beneficial for our customers. Alokai Connect not only separates the integration logic but also unifies the data models of underlying vendors and abstracts it for the frontend so the underlying changes in contracts won't affect it. This is becoming a common practice these days as frontend is usually the part that is mostly impacted by such changes. Do you think a true composable setup can live without a separate integration/orchestration layer? Tim Benniks Toke Lund Sana Remekie Jim Herbert Dom Selvon Markus Lorenz #headless #composable #ecommerce #mach
Mateusz Ostafil
1mo
It reminds me of an old quote from the Clean Code: “In fact, wrapping third-party APIs is a best practice. When you wrap a third-party API, you minimize your dependencies upon it.” The integration layer for me is like the aforementioned wrapping but on a bigger scale because: - you don't have to wrap each dependency individually; - you get a common interface to each service; - you also wrap the interactions between the services (~ orchestration)
Markus Lorenz
1mo
💯 Filip Managing and unifying data in a decentralized application becomes increasingly challenging as the number of services grows. Each service operates independently with its own data structures, making it difficult to ensure data consistency and accuracy. I talked with Tim over it and the integration layer is crucial to avoid the traps of the picture.
Director Innovation & Digital - Retail | eCommerce -Solving problems in digital commerce modernization projects. Talks COMPOSABLE Commerce, AI & MACH Architecture (Microservices-based, API-first, Cloud-native, Headless)
1moComposable shouldn't try for Unified data repo instead an open data environment which allow each service to access data and model to its specific use is better for the flexibility of the system architecture, and Integration Layer helps this cause, if the retail/eCom industry or MACH alliance can come up with data/API standarads it would be an added bonus like the fintech industry has