Connection Object
The Connection object represents a bidirectional relationship between users in the Replyke social features framework. Unlike follows, connections require mutual agreement between two users and represent equal partnerships similar to Facebook friends or LinkedIn connections.Properties
| Property | Type | Description |
|---|---|---|
id | string | Unique identifier for the connection (UUID) |
projectId | string | Identifier of the associated project (UUID) |
requesterId | string | ID of the user who initiated the connection request |
receiverId | string | ID of the user who received the connection request |
status | 'pending' | 'accepted' | 'declined' | Current status of the connection |
message | string | null | Optional message with the connection request |
respondedAt | Date | null | Timestamp when the request was responded to (accept/decline) |
createdAt | Date | Timestamp when the request was sent |
Status Definitions
| Status | Description | Initiator Actions | Receiver Actions | Notes |
|---|---|---|---|---|
pending | Request sent, awaiting response | Can withdraw | Can accept/decline | Active request state |
accepted | Connection established | Equal partners | Equal partners | Bidirectional relationship |
declined | Request rejected | Cannot re-request | Can delete & create new | Only receiver can re-initiate |
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
- Single Model Approach: One model handles requests and established connections
- Duplicate Prevention: Only one active connection between any two users
- Re-request Logic: After decline, only receiver can initiate new requests
- Status Transitions: Clear progression from pending → accepted/declined
User Model Associations
The Connection model creates two associations with the User model:API Endpoints
User-Centric Operations
POST /users/:userId/connection- Send connection request to userGET /users/:userId/connection- Get connection status with userDELETE /users/:userId/connection- Decline/withdraw/disconnect with userGET /users/:userId/connections- Get connections of specific userGET /users/:userId/connections-count- Get connections count for specific user
Connection-Centric Operations
GET /connections- List established connectionsGET /connections/count- Get connections countGET /connections/pending/sent- List sent pending requestsGET /connections/pending/received- List received pending requestsPUT /connections/:connectionId/accept- Accept specific connectionPUT /connections/:connectionId/decline- Decline specific connectionDELETE /connections/:connectionId- Remove specific connection
Status Transitions
Valid Transitions
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
Accepting Connection
Checking Connection Status
Notification Strategy
| Event | Notify Who | Type | Notes |
|---|---|---|---|
| Request Sent | Receiver | In-app only | connection-request |
| Request Accepted | Requester | In-app only | connection-accepted |
| Request Declined | No one | None | No notification sent |
| Connection Removed | No one | None | No notification sent |
Query Patterns
Get User’s Connections (Bidirectional)
Get Pending Requests
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

