Assignment 4: Backend Design & Implementation ​

a. Abstract Data Models ​

concept User ​

state
  username: one String
  password: one String

state
  username: one String
  password: one String

concept Session[UserT] ​

state
  user: one UserT
  startTime: one Time

state
  user: one UserT
  startTime: one Time

concept Labels[ItemT, UserT] ​

state
  owner: one UserT
  labels: set String
  map: lables -> set ItemT

state
  owner: one UserT
  labels: set String
  map: lables -> set ItemT

concept Limit[ItemT] ​

state
  item: one ItemT
  count: one Number
  const maxLimit: one Number

state
  item: one ItemT
  count: one Number
  const maxLimit: one Number

concept Profile[UserT] ​

state:
  owner: one UserT
  following: set UserT
  timeActive: one Time

state:
  owner: one UserT
  following: set UserT
  timeActive: one Time

concept Post[ContentT, UserT] ​

state:
  content: one ContentT
  owner: one UserT

state:
  content: one ContentT
  owner: one UserT

b. Concept Implementation --> ( HERE ) ​

c. Routes Implementation --> ( HERE ) ​

d. Vercel Deployment --> ( HERE ) ​

e. Design Reflection ​

The most significant trade-off that I had to consider was implementing the notion of a LimitedProfile (how many times can a user post per day?) and a LimitedPost (how long can a post's content be?). They have the same exact functionality, apart from the maxLimit (number representing the upper bound of a Limit). One trivial option that I initially went with was creating a single LimitedConcept with multiple collections, and having a single instance variable that mapped a Limited[T] to a maxLimit. Although this would satisfy my current implementation, this is not very scalable. For instance, I am considering adding a LimitedUsage concept for each particular user. Adding the collection would be trivial; however, this other concept would possibly need unique methods (i.e updating a usage Limit). Thus, I created a LimitedAbsConcept and two trivial implementations for LimitedProfile and LimitedPost to give myself flexibility in the future.

I ran into a similar choice for my Label concept. In theory, I want users to be able to either label a certain post, or label an account (and thus have all of this account's posts be under that label). Initially, it seemed that this should be a singular concept, with no clear distinction between the item being labeled in my Label collection. This is the one aspect of my implementation that I certainly wish I had changed (and will change in the future). The callback to determine whether a labeled item is a profile, and then acquiring all of this profile's posts is a significant amount of logic for a callback. The implementation, scalability, and efficiency would be much better if I had implemented an abstract class like I did for my Limited concept.

Apart from that, I am pleased with my implementation. Tying my various concepts together went pretty smoothly.