Repository for coursework for TechEd Software Development Bootcamp - Week 05
Static Site (Client): https://teched-sd-w05.onrender.com/
Web Service (Server): https://teched-sd-w05-server.onrender.com
- Kev B. - LinkedIn | Website | Email | Github
- Connor L. - Github
- Colin C. - LinkedIn | Portfolio | Github
- Themba .M - Github
As a group of fine, fine gentlemen; design and build a web application that utilises a snazzy and responsive, yet accessible, front-end webpage. The back-end must consider of a node.js server and SQLite database that can handle requests (GET, POST, DEL, PUT) from the client to insert, update or remove records from the database.
All requirements are complete, however we were unable to meet all stretch goals.
- ...quickly show that I do not recommend a TV show by pressing a button.
- ...quickly show that I recommend a TV show by pressing a button.
- ...write a review on a TV Show for others to see..
- ...see the latest TV shows on the web page.
- ...see overall ratings on each TV show.
- ...read other user's reviews on TV shows.
- ...see the website logo, navigation and title.
- ...navigate the website using a screen-reader and/or without using a mouse.
- ...see the footer containing copyright and company information.
- Design: Demonstrate proper design practices by creating wireframes, data flow and database schema. The application must include both client-side and server-side code.
- Front-End Dev: Develop a user interface with HTML and CSS, focusing on responsive, accessible and intuitive design. Implement async/await and the Fetch API for non-blocking database operations and API calls.
- Interactivity: Implement dynamic content on the front-end using vanilla JavaScript for DOM manipulation. Ensure the application is fully responsive and works across modern browsers.
- Back-End Dev: Build a server with Express that handles HTTP requests and communicates with an SQLite database. Use Express.js to set up your server and define API endpoints.
- Database Integration: Design a database and use SQLite to store, update and retrieve data efficiently using SQL queries. Demonstrate an understanding of database edsign, relationships and SQL queries. Use SQLite with the better-sqlite3 library for database operations.
- Collaboration: Work as a team to design and build a web application that showcases your skills in full-stack development, and collaborate on code using Git and Github.
- Presentation: Produce and present your problem domain, user stories, design and technical implementation to the class in the form of a 10minute presentation.
- Let someone else do it!: Use external libraries to add some pa-zazz to the project.
- Rebelling against Conformity: Have different functionality for each 'section' of viewing (eg, rank movies, only show movies with reviews, etc).
- We are Legion: Use more than one webpage to display information about TV shows.
- Stick around and find out!: Have basic user persistence and login (no auth).
- With great power, comes great responsibility: Be able to modify, delete TVshows, reviews and users.
- I'm in your computer, nabbin' your datas: Use a fancy API to grab existing TV Show data.
- HTML: Both index.html and its iframe popup template, closeup.html, are located in the /client/ folder.
- CSS: style.css is located in the /client/ folder.
- JS: All .js files (networkHandler.js, app.js, galleryBuilder.js, closeup.js) are all in the /client/ folder.
- IMGs: Client images are held within /client/public to facilitate inclusion within vite builds.
- JS: server.js and seed.js are in the /server/ folder to facilitate rapid testing of server and DB. Other .js (wordlibs.js, dbHandler.js) are found in the /server/assets/js folder.
- IMGS: Some images are located on the server within /server/assets/imgs but are not used. This was for a triaged goal of hosting the image files on the server or within the DB.
- JS: dbHandler.js is located in the /server/assets/js folder.
- SQL: All SQL queries are localted inside the /server/assets/js/dbHandler.js file.
- DB: The .db file itself is held within the /server/assets/db/ folder.
The team discussed what kind of application we'd like to make and once a decision was made, weworked on wireframes and some quick mockups to get the rough idea in place. These were refined and basic implementation was put in place to see how it looks on a page. The server side design was mapped roughly with our initial understanding of the problem domain and we prepared basic routings based on that. Given the overall project direction, it was identified that the DB would require at least 3 tables with differing elements, as well as a relationship between users and TV shows via reviews.
The frontend was designed with a clearly defined style and structure, and each section has a different context around TV Shows. The final frontend product was tested against Lighthouse and WAVE for accessibility and responsivity at typical mobile phone resolution.
Interactivity via the front end was achieved through the carousel drag, arrows to provide easy accessibility if dragging is difficult and ability to write reviews.
The backend was designed to be straight forward and have semantic endpoints that make sense. From a technical standpoint, it was designed to be a minimal API-like approach where internals were hidden from other layers and only safe, reliable access points were available for use.
The DB has many different queries all pre-prepared. These range from SELECT, INSERT, DELETE, UPDATE. A couple of queries use INNER JOINS to produce the required output for the client. The DB consists of three tables; users, tv_shows and reviews. users and tv_shows have a relationship to reviews, which links a review, user and tv show together via PKs/FKs.
As a team, we made decisions together and iterated on designs and concepts until all were in agreement that it was in an acceptable and actionable state. This process was facilitated by tools like Trello, Figma and of course, Google Meet.
For the presentation, as a team we had a meeting to discuss which elements we could fit into the available 10 minutes and that would match the requirements criteria. Once that was established, we partitioned the workload between each member based on their strengths and knowledge.
We should get government funding for the amount of libraries we stuck in this project! It was two. We added two libraries. Glide.js for carousels and Fancybox.js for popping up iframes.
Carousels go wheeeee! We implemented the carousels to hold the unique content in each section. This gave it a very fun-to-use, clean control layout and minimised the clutter of content across the style of the site.
We initially intended to implement a static page rather than iframe, but we decided to triage that away mid-way to focus on more important items in MVP. As we approached the deadline, we found scope to bring it back but in a more interactive way. And thus, iframe pop-up was born! It uses a pre-defined layout from closeup.html.
We unfortunately were unable to implement this. However, we implemented a similar feature via review persistence.
We had the back-end database able to modify and delete records, but did not have time to implement this on the server and client.
We explored this early on in the project but were unable to secure a solid API that gave us the required data and that was free within our discovery phase. So we opted to remove this from scope mid-way in the project.
Using the glide.js library, the team implemented smooth carousels and tweaked the Options of the library to produce desired results.
Using the Fancybox.js library, the team implemented iframe popups to display then populate information about TV shows.