User Request Component

The User Request component simulates HTTP requests to your system design, mimicking how real users interact with APIs in production applications.

Overview

When a user navigates to a page in a real application (like visiting linkedin.com/profile), the frontend sends API requests to retrieve data. The User Request component recreates this behavior in a controlled simulation environment, allowing you to test how your system handles different types of requests.

Real-World Example

Think of visiting your LinkedIn profile. When you navigate to /profile, your browser sends a GET request to LinkedIn's API (something like /api/users/your-id). The User Request component lets you simulate exactly this type of interaction.

Component Fields

1. Endpoint

The API endpoint you want to target. The /api/ prefix is automatically added, so you only need to specify the resource path.

Format:

/api/{endpoint}
/api/{endpoint}/{id}

Examples:

• users → translates to /api/users
• users/123 → translates to /api/users/123
• posts → translates to /api/posts

note

The endpoint name becomes the table/collection name in your database. For example, an endpoint users will create a users table.

2. HTTP Method

Select from four standard HTTP methods:

Method	Purpose	Body Required	ID Required
GET	Retrieve data	No	Optional
POST	Create new data	Yes	No
PUT	Update existing data	Yes	Yes
DELETE	Remove data	No	Optional

3. Properties (Request Body)

Define the data structure for requests that require a body (POST and PUT). Each property has three fields:

• Name: The field name (e.g., username, age, isActive)
• Type: Data type - string, integer, or boolean
• Value: The actual value to send

Example Properties:

{
  "name": "John Doe",
  "age": 27,
  "isActive": true
}

HTTP Methods in Detail

GET Request

Retrieves data from your system without modifying anything.

Supported Patterns:

1. Get All Records

   Endpoint: users
   Method: GET
   Result: Returns all records from the users table

2. Get Single Record by ID

   Endpoint: users/1
   Method: GET
   Result: Returns the user with ID = 1

Request Example:

// Component Configuration
Endpoint: users/1
Method: GET
Properties: (none required)

// Simulated Request
GET /api/users/1

Response Example:

{
  "status": "success",
  "data": {
    "id": "1",
    "name": "John Doe",
    "age": 27,
    "created_at": "2024-01-15T10:30:00Z"
  }
}

---

POST Request

Creates new records in your database. If the table doesn't exist, it will be created automatically.

Requirements:

• At least one property must be defined
• Properties define the table schema on first use

Request Example:

// Component Configuration
Endpoint: users
Method: POST
Properties:
  - name: "John Doe" (string)
  - age: 27 (integer)
  - isActive: true (boolean)

// Simulated Request
POST /api/users
Body: {
  "name": "John Doe",
  "age": 27,
  "isActive": true
}

What Happens:

1. Creates a users table (if it doesn't exist)
2. Defines columns based on your properties
3. Inserts a new record with the provided values
4. Returns the created record with an auto-generated ID

Response Example:

{
  "status": "success",
  "message": "Record created successfully",
  "record_id": "abc123",
  "data": {
    "id": "abc123",
    "name": "John Doe",
    "age": 27,
    "isActive": true,
    "created_at": "2024-01-15T10:30:00Z",
    "updated_at": "2024-01-15T10:30:00Z"
  }
}

Best Practice

POST requests work best when combined with the API Service Component for custom business logic. See the API Service documentation for advanced use cases.

---

PUT Request

Updates existing records in your database. You can modify existing fields or add new ones.

Requirements:

• Record ID must be specified in the endpoint
• At least one property must be defined
• Only updates/adds the fields you specify (doesn't delete other fields)

Request Example:

// Assuming John (ID: 1) exists with {name: "John Doe", age: 27}

// Component Configuration
Endpoint: users/1
Method: PUT
Properties:
  - age: 28 (integer)
  - city: "New York" (string)

// Simulated Request
PUT /api/users/1
Body: {
  "age": 28,
  "city": "New York"
}

What Happens:

1. Finds the record with ID = 1
2. Updates age from 27 to 28
3. Adds new field city with value "New York"
4. Preserves all other existing fields (like name)

Before:

{
  "id": "1",
  "name": "John Doe",
  "age": 27
}

After:

{
  "id": "1",
  "name": "John Doe",
  "age": 28,
  "city": "New York",
  "updated_at": "2024-01-15T11:45:00Z"
}

---

DELETE Request

Removes records from your database.

Supported Patterns:

1. Delete Single Record

   Endpoint: users/1
   Method: DELETE
   Result: Deletes only the user with ID = 1

2. Delete All Records

   Endpoint: users
   Method: DELETE
   Result: Deletes all records in the users table (but keeps the table structure)

Request Example (Single Record):

// Component Configuration
Endpoint: users/1
Method: DELETE
Properties: (none required)

// Simulated Request
DELETE /api/users/1

Response Example:

{
  "status": "success",
  "message": "Document '1' deleted successfully",
  "id": "1"
}

Request Example (All Records):

// Component Configuration
Endpoint: users
Method: DELETE
Properties: (none required)

// Simulated Request
DELETE /api/users

Response Example:

{
  "status": "success",
  "message": "Deleted 15 documents from 'users'",
  "count": 15
}

Important

Deleting all records (DELETE /api/users) removes all data but preserves the table structure. The table itself is not deleted and can be reused for new records.

Execution Order

User Request components have an execution order that determines when they run during simulation. Components execute sequentially based on their assigned number.

Example Flow:

#1 User Request: POST /api/users (creates user)
#2 User Request: GET /api/users/1 (retrieves created user)
#3 User Request: PUT /api/users/1 (updates user)

You can reorder components by clicking on their execution number and entering a new value.

Session Isolation

Each simulation session maintains its own isolated database state:

• User sessions: Authenticated, data persists across page refreshes within the same design
• Session data: Automatically cleaned up when you delete a design

This means you can run multiple simulations without interference, and your test data won't affect other users or other designs.

Working with Other Components

With API Service Component

Combine User Request with API Service to add custom business logic:

// User Request sends:
POST /api/users
Body: { name: "John", email: "john@example.com" }

// API Service processes:
- Validates email format
- Checks for duplicate emails
- Hashes password
- Sends welcome email
- Then creates the user

See API Service Component for details.

With Database Component

User Requests automatically interact with connected Database components. The data flows through your architecture based on your connections.

User Request → API Service → Database

See Database Component for more on data persistence.

With Load Balancer Component

When connected through a Load Balancer, your requests are distributed across multiple API Service instances:

User Request → Load Balancer → API Service (Instance 1)
                            → API Service (Instance 2)
                            → API Service (Instance 3)

See Load Balancer Component for distribution strategies.

Common Patterns

Creating a User Profile System

// 1. Create User
POST /api/users
Properties: { name: "Alice", email: "alice@example.com" }

// 2. Retrieve User
GET /api/users/{generated-id}

// 3. Update Profile
PUT /api/users/{generated-id}
Properties: { bio: "Software Engineer", location: "San Francisco" }

// 4. Delete User
DELETE /api/users/{generated-id}

Building a Blog System

// 1. Create Post
POST /api/posts
Properties: { title: "My First Post", content: "Hello World!", author: "Alice" }

// 2. List All Posts
GET /api/posts

// 3. Update Post
PUT /api/posts/{post-id}
Properties: { content: "Updated content!" }

// 4. Delete Post
DELETE /api/posts/{post-id}

Best Practices

1. Name endpoints consistently: Use plural nouns (users, posts, comments)
2. Use proper HTTP methods: Follow REST conventions (GET for reading, POST for creating, etc.)
3. Define clear properties: Use descriptive names and appropriate types
4. Test incrementally: Start with GET, then add POST, PUT, DELETE
5. Order requests logically: Create before reading, read before updating

Troubleshooting

"No body provided for POST request"

• Cause: POST request without any properties
• Solution: Add at least one property with a value

"PUT requires a record ID in the endpoint"

• Cause: Endpoint doesn't include an ID (e.g., /api/users instead of /api/users/1)
• Solution: Append the record ID to your endpoint

"Record ID 'X' not found"

• Cause: Trying to GET, PUT, or DELETE a record that doesn't exist
• Solution: Verify the ID exists by doing a GET all request first

Empty GET response

• Cause: No records exist in the table yet
• Solution: Create records using POST request first

Next Steps

• Learn about API Service Component for custom business logic
• Explore Database Component for data persistence
• Understand Load Balancer Component for scaling