Assignment 4: Backend Design & Implementation
Links
ADMs
Design Reflection
Follow mostly worked as a pared-down Friends concept, and Context much like Posts. However, I eventually realized that Context also needed an optional author (optional because autogenerated ones are allowed), to be informative and allow deletion / tracking whether a user had already submitted a context to a post.
I struggled to decide how to implement upvotes. I went back and forth between representing the UpvoteDoc as one target and one user, vs one target and a set of users. I eventually decided to represent upvotes as individual entries. Keeping the users in an array would have made it easier to count the number of upvotes, but also would have made it a lot slower and more complicated to actually upvote or downvote. I figured that even though counting is a common operation, since MongoDB has relational database qualities, it wouldn’t be much more inefficient than scanning through an array if there were enough upvotes on a single post, and it would keep the code simpler.
When designing my routes, I wasn’t sure whether to keep the context and post upvotes separate. My main rationale for separating them, besides following the instantiation example from the tutorial, was that they have slightly different behavior. Basically, the context upvote should also update which context is displayed alongside the post, since I want the most upvoted context to be visible when the post is unopened. However, I eventually made getTopContext its own sync rather than putting it in the upvote / retract context upvote syncs, so I think it might not have been necessary to keep them separate after all.