CSE 134B: Jeff Evans Fan Club

HW 5

In the previous assignment we made our Soccer Application "work," but we did not fully integrate it with a cloud hosted environment nor prepare it for the final release to production. In this final assignment we finish wiring up the application and make it work as a highly resilient progressive web application (PWA) that performs excellently on our median Android phone throttled to a 3G connection. We aim to do this using plain Vanilla JavaScript with some assistance from a Google library, though an extra credit section will allow you to explore another approach using a modern JavaScript framework of your choice.

App Details

TeamWatch is provides users with a convenient solution for managing soccer teams. Coaches are able to create an account with their team. They are then able to add their respective players and games with their opponents. They would be able to also edit their players and games. The app is able to consolidates the stats and shows each of the games stats. Coaches would also be given an access code which they could distribute to players and fans, so they too could also track the team’s progress and stats.

Login Details

Users are given three options to sign up with: as a coach, as a player, or as a fan. When you sign up as a coach, you are also creating a team in which you are the coach of. As a coach you are given access, to all the CRUD operations, as you are able to add, edit, and delete players, games, game statistics, and opponents. When you are creating an account as a player or a fan, you must enter an access code of a team, and you are able to view the team data.

Data Management

Our database is organized as:

users/

 team

 admin

teams/

 name

 logo

 games/

  active

  date

  location

  opponent

  time

 stats/

  stat

 players/

  name

  number

  position

  image

  stats

 opponents/

  logo

  name

We used Firebase for our authentication, and database using Firestore. When users create accounts they we use FirebaseAuth to authenticate and create their accounts. When a user account is created, a user account is created in the database with a team and admin field. The team’s of the user accounts contain the team name, its logo, and a collection of games, players, and opponents. Games contains whether it is active, the date, location, opponent, time, and a collection of stats. Players has the name, number, position, image, and their stats such as goals scored and yellow cards. Lastly the opponent collection only stores the logo and name of the opponent, which is used to display the versus page.

We decided to go with this approach, because each of the users have their individual teams that they follow. In addition, the way firestore organizes data, allows us to query the individual properties of each of the collections, without returning the subcollections. This allows us to make minimal network calls to get what we want when we need it.

By using firestore, we were able to able allow for offline persistence, which allows for offline CRUD.

PWA

We used webwork to generate the service worker. The service worker caches all the html, css, and javascript files. For the more dynamic pages, we used network first because the user needs to see the more recent data on those pages. Our app passes the Lighthouse test for PWA.

Optimizations

In addition to using service workers with workbox and offline persistence with Firestore, we also use minification and image compression. For minification, we used a gulp-minifier, which uses html-minifier, UglifyJS, and Clean CSS. We used Optimizilla to compress our images, which significantly reduced the file sizes.

Assessment

While we believe we added a fair amount of features in our application, there were a few things that did not work and we think could have been improved on. In general, our code quality is not consistent, as each of the team members did their respective parts and we did not have a consolidated pattern or guideline to follow. This applies to the JS and CSS, as both could be better written, but we lacked to time to organize it. In addition, we feel we may have included some additional network calls to retrieve the data for the pages. We could have reformatted the organizational structure of the data, figured better, more efficient ways to query things on a page, or looked more into caching. Thus, our performance takes a bit of a hit on the pages in which we have to make multiple network calls. While our app was able to pass Lighthouse’s PWA test, we found that the add to home page and the splash screen did not seem to work. Also, while we used Firestore for offline persistence, we found that it did not seem to work too well with adding/editing things in the database while offline. There would be network errors that would appear in the console, though the data would be added when the page is refreshed. Lastly we found that minifying the page caused problems with registering the service worker.

Load Time and Size Analysis:

Page Load Time Page Size
Login 861 ms 1.5 KB
Sign Up 811 ms 1.5 KB
Coach Sign Up 828 ms 2.1 KB
Player Sign Up 806 ms 2.1 KB
Home Page 892 ms 3.9 KB
Schedule 897 ms 3.5 KB
Game Detail 951 ms 6.3 KB
Add Game 875 ms 2.6 KB
Edit Game 926 ms 3.0 KB
Add Event 904 ms 2.5 KB
Players 933 ms 5.2 KB
Add Player 887 ms 2.5 KB
Edit Player 936 ms 3.5 KB
Player Details 922 ms 2.2 KB
Settings 951 ms 3.2 KB
Edit Team Information 974 ms 4.0 KB
Manage Opponents 888 ms 2.5 KB

We ran our performance analysis of the optimized version of our website on a device running Android 5.1.1. We used the Chrome DevTools to emulate the device running on a Slow 3G network.