Architecture

We provide an ecosystem of independent developer tools adressing challenges that you will inevitably encounter when building an eCommerce storefront. Each of the tools we provide is focused on solving a specific category of problems. They work best together, but they are independent from each other - each can be esily replaced with a different solution.

Typical Headless Architecture

Building a great Storefront requires solving multiple domain-specific problems. These problems go far beyond the Storefront itself. For example, - Infrastructure and data layer significantly impact Storefront’s speed and reliability. We help with all of that!

Let’s see what a typical, state-of-the-art headless eCommerce architecture looks like on a high level. You will learn in a moment that our product ecosystem is a reflection of it.

Headless architecture is like an onion. It has layers. Each of them has strict responsibilities, and as long as these responsibilities are protected, they ensure flexibility and scalability of the whole system.

• Of course, the storefront is the critical element of modern eCommerce architecture. This is the only part of the system that your customers interact with directly. It has to be fast, reliable, intuitive, and look great to deliver a great User Experience to your customers.
• In headless and composable architectures, we compose our stack from multiple vendors. Each of them delivers its services through an API. Establishing all of those connections directly from the frontend often leads to performance problems and accelerated technical debt accumulation. It also makes our frontend a multi-purpose monolith which we would like to avoid when building for scalability. A separate integration layer keeps your frontend flexible and more abstracted from third-party vendors (which is essential if we want to avoid complete vendor lock-in). In addition, your frontend now has to connect to only one API that can be reused in other contexts like mobile applications or kiosks.
• Headless infrastructure is much more complex than one needed to host the monolith. Now you have multiple applications with different requirements. Each works differently, consumes different resources, and handles different traffic. To ensure that your eCommerce store works well and delivers a great user experience, all components need to work well together. One bottleneck will affect the overall performance and reliability of your system.

Alokai Architecture

Our goal is simple - make building a great storefront as easy and as fast as possible without compromising quality and flexibility. Everything we build is the reflection of this goal.

Let’s see how our products fit into the typical headless architecture. Each addresses a different category of challenges related to building a storefront.

• Storefront UI (White-label Design System) - UI development acceleration with Vue / React components and Figma design.
• SDK (Frontend integration layer) - Ensures the connection with Middleware is stable, and responses are fully typed.
• Middleware (Backend integration layer) - Connects third-party vendors and exposes a single API for the frontend.
• Unified Data Layer (Data Model) - Fully decouples your storefront from the underlying API's simplifying use cases such as migration to a new backend, updates or multi-vendor setups.
• Console and Cloud - (Cloud and monitoring platform) - Multi-region SaaS Cloud Platform for your Alokai Application with observability, monitoring, analytics and more.
• Storefront (Project Accelerator) - A ready-to-use Storefront Accelerator that is using all of the above products and is already connected to your eCommerce, CMS, Search and Payment vendors (we will talk about integrations in a moment!)

Storefront UI, SDK, Middleware, and Console are the barebones of your Alokai application. Using them ensures that you’re applying state-of-the-art architecture that will protect the scalability and flexibility of your project.

Integration Architecture

Another challenge you’ll inevitably face when going headless comes from the composable nature of this stack. Hundreds of vendors are out there, and almost countless combinations of how they can be used together.

Integrating them with your data layer is a time-consuming process. This is why we offer out-of-the-box integrations with leading MACH vendors for all our products to save you from time-consuming integration work. We integrate with eCommerce vendors, Content Management Systems, Search & Personalisation vendors, and Payment providers.

On the high level, every third-party vendor integration is similar and contains of two elements:

• Integration API Client (middleware) that is responsible for calling the external service. Each API Client integrates different third-party API into the Middleware.
• Integration SDK Module (storefront) that calls the Middleware and provides Typescript types related to specific middleware integration. Then calling an integration from the frontend is as easy as calling a function within your storefront. For example, to fetch products from BigCommerce integration, we simply write sdk.bigCommerce.getProduct()

Alokai Ecosystem

Elements of our ecosystem generally fall into three categories:

• Libraries offer easy-to-use abstractions over previously complicated elements of headless architecture. We build those for things that have established best practices allowing to abstract implementation details and focus on getting things done. A good example of such a product is API Gateway. Even though every project uses it differently the use cases can be easily covered by universal API abstraction. All of our libraries are Open Source projects under MIT license.
• Integrations with third-party vendors. As a rule of thumb every integration with a platform that has a free or low-price tier is Open Source and every integration with Enterprise-grade-only vendor is part of our Enterprise License. Here you can find available integrations.
• Storefronts using our tools and integrations that save you from generic and repetitive groundwork and provide direct access to the source code. We build those for things that can look and work completely different in different projects. In such cases, abstractions are simply too limiting. A good example of a product that should be an accelerator is a UI library. There are too many ways to customize the UI to restrict its capabilities with abstractions and extension points, allowing you to adjust only certain aspects of your components.