WeTalk is a project I worked on while learning the basics of web development. It uses Flask, which is a Python Microframework, and PostgreSQL as the DBMS. WeTalk is hosted on Heroku. Following features were implemented -
Following are some screenshots of WeTalk:
Following is the Entity Relationship (ER) Diagram of WeTalk:
On an abstract level, WeTalk has two major entities, namely User and Post. There are four relationships between them – “User follows another User”, “User creates a Post”, “User likes a Post” and “User comments on a Post”.
Entities –
The “User” entity stores data for each user. User entity has three unique attributes – ID, Email and Username. ID was chosen as the primary key among them. Other attributes for the User entity are password, is_admin and joined_at. “is_admin” is a Boolean attribute that indicates if the user is an admin. The joined_at attribute is a timestamp that stores the user’s onboarding time.
The “Post” entity stores data for each post made on wetalk. The primary key for Post is “id”. Other attributes are content, timestamp, and image. Post entity has three derived attributes, namely “imageThere”, “numLikes”, and “numComments”. “imageThere” indicates if the user has uploaded any image with the post, “numLikes” and “numComments” are the number of likes and comments for a post.
Relationships –
As we can see from the schema diagram, we have separate tables for keeping the record of likes and comments on each post. The likes and comments table have user_id and post_id as foreign key fields. The “Relationship” table is used to keep track of follower-following relationship between users. As we have followed the theory of database design and have kept separate tables for separate records, there is no redundancy in our database and it is in 3rd normal form, which is sufficient for practical purposes.
The deployment platform that we are using, Heroku, supports easy setup of CI/CD pipelines with triggers from GitHub repository. For example, the image above shows a pipeline set up so that every pull request on the connected GitHub repository (to merge testing branch to master branch) will trigger the creation of a “Review App”. In case the pull request is approved, that will automatically trigger a new build by Heroku and deploy it. Also, any commit on the repo’s master branch will also trigger a rebuild.
This way, we can minimize the development time that goes into deploying the app manually every time there’s a minute change.
This was a short description of the project. Thanks for reading.