A big part of the fun of designing an application is making decisions about what to prioritize.
You make those decisions by asking questions like:
- What are the essential features of the project?
- What are the time costs of those features?
At this stage of the project, I'm able to view a blog feed of all users and then by clicking on a list of usernames, convert that feed into a list of posts by the selected user.
The oldest posts currently in the database were created manually for testing purposes - they were hardcoded with the following fields: author, title, text, and date.
The most recent addition to the site is a functioning endpoint at /create, aka a 'write a post' page, that allows you to input a title and body into textarea fields and POST that data to the API.
The server then reads that data and also collects the user info via the OpenId info attached to the post request by middleware. Now it has everything it needs to create a Mongo document (ie. a record).
The problem is that OpenId is pulling my user info from my google account - an account that has some bio information that a user might not be willing to share publicly. The easy solution might be to use the email address as username for now, but looking at an email address in the user-list just looks awful. Email as username just doesn't seem right.
So I've decided that my next step is going to be implementing a User Model which will provide the following benefits:
Displaying dynamic usernames instead of email addresses or personal name.
Normalizing the DB by moving a step toward storing user info in the Blog Post model. This has already been a pain when writing a query to fetch all usernames for the user list.
I'll be able to build on the user model to implement a sign-up page.
Top comments (0)