Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am designing an application where users message one another privately, and may send messages to any Entity in the database (an Entity may not have a user account yet, it is a professional database). I am not sure how to best design the database and the API to allow messaging unregistered users. The application should remain secure, and data only accessed by those with correct permissions.

Messages sent to persons without user accounts serve as an invitation. The invited person should be able to view the message, act on it, and complete the user registration upon receiving an InviteMessage.

In simple terms, I have:

User
    misc user fields (email, pw, dateJoined)

Entity (large professional dataset):
   personalDetails... 
   user->User (may be null) 

UserMessage:
   sender->User 
   recipient->User
   dateCreated
   messageContent, other fields.....

InviteMessage:
   sender->User
   recipient->Entity
   expiringUrl
   inviteeEmail
   inviteePhone

I plan to alert the user when selecting a recipient that is not registered yet, and inform that he may send the message as an invitation by providing email, phone where we can send the invitation.

Invitations will have a unique, one-time-use URL, e.g. uuid.uuid4(). When accessed, the invitee will see the InviteMessage and details about completing his/her registration profile.

When registration is complete, InviteMessage details to a new instance of UserMessage (to not lose their data), and assign it to the newly created User.

The ability to interact with and invite persons who do not yet have accounts is a key feature of the application, and it seems better to separate the invitation from the private, app messages (easier to keep functionality separate, better if data model changes).

  • Is this a reasonable, good design?
  • If not, what would you suggest?
  • Do you have any improvements?
  • Am I correct to choose to create a separate endpoint for creating invitations via the API?
share|improve this question

1 Answer 1

If a message can be sent to any Entity, it would make more sense to associate the message with the receiving Entity rather than with the user. If you do that, you don't need to distinguish between invitations and normal messages; instead, you can write the invitation-specific data in an own table:

 User:
     misc user fields

 Entity:
     personalDetails
     user -> User (nullable)

 UserMessage:
     sender -> User
     recipient -> Entity
     dateCreated
     messageContent

 Invitation:
     content -> UserMessage
     expiringUrl
     inviteeEmail
     inviteePhone (aren't these two field part of Entity?)

This increases maintainability: If you ever want to add an additional field to UserMessage you'd have to also change InviteMessage and the code copying an InviteMessage to a UserMessage with your approach.

Moreover, assume that an Entity has received multiple invitations. You'd want persist all of them when a new user account is created. This is also easier if you don't need to copy the message (just delete all Invitations of the Entity's messages).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.