Skip to content

Logistics – Blazor Microfrontend Backlog Plan

Introduction

This document defines backlog planning for a Blazor-based logistics microfrontend delivered stub-first: the UI, navigation, and service abstractions ship before a real logistics backend API exists. Stub or in-memory implementations provide representative data so designers, product, and engineering can validate flows and shell integration early.

The plan uses the same generation and styling stack as other ConnectSoft MFEs:

  • ConnectSoft.Blazor.ShellTemplate (cs-blazor-shell): Shell application that hosts microfrontends.
  • ConnectSoft.Blazor.MicrofrontendLibraryTemplate (connectsoft-blazor-mfe): Blazor WebAssembly MFE project(s).
  • ConnectSoft.Blazor.UIKit with ConnectSoft.Blazor.ComponentLibrary.Adapters.Flowbite: Shared components and Flowbite-oriented styling (see integration notes in ConnectSoft.Blazor.Mfe.AIChatTemplate).

Structure:

  • Epic: One epic LOG-MFE-001 spanning stub UI, UIKit/Flowbite, shell registration, CI, and documentation.
  • Features: Prefixed LOG-MFE-<AREA>-001 — each feature is a major milestone (few items).
  • Tasks: Prefixed LOG-MFE-<AREA>-T### — large, end-to-end work items. Each task intentionally bundles implementation, automated tests, documentation, and CI/CD (pipeline updates, quality gates, or release notes) for that slice, rather than splitting those concerns across separate backlog items.

Work items can be created in Azure DevOps Boards by copying titles and descriptions from this document. IDs are stable identifiers for traceability.

Prerequisites (stub phase)

For the initial stub phase, no logistics backend is required.

  • Shell (optional for local MFE-only development): May use a development shell with authentication stubbed or simplified.
  • Backend APIs: Out of scope for this epic until a follow-up epic wires HTTP implementations of the same service interfaces.

When the logistics API exists, a separate epic should replace stub registrations with typed HttpClient clients and align DTOs with the official service model package (to be defined).

Template and reference repositories

Shell template

ConnectSoft.Blazor.ShellTemplate

  • Repository: ConnectSoft.Blazor.ShellTemplate
  • NuGet Package: ConnectSoft.Blazor.ShellTemplate
  • Template short name: cs-blazor-shell
  • Purpose: Blazor Server shell with MFE configuration, navigation, and UIKit integration. Use --uiKitAdapter Flowbite for parity with the MFE.

Microfrontend template

ConnectSoft.Blazor.MicrofrontendLibraryTemplate

  • Repository: ConnectSoft.Blazor.MicrofrontendLibraryTemplate
  • NuGet Package: ConnectSoft.Blazor.MicrofrontendLibrary
  • Template short name: connectsoft-blazor-mfe
  • Purpose: Blazor WebAssembly MFE with optional UIKit adapter parameter (Flowbite recommended).

Reference implementations

Repository Use for
ConnectSoft.Blazor.Mfe.Identity.AdminTemplate Admin-style pages, CRUD-style layouts, code-behind structure, in-memory service patterns
ConnectSoft.Blazor.Mfe.Identity.SelfServiceTemplate Lighter self-service flows and navigation
ConnectSoft.Blazor.Mfe.AIChatTemplate Flowbite adapter CSS/JS, initFlowbite, and WASM host script ordering (docs/integration.md)
ConnectSoft.Blazor.Mfe.AuthorizationServer.AdminTemplate Large epic-style planning, API settings types, HTTP client layout for future real backend

UI packages

  • ConnectSoft.Blazor.UIKit — component library.
  • ConnectSoft.Blazor.ComponentLibrary.Adapters.Flowbite — Flowbite adapter styles and scripts.

Logistics screens use Flowbite-oriented layouts (sidebar, tables, cards, modals) composed from UIKit; there is no separate “logistics-only” Flowbite template—patterns match existing admin MFEs.

Template installation

dotnet new install ConnectSoft.Blazor.ShellTemplate
dotnet new install ConnectSoft.Blazor.MicrofrontendLibrary
dotnet new list ConnectSoft.Blazor

Stub architecture

  • Define interfaces for logistics operations (queries and commands) and DTOs in a dedicated area (e.g. Models, Contracts, or Services/Abstractions).
  • Implement stub or in-memory services returning seed data (pattern similar to InMemoryUserStore / service layers in Identity.AdminTemplate).
  • Configuration flag UseStubLogisticsApi (or equivalent) selects stub implementations in DI; future work registers HTTP clients instead without changing Razor pages.
  • Optionally define LogisticsApiSettings and named HttpClient registration with no live calls in the stub phase, documenting the future boundary (as in AuthorizationServer.AdminTemplate planning).
flowchart TB
  subgraph shell [BlazorShell]
    Nav[Navigation_and_auth]
  end
  subgraph mfe [Logistics_MFE_WASM]
    Pages[Admin_and_SelfService_pages]
    UI[UIKit_Flowbite]
    Stub[StubLogisticsServices]
    Future[HttpLogisticsClient_future]
  end
  shell --> mfe
  Pages --> UI
  Pages --> Stub
  Stub -.-> Future
  Future -.-> API[Logistics_API_future]
Hold "Alt" / "Option" to enable pan & zoom

Suggested repository layout

Phase 1 (recommended): One repository, e.g. ConnectSoft.Blazor.Mfe.Logistics.Template, containing:

  • Admin route group (/logistics/admin/...)
  • Self-service route group (/logistics/self/...)

Split into separate repos (Admin vs Self-Service) only if deployment or team boundaries require it.

Azure DevOps epic and features

Tasks below are end-to-end: each one is closed only when code, automated tests, documentation, and CI/CD for that slice are done (pipeline updated if needed, README or internal docs updated, quality gates satisfied). No separate backlog rows for “just CI” or “just docs”—those roll into the same task.

Epic: LOG-MFE-001 – Logistics Blazor microfrontend (stub-first, Flowbite/UIKit)

Description: Deliver a logistics Blazor WebAssembly microfrontend with ConnectSoft.Blazor.UIKit and Flowbite adapter, stubbed logistics services, representative admin and self-service pages, shell registration, and documentation. No production logistics API integration in this epic.

Acceptance criteria:

  • MFE builds and runs standalone and loads from the shell when configured.
  • All primary pages read data through stub services controlled by configuration.
  • UIKit + Flowbite assets load correctly; interactive Flowbite behaviors work after Blazor navigation (re-init where required).
  • Automated tests and CI prove regressions are caught; documentation matches what ships.
  • Backlog IDs (LOG-MFE-*) are reflected in Azure DevOps as one epic and child features/tasks.

Feature: LOG-MFE-FOUND-001 – Foundation: template, UIKit/Flowbite, stubs, and first pipeline

Description: One milestone that establishes the repository, full UIKit + Flowbite integration (per ConnectSoft.Blazor.Mfe.AIChatTemplate docs/integration.md), logistics contracts and stub services with UseStubLogisticsApi, optional LogisticsApiSettings placeholder for a future HttpClient, repository hygiene, README, and a working CI pipeline (restore / build / test with org quality gates).

Acceptance criteria:

  • Solution builds; tests run locally and in CI; PR validation is meaningful.
  • Flowbite CSS/JS and initFlowbite behavior validated on navigation.
  • Stubs and DI are in place for downstream admin/self-service work.

Tasks:

  1. LOG-MFE-FOUND-T001 – End-to-end foundation delivery
    • Implementation: Generate solution from connectsoft-blazor-mfe with Flowbite UIKit adapter; add ConnectSoft.Blazor.UIKit and ConnectSoft.Blazor.ComponentLibrary.Adapters.Flowbite; wire static assets, Flowbite JS (CDN or approved bundle), lifecycle hooks for interactive components; add shared admin layout shell; define DTOs, query/command interfaces, stub implementations, configuration flag, optional API settings types; .editorconfig / .gitignore / LICENSE per org.
    • Tests: Unit tests for stub services (seed data consistency); smoke coverage appropriate for foundation (e.g. key services or routing).
    • Documentation: README with local run, stub mode, template names/NuGet IDs, and a short embedded LOG-MFE scope summary; optional repo docs/ section for Flowbite notes.
    • CI/CD: Azure Pipelines (or default) YAML: restore, build, test, fail on test failure; treat warnings/nullable per team policy; document versioning in README.
    • ✅ Done when: Green pipeline on main/PR; reviewer can clone, run tests, and run the WASM app with Flowbite + stubs working.

Feature: LOG-MFE-ADMIN-001 – Admin logistics experience (stub-bound)

Description: Deliver the full admin vertical slice: routes under e.g. /logistics/admin, dashboard, shipments list/detail, inventory/locations, exceptions/alerts, empty/loading states—all bound to stub services using Identity.AdminTemplate-style structure (pages, code-behind).

Acceptance criteria:

  • All admin areas navigable; no direct HTTP calls to a real logistics API.
  • UI uses UIKit/Flowbite patterns (tables, cards, filters as needed).

Tasks:

  1. LOG-MFE-ADMIN-T001 – End-to-end admin vertical slice
    • Implementation: Routing, navigation, and all admin pages listed above; integrate existing stub queries; responsive layout for desktop-first admin.
    • Tests: Automated tests for view models or services used by admin pages; optional bUnit/component tests where high value.
    • Documentation: README section “Admin routes” and any demo data notes; keep README self-contained if routes or stub data change.
    • CI/CD: Extend pipeline if new test projects or analyzers apply; ensure admin code paths remain covered by dotnet test.
    • ✅ Done when: Demo-ready admin flow; CI green; docs describe how to exercise admin in stub mode.

Feature: LOG-MFE-SELF-001 – Self-service / operator experience (stub-bound)

Description: Deliver the self-service vertical slice: routes under e.g. /logistics/self, distinct layout if needed, my tasks, scan/receive placeholder, status lookup, basic responsive pass—patterns from Identity.SelfServiceTemplate.

Acceptance criteria:

  • Clear separation from admin chrome; all data from stubs.

Tasks:

  1. LOG-MFE-SELF-T001 – End-to-end self-service vertical slice
    • Implementation: Self-service routing and pages; stub-backed flows; document scan/receive as future hardware work.
    • Tests: Unit or component tests for self-service services and critical UI logic.
    • Documentation: README “Self-service routes”; note mobile/responsive expectations.
    • CI/CD: Pipeline continues to run full test suite; add coverage for new tests.
    • ✅ Done when: Operator demo path works end-to-end; CI green; docs updated.

Feature: LOG-MFE-INTG-001 – Shell integration and release readiness

Description: Integrate the MFE with ConnectSoft.Blazor.ShellTemplate: MicroFrontends configuration, navigation entries, auth handoff documentation, integration smoke, optional Dockerfile / publish artifact for WASM hosting, and follow-up epic outline for real APIs (LOG-MFE-API-001 or equivalent).

Acceptance criteria:

  • Shell loads logistics MFE in dev/staging; operators can follow a documented path from shell to admin/self-service entry points.

Tasks:

  1. LOG-MFE-INTG-T001 – End-to-end shell integration and release
    • Implementation: Register MFE URL and routes in shell appsettings; add shell menu links; align with shell auth (stub or real as available); optional container/static hosting artifact if required by platform.
    • Tests: Automated integration tests only if the repo supports them; otherwise documented smoke checklist checked in PR template or runbook, with evidence in PR description.
    • Documentation: Shell configuration snippet, environment variables, auth/token expectations for future API; in-repo README (and optional docs/) with product context (logistics MFE: admin + light self-service, stub-first until API epic); “Next epic” section for HTTP clients and service model package—self-contained in the repository, no external doc links required.
    • CI/CD: Pipeline stages for publish/container if adopted; version tags or release branch process documented.
    • ✅ Done when: Documented shell→MFE journey works; release path clear; follow-up API epic described for product planning.

Development workflow summary

  1. Execute features in order: FOUND → ADMIN → SELF → INTG (each closes an end-to-end increment).
  2. Within each task, finish code, tests, docs, and CI before marking the work item Done.
  3. After LOG-MFE-INTG, plan LOG-MFE-API-001 (or similar) for real backend integration.

Deployment notes

  • WASM MFE is deployed independently (static hosting or container) per org standards.
  • Shell remains Blazor Server (or current standard) and references published MFE endpoints.
  • Environment-specific appsettings holds MFE base URLs.

Summary table (Azure Boards)

Type ID Title
Epic LOG-MFE-001 Logistics Blazor microfrontend (stub-first, Flowbite/UIKit)
Feature LOG-MFE-FOUND-001 Foundation: template, UIKit/Flowbite, stubs, first pipeline
Task LOG-MFE-FOUND-T001 End-to-end foundation (impl, tests, docs, CI/CD)
Feature LOG-MFE-ADMIN-001 Admin logistics experience (stub-bound)
Task LOG-MFE-ADMIN-T001 End-to-end admin vertical slice (impl, tests, docs, CI/CD)
Feature LOG-MFE-SELF-001 Self-service / operator experience (stub-bound)
Task LOG-MFE-SELF-T001 End-to-end self-service vertical slice (impl, tests, docs, CI/CD)
Feature LOG-MFE-INTG-001 Shell integration and release readiness
Task LOG-MFE-INTG-T001 End-to-end shell integration and release (impl, tests/smoke, docs, CI/CD)

Create the epic first in Azure DevOps, then four features as children, then one primary task per feature (four tasks total). Each task title should retain the LOG-MFE- prefix. Work is not complete until implementation, tests, documentation, and applicable pipeline updates for that slice are finished.