Support Center

Shared Packages & Workspace Architecture

The Mallnline platform is built from three frontend applications that work together to deliver the full experience. To keep these applications in sync and ensure a consistent experience, shared code is managed through workspace packages — centralized libraries that all three apps draw from.

How It Works

Mallnline's frontend consists of three standalone applications, each tailored to a specific role:

Application Who Uses It What It Does
The Storefront Visitors and Buyers Browse Malets, discover products, make Murchases
The Deck Malet Owners Manage products, Murchases, analytics, and Malet settings
The Tower Platform Admins Oversee platform health, users, search configuration, and error tracking

Many features span multiple applications — for example, both The Deck and The Storefront need to display Malet details, product listings, and Murchase data. Instead of maintaining separate copies of this shared logic, the platform uses a shared package called @ngwenya/queries.

What `@ngwenya/queries` Contains

This package centralizes the GraphQL queries and data types that all three applications use to communicate with the backend. This includes:

  • Malet queries — fetching Malet details, owned Malets, and previews
  • Murchase queries — retrieving Murchases by Malet, Murchase history
  • Organization queries — team management, membership data
  • Product/service queries — creating and managing catalog items
  • Authentication queries — login, session management
  • And 16 more domain areas

What `@mallnline/ui` Contains

This package centralizes the core visual components and design tokens ensuring that everything looks identical across the platform. This includes:

  • Interactive Elements — Buttons, Inputs, Toggles, Modals
  • Feedback & States — Spinners, Skeletons, Error Boundaries, Empty States
  • Design Tokens — The tokens.css file containing all shared Mallnline brand colors, spacing, typography, and dark mode variables

Why This Matters

When a backend feature is updated (for example, a new field is added to Malet data), the change only needs to be made once in the shared package. All three applications automatically pick up the update, ensuring:

  • Consistency — The Deck, Storefront, and Tower always show the same data in the same format
  • Faster updates — Changes propagate to all apps simultaneously
  • Fewer bugs — No risk of one app falling out of sync with the others

For Malet Owners

As a Malet Owner, this architecture means:

  • Your data is always consistent — whether you're viewing your Malet in The Deck or previewing it on the Storefront, you see the same information
  • New features arrive everywhere at once — when the platform adds new capabilities, they appear in all relevant applications simultaneously
  • Reliability — shared, tested code means fewer edge cases and inconsistencies

For Developers

The workspace is managed using pnpm workspaces. The architecture looks like this:

ngwenya/
├── pnpm-workspace.yaml          # Links all packages and apps
├── ngwenya-packages/            # Shared packages repository
│   ├── queries/                 # @ngwenya/queries (21 domain query files)
│   └── ui/                      # @mallnline/ui (core Svelte components)
├── ngwenya-front/               # Storefront (port 5173)
├── ngwenya-deck/                # The Deck (port 5171)
└── ngwenya-tower/               # The Tower (port 5170)

Each application declares the shared packages as a workspace dependency:

{
  "dependencies": {
    "@ngwenya/queries": "workspace:*",
    "@mallnline/ui": "workspace:*"
  }
}

Import shared queries and UI components via sub-path imports:

import { GET_MY_OWNED_MALETS } from '@ngwenya/queries/malet';
import { Button, Modal } from '@mallnline/ui';

NOTE

For Developers: See Shared Query Package for the full technical architecture, domain file mapping, and contribution guide.

Frequently Asked Questions

Does this affect how I use The Deck or The Storefront? No — as a Malet Owner or Visitor, you won't notice any difference in how the applications work. The shared package is an internal infrastructure improvement that happens behind the scenes.

Will new features still be released to all apps at the same time? Yes — that's one of the key benefits of this architecture. When a feature is built using shared queries, it becomes available across all three applications simultaneously.

What happens if a shared query or component needs to change? The change is made once in the @ngwenya/queries or @mallnline/ui package. All three applications are then tested to verify compatibility before the update is deployed.

Can I contribute queries or components as a developer? If you're building a feature that spans multiple Mallnline apps, add your logic to the appropriate shared package in ngwenya-packages/. Follow the domain file convention. See the Developer Portal documentation for the full UI contribution checklist.