Skip to main content

​
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

PropertyTypeDescription
idstringUnique identifier for the connection (UUID)
projectIdstringIdentifier of the associated project (UUID)
requesterIdstringID of the user who initiated the connection request
receiverIdstringID of the user who received the connection request
status'pending' | 'accepted' | 'declined'Current status of the connection
messagestring | nullOptional message with the connection request
respondedAtDate | nullTimestamp when the request was responded to (accept/decline)
createdAtDateTimestamp when the request was sent

​
Status Definitions

StatusDescriptionInitiator ActionsReceiver ActionsNotes
pendingRequest sent, awaiting responseCan withdrawCan accept/declineActive request state
acceptedConnection establishedEqual partnersEqual partnersBidirectional relationship
declinedRequest rejectedCannot re-requestCan delete & create newOnly 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

  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

The Connection model creates two associations with the User model: 
// 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

EventNotify WhoTypeNotes
Request SentReceiverIn-app onlyconnection-request
Request AcceptedRequesterIn-app onlyconnection-accepted
Request DeclinedNo oneNoneNo notification sent
Connection RemovedNo oneNoneNo notification sent

​
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
  • 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