projectmycelium/docs/dev/design/archive/APP_WORKFLOW_COMPLETE_GUIDE.md

🚀 Complete App Workflow Guide: End-to-End Implementation

📋 Overview

This guide documents the complete end-to-end workflow for app creation, marketplace listing, purchase, and deployment tracking in the Project Mycelium. This pattern can be replicated for service-provider workflows and node slice rentals.

🎯 Complete Workflow: App Provider → Customer

Step 1: App Creation (Provider Side)

• User: App Provider (e.g., user1@example.com)
• Action: /dashboard/app-provider → Create new app
• Backend: add_app_api → UserPersistence::add_user_app
• Data: App saved to provider's apps array in JSON
• Marketplace: create_marketplace_product_from_app → MockDataService::add_product

Step 2: Marketplace Visibility

• User: Any user
• Action: /marketplace/applications
• Backend: applications_page aggregates apps from all users
• Data Source: Scans all user_data/*.json files → apps arrays
• Result: Provider's app visible to all users

Step 3: App Purchase (Customer Side)

• User: Customer (e.g., user4@example.com)
• Action: Marketplace → Add to cart → Checkout
• Backend: OrderService::checkout → create_app_deployments_from_order
• Result: Deployment records created for both provider and customer

Step 4: Deployment Tracking

• Provider Side: Deployment added to provider's app_deployments with customer info + revenue
• Customer Side: Deployment added to customer's app_deployments with app info
• Cross-Reference: Same deployment ID links both perspectives

Step 5: Dashboard Display

• Provider Dashboard: Shows published apps + customer deployments
• Customer Dashboard: Shows purchased apps (derived from deployments)

🏗️ Data Architecture

Provider Data Structure

// user1_at_example_com.json (App Provider)
{
  "apps": [
    {
      "id": "app_001",
      "name": "My App",
      "status": "Active"
    }
  ],
  "app_deployments": [
    {
      "id": "dep-001",
      "app_id": "app_001",
      "customer_email": "user4@example.com",  // Customer who purchased
      "monthly_revenue": 120  // Provider earns revenue
    }
  ]
}

Customer Data Structure

// user4_at_example_com.json (Customer)
{
  "apps": [],  // Empty - customer didn't publish any apps
  "app_deployments": [
    {
      "id": "dep-001",  // Same deployment ID
      "app_id": "app_001",
      "customer_email": "user4@example.com",  // Self-reference
      "monthly_revenue": 0  // Customer doesn't earn from purchase
    }
  ]
}

🔧 Critical Implementation Details

1. Data Separation Logic

User Dashboard (/dashboard/user)

/// Shows purchased apps - derived from deployments where user is customer
pub fn get_user_applications(&self, user_email: &str) -> Vec<PublishedApp> {
    persistent_data.app_deployments
        .filter(|d| d.status == "Active" && d.customer_email == user_email)
        .map(|deployment| /* convert to app view */)
}

App Provider Dashboard (/dashboard/app-provider)

/// Shows published apps - from apps array
let fresh_apps = UserPersistence::get_user_apps(&user_email);

/// Shows deployments of published apps only
let user_published_app_ids: HashSet<String> = fresh_apps.iter()
    .map(|app| app.id.clone())
    .collect();

let filtered_deployments = fresh_deployments.iter()
    .filter(|d| user_published_app_ids.contains(&d.app_id))

2. Role-Based Display

App Provider Perspective

• /dashboard/app-provider:
  • "My Published Apps" → From apps array
  • "Active Deployments" → From app_deployments filtered by published apps
• /dashboard/user:
  • "My Applications" → Empty (provider didn't purchase apps)

Customer Perspective

• /dashboard/user:
  • "My Applications" → From app_deployments where customer_email matches
• /dashboard/app-provider:
  • Empty sections (customer didn't publish apps)

3. Cross-User Deployment Counting

/// Count deployments across all users for app provider stats
fn count_cross_user_deployments(app_provider_email: &str) -> HashMap<String, i32> {
    // Scan all user_data/*.json files
    // Count deployments of this provider's apps
    // Update provider's app.deployments count
}

🎨 Frontend Implementation

User Dashboard JavaScript

// Populate purchased applications table
populateApplicationsTable() {
    const applications = this.userData.applications || [];  // From get_user_applications()
    // Display apps user purchased
}

App Provider Dashboard

// Shows published apps and their deployments
// Data comes from app_provider_data_api with proper filtering

🔄 Order Processing Flow

Purchase → Deployment Creation

// In OrderService::create_app_deployments_from_order()
for item in order.items {
    if item.product_category == "application" {
        // Find app provider
        let app_provider_email = find_app_provider(&item.product_id);
        
        // Create deployment record
        let deployment = AppDeployment::builder()
            .app_id(&item.product_id)
            .customer_email(&customer_email)
            .build();
        
        // Add to provider's data (for tracking)
        UserPersistence::add_user_app_deployment(&app_provider_email, deployment.clone());
        
        // Add to customer's data (for user dashboard)
        UserPersistence::add_user_app_deployment(&customer_email, deployment);
    }
}

🎯 Replication Pattern for Other Workflows

Service Provider Workflow

1. Creation: Service provider creates service → services array
2. Marketplace: Service appears in /marketplace/services
3. Purchase: Customer books service → service_requests array
4. Tracking: Provider sees requests, customer sees bookings

Node Slice Workflow

1. Creation: Farmer creates slice → slice_products array
2. Marketplace: Slice appears in /marketplace/compute
3. Rental: Customer rents slice → active_product_rentals array
4. Tracking: Farmer sees rentals, customer sees active resources

📊 Key Success Factors

1. Proper Data Separation

• Publishers see their published items + customer usage
• Customers see their purchased items only
• No role confusion or data duplication

2. Cross-User Tracking

• Same deployment/booking ID in both users' files
• Different perspectives (provider vs customer)
• Proper revenue attribution

3. Role-Based Filtering

• User dashboard: Filter by customer_email == current_user
• Provider dashboard: Filter by published_items.contains(item_id)

4. Real-Time Updates

• Marketplace immediately shows new items
• Purchase creates records for both parties
• Dashboards reflect current state

🏆 Production Readiness

This pattern provides:

• ✅ Complete multi-user workflows
• ✅ Real data persistence
• ✅ Proper role separation
• ✅ Cross-user tracking
• ✅ Revenue attribution
• ✅ Integration-ready architecture

The same pattern can be applied to any producer/consumer workflow in the marketplace, ensuring consistent behavior across all product types.