GitHub repository: https://github.com/Ellezique/Full-Stack-App-PART-A
- Front end: https://github.com/Ellezique/aftercredits-client
- Back end: https://github.com/Ellezique/aftercredits-server
- This Readme: https://github.com/Ellezique/Full-Stack-App-PART-A
- Netlify front end deployment: https://aftercredits.netlify.app
- Heroku back end deployment: https://aftercredits-api.herokuapp.com/
Heroku and Netlify are connected to their respective Github repositories and are set up for automatic deployment from the master branch.
- All videos on this youtube channel: https://www.youtube.com/channel/UClVdwtuINqN1dOWUrmhG8rA
- Trello board: https://trello.com/b/VLtFLtdT/aftercredits
AfterCredits is a movie discussion app (ideally for people aged 18 and older). There are two proposed versions of the app:
A. Early Beginnings version: The initial core app version is designed to build user community. There will be one movie or series for the month, similar to a book club. Community users can see what the selected movie/series is so that they can have a chance to watch it if they haven't seen it yet. When they are ready, they can join the chatroom to discuss the movie/series with other users.
B. Expansion version: The expanded app will have multiple movies/series, each with their own chatroom. Users can join a chatroom to discuss any listed movie or series of their liking whenever they wish, rather than waiting for a single monthly selection.
From a real life marketing perspective, the plan would be to achieve continued member and participation growth by commencing with a small and intimate community and gradually expanding the collection of movie/series chatrooms as the community grows (and becomes, perhaps, less intimate due to the increased number of users), thereby allowing for the users to be spread out across multiple chatrooms.
C. Delivered Application:
The delivered application has built in functionality to create additional cards and can accommodate both the core and expansion purposes.
Users can see the listed movie/series cards with the film title and poster. A user can select a card and then see more information about the movie/series (release date, genre, cast and description) or enter the chatroom to see what other users have posted and join the discussion by posting their own comments.
AfterCredits is a site for users to get information about listed movies/series and join the listed movies/series chatroom discussions.
DISCLAIMER: The app was planned with an early beginnings version (with basic features) and an expansion version with numerous features (to strive towards but unlikely to fully implement by the deadline). The delivered application, as anticipated, includes numerous features from the expansion version but does not implement all features from the expansion version. Details of the planned early beginnings and expansion apps are included along with details of the delivered application.
A. Early Beginnings version: (see below for the functionality/featuers and screenshots in the delivered app)
Users can sign up and then log in to access the chatroom to discuss the movie/series of the month. They will need the following to sign up:
- username
- password
Authentication and Authorisation will be handled using:
- Knock
- JWT
There will be two user roles:
- Admin
- User
The home page includes one movie/series card for the month. The movie/series card will contain the:
- title
- poster (image)
The initial title and image can be saved in the source code as a placeholder. Thereafter, the movie data can be accessed from an API such as the Movie Database (IMDB Alternative). The RAPID API version currently has a basic price plan of $0.00 per month that inludes 1,000 requests per day and is available at: https://rapidapi.com/rapidapi/api/movie-database-imdb-alternative/ Once the API is implemented, the imdb_id can be stored in the database when the card is created. That imdb_id can then be used to fetch the title and poster(an image url) from the API.
A "Show more" button can then toggle additional data from the API e.g. a movie or series description.
Each movie/series card contains its own chatroom relevant to that movie/series.
Messages will have CRUD functionality. Users can post, edit and delete their own messages. Admin role users can additionally delete anyone's message to ensure a means for removing inappropriate content.
Each message will include:
- username
- message
- posting time and date
All website visitors can access the contact page.
An Admin email address will be included to allow users to contact an admin directly.
The AfterCredits head office address will be listed and accompanied by a static location map.
Styling will include the following:
- Icons: https://fontawesome.com
- Google fonts: https://fonts.google.com/
- Background image/s from unsplash: https://unsplash.com/
Each JavaScript component will have its own css stylesheet e.g. Navbar.js and Navbar.css
(see below for the functionality/featuers and screenshots in the delivered app)
B. Expansion version:
As above. An expansion feature could enable users to select an avatar image (a limited number of images posing no storage issues) or upload their own image (requiring a storage solution such as Cloudinary).
As above.
The Cards feature should have full CRUD functionality so that an Admin user can change the monthly movie/series card and add additional cards as the site grows towards the Expansion version.
The home page includes multiple movie/series cards. Each home page movie/series card will contain the:
- title
- image
Users may click on a card to view additional movie information, which may include any of the following: Year, Metascore Rating, IMDB rating, Release date, Runtime, Genre, Directors, Writers, Actors, Plot, Awards etc.
As above.
Additionally user messages can display with the user's chosen avatar or image. Users can click on a username to see all of their messages.
Each movie/series can have two chatrooms:
- with spoilers
- without spoilers A spoilers boolean could be added to the Cards table to distinguish spoiler and no-spoiler messages. An additional button will be needed to allow users to select whether they want to view the spoiler or no-spoiler chatroom.
Chatrooms can contain many messages. There could be a scroll bar or a hide/show more button so that only the most recent messages are visible but that the user may still look at older messages should they choose to do so.
As above but instead of including an admin email address, users can submit a contact form.
- The contact form could be handled using Netlify forms.
The interactive map of the business address will have a marker showing the location. Users can interact with the map. The map data can be provided by an API such as Bing Maps API, available at https://www.bingmapsportal.com/ or alternatively, the Google Maps API.
This page will also include links to the developers' GitHub accounts.
Styling could include the following:
- Icons: https://fontawesome.com
- Google fonts: https://fonts.google.com/
- Background image/s from unsplash: https://unsplash.com/
- Animated background: https://greensock.com/
- A search feature so that users can search for a particular movie or series by genre, actor, rating etc. This feature will not be pursued in the current project. It would require database design changes and features that are beyond the scope of the current project.
- Thorough solutions to moderating and handling user input and dealing with inappropriate content.
C. Delivered Application:
The backend Rails API app handles the users, messages and cards. The data is stored in a postgreSQL database.
Users can sign up if they do not have an account. The log in page has a link to the sign up page and vice versa.
If users have previously created an account, they can log in.
Authentication and Authorisation is handled using:
- Knock
- JWT
There are two user roles:
- Admin
- User
The rails api application has default users and details created in the seeds file.
The home page includes multiple movie/series cards and more can be added using only the relevant imdb id. All other details are then called from Movie Database (IMDB Alternative) hosted on Rapid API. The postgreSQL database only stores the imdb_id thereby eliminating any copyright concerns that could arise from copying data from IMDB.
A user can select the movie/series card that interests them:
A "Show more" button toggles additional movie data. A "Chatroom" button toggles the chatroom. Both can be open at the same time.
Each movie/series card has its own chatroom. The chatroom shows all messages for that card. Logged in users can post, edit and delete their own messages. Admin users can delete anyone's message.
An option button reveals edit and delete buttons. Individual messages can be edited or deleted. A pop up warns users before deleting a message.
This is a fullstack application using React app on the front end and a Rails API app in the backend. The backend Rails API handles messages, users and cards and data is stored in a postgreSQL database.
At the time of deadline, the AfterCredits app calls all messages from the server before processing them on the frontend. Future improvements to the app should handle this in the backend.
Users can contact administrators by completing the contact form. The contact form and submissions are handled by Netlify. Submissions have been tested and receipt confirmed.
Users can see the fake business address on a bing map. The map is interactive with zoom in and out buttons. There is also a locate me button, an arrow that shows or hides "Australia QLD Brisbane Brisbane City" and the option to view the map in road, aerial or bird's eye view and the option to toggle labels on or off. The bottom corner of the map has the scale. If the user hovers over the pushpin, the info box will open (which can be closed by clickin on the close circle in the top right of the infobox or by moving the mouse away).
The contact page also contains credits. The project is built by Gizelle and Chris and their GitHub profile links open in new tabs when clicked. Free use of the background videos is permitted with credit, and accordingly, hyperlinks are included for the sources.
The Navigation bar has links for log in, sign up, home and contact. When a user is logged in, the navbar shows their username and the option to log out (instead of log in/sign up).
The navigation bar is responsive and has a drop down menu. The navbar is slightly transparent. The links light up red on hover. The AfterCredits text lights up on hover.
Styling, design and aesthetics:
- The navbar icons are from fontawesome: https://fontawesome.com
- Google fonts were used to add to the limelight "hollywood" theme: https://fonts.google.com/
- Background videos are free to use and credited on the contact page. The videos are stored in cloudinary.
- Hover effects are used on buttons, links and cards.
There is a special page for error 404 with a link to the home page (to improve user experience).
Broadly, the target audience inludes anyone that enjoys watching movies/series and would like to read other users' comments and engage in discussions about movies/series. The app is a community for watchers, bingers, enthusiasts, the curious and critics alike.
A. Early Beginnings version: The target audience includes users who:
- want to join a monthly movie/series club
- want to discuss or read comments about a movie/series
- are, ideally, at least 18 years old (movies and series have classifications and age restrictions which vary between jurisdictions, therefore it is preferable that users are at least 18 years old when entering chatrooms).
B. Expansion version: The target audience includes users who:
- want to discuss or read comments about a number of different listed movies/series
- get more information about listed movies/series
C. Delivered Application: As above. The onus is on users themselves to certify and confirm that they are at least 18 years old when signing up.
- HTML: HyperText Markup Language is the standard markup language for documents to display in web browsers.
- CSS: Cascading Style Sheets describe the presentation and styling of markup language documents. There are numerous style sheets for general style, components and pages. Not all pages and componenets required their own stylesheets.
- React.js: React is a front-end (client side) JavaScript library used to build user interfaces and components. This enabled building seperate and reusable components that made the development process more organised. It also reduced code conflicts as developers could work on seperate components in seperate files. Similarly, building seperate components reduces the risk of accidentally breaking features that have already been completed, whilst also making it easier to identify where bugs are (in seperate components rather than combing through huge files of code mixing numerous components).
- Yarn: Yarn is a package manager for JavaScript (client side) that was used for this project. It is prefereable to use yarn with React apps. The most stable version currently is 1.22.5, which was used for this project. To add and remove packages,
yarn add [package]
andyarn remove [package]
. Install all project dependencies usingyarn install
. Dependencies can be upgraded to the current stable versions by runningyarn upgrade
. All dependencies and configuration for the React side of AfterCredits will be specified in the package.json file. Npm packages were accidentally introduced at some stage during development but then fixed by removing the package-lock.json file. - Jest: Jest is a testing framework that works with React projects (testing front-end). It was used for testing along with the testing-library. This is a fairly logical choice for testing a React app. Time was a restricting factor that did impact the volume of testing. Neither developer had prior jest testing experience but fortunately there are a lot of resources available.
- Packages
- Bing Maps-React is a package that makes it relatively simple to use the Bing Maps API in a React app, and accordingly requires a Bing Maps API key, which was easy to obtain without the need to register an account with a credit card. Bing Maps is free for developers to use and there is no risk of incurring fees. The Bing Maps-React package did not have documentation addressing infoboxes with pushpins but this was ultimately resolved. The package is otherwise very convenient to implement and use. Unfortunately, this particular package throws an error when testing with Jest. This error remains an open issue that has been previously reported and followed up on by one of the developers in this app: milespratt/bingmaps-react#32
- Font Awesome provides vector icons and logos. The initial logo was a vector icon, which was later replaced by a popcorn png image. Fontawesome vector icons were used for the navbar burger menu icons. It is easy to set up and use and allows for future expansion of the app to incorporate more vector icons (e.g. in chatrooms).
- Axios is a promise based HTTP client for the browser. It was especially useful on the front end application for API calls (request and response).The app uses Rails API (messages, users, cards) and the third party movie APIs.
- As this is a React application, dependencies include testing-library for react and jest as well as react-dom and react-router-dom.
- Netlify: Netlify is used to deploy the front-end React repository. The service used for this project is free of charge. Netlify forms was used for the contact form on the contact page and Netlify receives and stores the contact information submitted (and also includes a helpful spam filter). Netlify forms also provides security and is a very practical and easy to implement solution for the contact form. Netlify allows for easy handling of secret API keys stored in .env files in .gitignore - the keys were copied to Netlify using the user friendly dashboard after deployment.
The back end application is a Rails API for messages, users and movie/series cards.
-
Ruby on Rails: Ruby on Rails is a back-end/ server side application framework written in Ruby. It has a model-view-controller framework but only models and controllers were required for this backend api app.
-
Rspec: Rspec is a meta-gem used for testing in Ruby on Rails. Tests have been prepared for models and requests. See gems below. Note that informal testing was done using postman during developement (see the youtube test channel and trello cards for some examples of that testing)
-
RubyGems: Ruby Gems is a package management framework for Ruby and is used to distribute Ruby programs and libraries. RubyGems is a tool used to install gems. The following additional gems were used to assist with testing the rails api:
-
Factory Bot contains methods to dynamically create fake seed data for the testing environment. A factories folder contains files for card, message and user.
-
Database Cleaner is a gem that was used for cleaning databases in the testing environment. This gem was needed to get rid of the factory bot data.
-
Shoulda Matchers provides RSpec-compatible one-liners to test common Rails functionality that, if written manually would be longer and more error-prone. Shoulda Matchers was used to test model associations and validations.
-
Knock is a gem that provides for JWT authentication for the Rails API app. This was crucial for user authentication. It was a good solution for this app that requires users to sign up and log in.
-
Heroku: Heroku is a cloud platform that supports Ruby on Rails. It was used to deploy the Ruby on Rails repository (back-end/ server-side). The service used for this project is free of charge.
The third party API's used are:
- Bing Maps for the interactive map on the contact page.
- Movie Database IMDB Alternative to retrieve movie/series data using only the imdb id. The postgreSQL databse only stores the imdb_id. All other movie data is retrieved from the movie API.
Manual testing was recorded in video format and uploaded to Youtube. The manual video tests include tests for development and production testing. They can be accessed at the following channel: https://www.youtube.com/channel/UClVdwtuINqN1dOWUrmhG8rA
- In future, Cypress could be considered as an alternative for user testing.
- PostgreSQL: PostgreSQL is a free relational database management system. It stores the data for users, messages and move/series cards. The ERD diagram is above and shows the database structure. It was easy, fast and straight forward to link PgAdmin to Heroku to see the database contents for the deployed app. This was very helpful during early development and informal testing. The admin user feature was added towards the end which did require an update of teh ERD as isAdmin was added to the Users table, though this was easily implement in rails.
- Github: Github is a development platform and service hosting Git version control. The service used for this project is free of charge. It also integrates with Netlify and Heroku making automatic deployment from master branches a hassle free solution to continuous deployment. Additionally, Github integrates with Trello, enabling developers to attach commit messages to trello cards throughout development. Gitguard has also been integrated allowing for security scans of all code pushed to Github and Gitguard detected an a secret api key in a commit history that was pushed to Github before the keys were isolated in a .env file that was in .gitignore. The repository was private at the time but the detection allowed for a quick api key reset to ensure ongoing security and protection of the secret keys especially in the event that the repository is made public in future (as it likely will be).
- Git: Git is a version control system for tracking changes across a set of files and to coordinate work between programmers working collaboratively on developing source code.
A. SETUP
-
Create app in central repository on GitHub. Both developers will have access to push and pull- Developers must do all their work on a different branch to master and must not commit to the master branch directly.
-
Each developer clones the main GitHub repository to their local. Developers are working in VS Code.
-
In local, developers create and checkout their own branch:
$git checkout -b Developername
.
B. DEVELOPMENT
-
Developers should do all their work on their own branch and not commit to the central repositry (GitHub) master branch directly. Developers should work only on their
Developername
branch.$ git branch
to see what branch you are on. If you are not on your branch$ git checkout Developername
-
Code in your Developername branch and then stage changes in local
$ git add .
and commit changes with$ git commit -m "meaningful commit description"
. -
The developer can incorporate changes from the GitHub repo into the branch that they are on by making sure they are on their
Developername
banch and then:$ git merge master
. They can pull using$ git pull origin master
. Resolve conflicts locally in VS Code before pushing to GitHub. -
Developers can push their changes to GitHub from their developer branch
$ git push origin Developername
. Developers can then follow the prompts in the GitHub repository "Pull requests tab" to merge their Developername branch with the Github master branch (green buttons) and delete their branch after it has been merged with the Github central master branch (purple button).
Who are they? | What is their main goal? | What is their main barrier to achieving this goal? | |
---|---|---|---|
Binge Watcher | A person that uses streaming services such as netflix to binge watch shows and movies | To discuss in real time what is happening in their favourite shows while they are watching them | Finding a chat application that supports live message updates without having to refresh the page/app |
Who are they? | What is their main goal? | What is their main barrier to achieving this goal? | |
---|---|---|---|
Movie Enthusiast | A person that regularly goes to the cinema to watch the latest movies | To find a place where others that share their interest can gather to discuss the latest movies | Finding a website that facilitates discussion around this mutual interest |
Who are they? | What is their main goal? | What is their main barrier to achieving this goal? | |
---|---|---|---|
AfterCredits Administrator | Users with admin privileges on the AfterCredits web app | General admin duties around card creation and chatroom monitoring | The functionality present in the app and the authentication mechanism present to limit who can access that functionality |
As a Binge Watcher of TV shows and movies, I want to feel like the discussion I have in the chatroom is happening in real time so we can react/discuss things that are happening as it unfolds.
As a Binge Watcher, I want to be able to use the site on my phone and for it to be a smooth experience so I can stay in the conversation while I am on the move.
As a Binge Watcher, I dont want other users to be able to change my posts, so I know what I post is safeguarded and is my own content.
As a Binge Watcher, I want to be able to contact an Admin so that I can send them feedback about the site or to inform them about issues I have with either the site or other users.
As a Movie Enthusiast, I want to go into chatrooms based around my favourite films/shows with others, so I can share my opinions and gain insight from our discussions.
As a Movie Enthusiast, I want to be able to view the initial content of the site without registering so I can see what it is all about before I go through a potentially annoying and lengthy process of creating an account and giving away my personal details.
As a Movie Enthusiast, I want my posts to be there when I return to the chatroom so I can continue the conversation later.
As a AfterCredits Administrator, I want to have the ability to remove certain user messages from the chatroom if they are deemed to break the terms of service for the web app, so I can ensure the chatroom stays civil even during heated discussions.
As a AfterCredits Administrator, I want to be able to manage movie/series cards for Users to view and interact with, so I can enable users to have their conversations on that particular movie/series.
As a AfterCredits Administrator, I want to be able to join the conversation alongside other users, so I can share my views on my favourite hobby with them.
Wireframes were prepared using Balsamiq Wireframes.
A. Planning: Early Beginnings version
B. Planning: Expansion version
C. FINAL WIREFRAMES for the Delivered Application:
Planning commenced with a discussion and presentation of various concept ideas. One concept idea was selected and developed into a project idea. Gizelle planned the initial idea, app, apis and some dependencies and prepared the intial trello cards. Chris assisted with fleshing out the idea and adding additional trello cards before and during development.
The aim of this project was to build the core app (Early Beginnings) first and then incorporate features from the Expansion version. The aim was not to deliver the full expansion version, but rather to build as many features as possible, towards the full expansion app, within the allowed development timeline. More expansion features were incorporated into the delivered app than initially anticipated during the planning phase.
An Agile methodology was used in this project. This methodology allows for changing the requirements at any time to adapt to challenges encountered and to incorporate additional features as time permits. The team managed the project jointly rather than appointing a single project manager.
Informal testing was performed concurrently with development e.g postman was used to test all crud functionality for cards, users and messages during development (some but not all screenshots of this testing were recorded in trello cards and some testing is recorded in a youtube test video). User testing videos were recorded and uploaded to youtube.
Both the front and backend apps were deployed early and often. Most formal framework testing for both the rails and react apps were done in the late stages of development. Test Driven Development was not used during this project, allowing developers to built as many features as possible before the deadline. Admittedly, TDD would be best practice but neither developer had significant testing experience prior to the project and agreed to prioritise building features over learning testing at outset. Testing cards were not assigned to specific developers early on because it was initially proposed that developers write tests for the components that they build. Due to time constraints and various components depending on completion of other components and code, the latter was prioritised over early test writing. Gizelle wrote the backend tests and recorded the user test videos for youtube but wrote very limited tests for react due to time constraints. Neither developer had time to finish writing tests for the front end application by the deadline.
Gizelle created and deployed both front and back end apps. She wrote most of the backend code, did the styling for the front end and built the navbar, contacts page (including contact form and Bing Map), Sign up and Log in forms. Gizelle also prepared most of the documentation.
Chris is the more experienced React developer and wrote the code for the most important and complex components of the front end app - the cards and messages components that handle the third party movie API (to retrieve movie data for each imdb id stored in the database) and Rails API (messages, users and cards data from the postgreSQL database). Chris also took on integration. He also prepared the dataflow diagram, user stories and application architecture diagram for the documentation.
Some tasks were assigned and allocated at outset. Later tasks were picked up by developers in accordance with their preference, skills and capacity.
Trello is a Kanban-style web application used for organizing collaborative projects. Columns represent stages of the process (to do, working on, blocked, finished). Cards represent tasks. These task cards are moved between the column stages as work on the task progresses. The board, as a whole, provides a visual depiction of the project progress.
The Trello board used for this project is online at: https://trello.com/b/VLtFLtdT/aftercredits
Cards are arranged by 4 main categories:
- To Do - Part A (pink)
- To Do - Back End (cyan)
- To Do - Front End (yellow)
- Other Criteria Part B (orange)
Cards contain information about the relevant task or criteria, a color cover corresponding to the column category (for ease of progress tracking), difficulty level, deadlines and task allocation.
The Trello Board, columns and preliminary cards for the overall project are created. All tasks for Part A are allocated.
Developers work on multiple tasks concurrently.
Developers agreed to take a break from the project over the weekend. Card deadline updated from aspirational early-finish deadline to actual deadline:
Added more Part B card details and checklist items:
Please visit the Trello board to see expanded details for card activity as recorded over time: https://trello.com/b/VLtFLtdT/aftercredits