​

Connection Object

​

Properties

​

Status Definitions

​

Characteristics

​

Bidirectional Relationship

• Mutual Agreement: Requires approval from both parties
• Equal Partnership: Once accepted, both users have equal status
• Request/Response Workflow: Structured approval process
• Complete History: Maintains full interaction history

​

Business Rules

1. Single Model Approach: One model handles requests and established connections
2. Duplicate Prevention: Only one active connection between any two users
3. Re-request Logic: After decline, only receiver can initiate new requests
4. Status Transitions: Clear progression from pending → accepted/declined

​

User Model Associations

// User hasMany Connection as "sentConnections" (as requester)
User.hasMany(Connection, {
  foreignKey: "requesterId",
  as: "sentConnections",
  onDelete: "CASCADE"
});

// User hasMany Connection as "receivedConnections" (as receiver)
User.hasMany(Connection, {
  foreignKey: "receiverId",
  as: "receivedConnections",
  onDelete: "CASCADE"
});

​

API Endpoints

​

User-Centric Operations

• POST /users/:userId/connection - Send connection request to user
• GET /users/:userId/connection - Get connection status with user
• DELETE /users/:userId/connection - Decline/withdraw/disconnect with user
• GET /users/:userId/connections - Get connections of specific user
• GET /users/:userId/connections-count - Get connections count for specific user

​

Connection-Centric Operations

• GET /connections - List established connections
• GET /connections/count - Get connections count
• GET /connections/pending/sent - List sent pending requests
• GET /connections/pending/received - List received pending requests
• PUT /connections/:connectionId/accept - Accept specific connection
• PUT /connections/:connectionId/decline - Decline specific connection
• DELETE /connections/:connectionId - Remove specific connection

​

Status Transitions

​

Valid Transitions

pending → accepted (by receiver)
pending → declined (by receiver)
pending → [DELETED] (by requester - withdraw)
accepted → [DELETED] (by either - disconnect)
declined → [DELETED] (by receiver only - to allow re-request)

​

Invalid Transitions

• declined → accepted (must delete and create new request)
• Cannot change status once responded (except delete for disconnect/re-request)

​

Usage Examples

​

Sending Connection Request

POST /users/user-123/connection
Body: { "message": "Hi! I'd like to connect." }
→ Creates Connection with status="pending", requesterId=current-user, receiverId=user-123

​

Accepting Connection

PUT /connections/connection-uuid/accept
→ Updates status to "accepted", sets respondedAt timestamp

​

Checking Connection Status

GET /users/user-123/connection
→ Returns detailed status: none/pending/connected/declined with metadata

​

Notification Strategy

​

Query Patterns

​

Get User’s Connections (Bidirectional)

-- User is connected if they are requester OR receiver with accepted status
SELECT * FROM Connections
WHERE projectId = ?
  AND status = 'accepted'
  AND (requesterId = ? OR receiverId = ?)

​

Get Pending Requests

-- Received requests
SELECT * FROM Connections
WHERE projectId = ? AND receiverId = ? AND status = 'pending'

-- Sent requests
SELECT * FROM Connections
WHERE projectId = ? AND requesterId = ? AND status = 'pending'

​

Performance Considerations

• Indexes: Optimized for queries by requesterId, receiverId, status, and projectId
• Pagination: All list endpoints support pagination
• Rate Limiting: Connection requests limited to 25 requests per 5 minutes
• Caching: Consider caching connection counts and lists for active users

​

Related Models

• User: The users involved in the connection relationship
• Follow: One-way relationship alternative that doesn’t require approval
• AppNotification: Notifications for connection requests and acceptances