Kelly Fang 6.1040 Portfolio

Appearance

A4. Backend Design ​

Data Modeling ​

I changed and removed some of my concepts to better fit the scope of future assignments

concept: User
state:
 registered: set User
 username, password: User -> one String
concept: User
state:
 registered: set User
 username, password: User -> one String
concept: Post [User]
state:
    posts: set Post
    id: Post → one string
    author: Post → one User
    content: Post → one Content
    date_posted: Post → one Date
    location: Post → one or no Location
concept: Post [User]
state:
    posts: set Post
    id: Post → one string
    author: Post → one User
    content: Post → one Content
    date_posted: Post → one Date
    location: Post → one or no Location
concept Event [User, Trail, Post]
state:
    events: set Event
    id: Event → string
    owner: Event → one User
    name: Event → one String
    description: Event → one string
    itinerary: Event → one Trail
    date: Event → one Date
    attendees: Event → set User
    tags: Event → set String
    checklist: Event → checklist (set string → number)
    posts: Event → set Post
concept Event [User, Trail, Post]
state:
    events: set Event
    id: Event → string
    owner: Event → one User
    name: Event → one String
    description: Event → one string
    itinerary: Event → one Trail
    date: Event → one Date
    attendees: Event → set User
    tags: Event → set String
    checklist: Event → checklist (set string → number)
    posts: Event → set Post
concept: Trail [User, Post]
state:
    trails: set Trail
    owner: Trail → one User
    stops: Trail → set (Location → Post)
concept: Trail [User, Post]
state:
    trails: set Trail
    owner: Trail → one User
    stops: Trail → set (Location → Post)
concept: Comment [Post, User]
state:
    comment: set Comment
    author: Comment -> one User
    post: Comment -> one Post
    content: Comment -> one String
concept: Comment [Post, User]
state:
    comment: set Comment
    author: Comment -> one User
    post: Comment -> one Post
    content: Comment -> one String
concept: Friend [User]
state:
    friends: User -> set User
    pending: User -> set User
concept: Friend [User]
state:
    friends: User -> set User
    pending: User -> set User

App Definition ​

app trailMix
include
    User
    Post [User]
    Event [User, Trail, Post]
    Trail [User, Post]
    Comment [Post, User]
    Friend [User]
app trailMix
include
    User
    Post [User]
    Event [User, Trail, Post]
    Trail [User, Post]
    Comment [Post, User]
    Friend [User]

Data Model Diagram ​

trailMix data model

Design Reflection ​

While working on my backend service, I also had to consider how to divide the work between the frontend and the backend. In my backend implementation I do not have data/format validation implemented for fields such as date and location. In my implementation of the frontend, I would give it control over how data is processed and formatted for the backend, though I think adding some data validation in the backend would be beneficial in terms of extra error proofing.

Another example is when I was implementing my register and create endpoint for the event concept. I wanted it such that a user that creates an event would automatically be registered for it. However, I was not sure if that should constitute 2 separate API calls which would be made in the frontend, one that would create the event and one that would register the user for it right after or if it should all be included in 1 api call. I decided to go with the latter since a user should always be attending an event they create but I am currently still grappling with the decision in terms of its tradeoffs and if that is a good design decision.

Also while implementing and revising my concepts, I removed my Map concept as it felt more like a UI instead of a functionality. The map is used throughout several instances of my app as a profile, a global/friend feed, and to display event information and discussions but the UI is a combination of the user, trail, post, and friend concept coming together instead of its own concept.

I also had to consider how to keep track of the dependencies among my concepts. I wasn't sure if I should have posts point to the events they belong to or have events point to all the posts within them. I decided to go with the latter as a post can exist on its own without an event and that it would make more sense in the hierarchy of information to load all the posts for an event given the event (ex: load all posts for an event when on the event page) and that adding an extra optional field to the post data scheme may prove confusing.