Swish talks to several services as of now (Mux, Algolia, GCS), and the number of tokens/keys/secrets it will have to keep track of will only grow as it's feature set grows. Passing secrets in as non-source-controlled environment variables worked fine for development, but a full Secrets Management solution should be implemented during the transition to K8 deployment.

(From GitLab)

(From GitLab)

(From GitLab)

No channels are shown in the channel tab.

User authentication + authorization checks have to be implemented in the APIGatewayService. User authorization checks also have to be implemented in relevant services (VideoContentService, VideoDataService, etc.). This means that user auth information must be passed to subsequent services from APIGatewayService.
(From GitLab)

Some of the unit tests (in particular my first, the VideoDataService unit test) have a lot of hard coded values. Hard coded values are non-configurable, so those should all become variable values tied to one const declared at the beginning of the test.

(From GitLab)

uploadIcon in ChannelContentService needs a unit test. It should test the uploading and piping activity.
(From GitLab)

So far tested on Firefox and Chrome. Videos will not play.

The SearchService needs implementation. It needs to manage Algolia search index entries.
(From GitLab)

Resources need limits. Users should only be able to have a set number of channels, channels should only be able to have a set number of videos, etc. Limits need to be implemented both as a hard check on the backend and a soft error on the client.

Counts that need limiting:

1. Channel count (per user)
2. Video count (per channel)
3. Upload size (per video)
4. Video duration (per video)
5. Upload size (per channel icon)

(From GitLab)

(From GitLab)

(From GitLab)

(From GitLab)

Both mobile and web platforms need a log out button. The web app is more urgent.

This is probably caused by the auth token expiring or getting cancelled, but I thought the auth module was supposed to handle both those cases.

Google's preferred means for a GKE cluster to authenticate with GCP services is using the workload identity feature. While the system I'm using right now suffices, I should try to stay in good practice and switch as soon as possible.

Add code tracing with Stackdriver to improve visibility of performance.

https://opentelemetry.io/

Editor configuration files (VSCode, linting files, prettierr files, etc.) need to be configured in a standard way regarding JS/TS rules and indentation. All files should exist at a root level.
(From GitLab)

Add support for Google Analytics in both the web and mobile apps

Errors need tests too! Services should be tested in a way to stimulate error responses and those errors should be validated as correct (Only the type and the fact it returns an error, actual error message details don't need to be tested).
(From GitLab)

(From GitLab)

The mobile app doesn't present or track watch time.

The backend will need error handling code that goes beyond always returning a 500 and the Node error message.

Standard errors need to implemented for 404 Not Found, 400 Bad Request, and 500 Internal Server Error. Error handling should also be able to work with the chained nature of the services, nesting errors until reaching the API Gateway service, where it will be parsed into a client-readable form.
(From GitLab)

Documentation should not be split between TypeDoc and many README.MDs. What could be done is:

• Consolidate all documentation into READMEs and remove TypeDoc annotations

or

• Remove all the READMEs and move to untyped JSDoc annotations. If we're moving forward with annotations, it makes far more sense to use JSDoc for its much larger assortment of features rather than TypeDoc.

(From GitLab)

The web app needs to be accessible by crawlers. This means bypassing auth once a connecting client can be identified as a crawler, and serving them a stripped down web page meant for indexing.

A Gitlab CI/CD pipeline configuration file is needed. This also means a CI/CD pipeline needs to be designed.
(From GitLab)

(From GitLab)

Useful diagram:

The API needs a full integration test. The DB, Algolia index, GCS Bucket, and Mux Asset List need to be cleared. Once everything is cleared, all API endpoints should be individually tested and checked off as working as expected. The following needs testing:

1. Expected non-error functionality
2. Authorization bounds (401s)
3. Error states (404s)
   (From GitLab)

The Swish backend (and later frontend) will require a logical (or virtual) separation between production data. To do so, all services used must be namespaced into separate environments.

Algolia: Algolia supports separate indices. One index will be made for each environment, and upon startup, the application will specify a different index ID depending on the loaded environment.

• 2 indices: dev_swish, prod_swish

Mux: Mux supports separate "environments". Mux environments act as separate namespaces for all their video resources. One Mux environment will be made for each environment, and upon startup, the application will choose the correct API credentials depending on the loaded environment. This also means there will be different webhook secrets, so 2 event pipelines are needed.

• 2 environments: Development, Production
• 2 google functions: dev-muxWebhookPortal, prod-muxWebhookPortal
• 2 PubSub topics: dev-mux-events, prod-mux-events
• 2 PubSub subscribers (1 for each topic): dev-swish-api, prod-swish-api

CDN: Google Cloud Storage has separate buckets. One bucket will be made for each environment, and upon startup, the application will choose the correct bucket ID depending on the loaded environment.

• 2 buckets: dev-swish, prod-swish

Database: While Google Firestore does not support any native namespacing, I can create my own by prefixing. Collections will be prefixed so the application can choose where to look for resources depending on the execution environment.

• 2 prefixes: dev, prod

(From GitLab)

(From GitLab)

Adding support for Channel icons includes buildup of ChannelContentService. At the moment it contains nothing but a markup file. It needs an implementation of the /uploadIcon endpoint. That endpoint needs corresponding code in the APIGatewayService. ChannelDataService also has to be updated, since channel schema will change with the addition of a new field for channel content.
(From GitLab)

After uploading a video, the redirect brings you to a page which results in a "video.content is null" error

(From GitLab)

The API allows unlimited uploads to a single video. While this isn't possible using the UI, if someone were to RE the API they could rack up quite the bill for us.

The mobile UI needs significant touchups before it's ready to be released.

Player:
The video player needs a complete redesign. A new video control popup and fullscreen are needed. Internal hooks ready for Phase 3 time tracking are necessary.

Loading:
Spinners need to be replaced with gray wireframes.

Zero states:
When the backend returns an empty response for a query, a proper zero-state message (Icon with a small piece of text) should be shown.

Error states:
When the backend service returns an error, an error message should be shown.

Tab bar:
The tab bar should be redesigned to look nicer.

(From GitLab)

As Swish uses increasingly many services (GKE, GCS, Auth0, Redis, etc.), it's becoming more and more appealing to manage all these resources through an IaC service like Terraform.

When uploading a video through the web UI, 2 Mux assets are created and 2 content records are created. Only one is attached to the video, so the other is left dangling. This is urgent as it uses double the resource (transcoding is one of the more resource heavy tasks)

The Mobile app needs to be transitioned to the new API. This means ripping out the old service code and replacing it with the direct equivalent. Some changes will have to happen relating to the video and channel queries (they are used to query their resources instead of a dedicated endpoint like what was being done with Firebase Functions). The upload for both videos and channel art must be moved to a service container. As of right now upload code is mostly stuck in the widget directly, which is undesirable.
(From GitLab)

(From GitLab)

Focus on backend testing and backend deployment.

(From GitLab)

This depends on the application test environment being accessible by Mux

Currently, Mux does not send us transcoding completion events. We should have a webhook that responds to such events and properly updates the DB (creates/updates the content records)
(From GitLab)