shetaye/swish

A human-first video platform.

👋

Interesting Projects

🧮 Omega CPU 2015 - 2018

The Omega CPU was my first major project. It is a 32-bit RISC processor with a custom instruction set and assembly language written in VHDL and deployed on a Xilinx Spartan-6 FPGA. I developed it with the assistance of mentors at the Bakken museum.

🕊 Athena 2018 - 2021

Athena is a proof-of-concept Discord bot that moderates servers through direct democracy. It was developed on and off from 2018 to 2021, and is the third iteration in the project (the other two being DDD and Direkt). Athena (then called DDD) was at first a chat-only service which moved to a web platform (like mee6). It is written using Vue, Node.JS, SQL and Discord.JS.

Other things I've worked on

🦾 FRC Robot 2020 - 2022

I particpated in my Highschool's FRC robotics team, Team BJORG. I contributed to the 2020 robot as a software developer and the 2022 robot as control systems lead. All of our code is on GitHub. The robot is programmed in Java and was an exercise in repository management considering the number of active developers we had.

swish's Issues

Transition Mobile App to New API

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)

Standardize Editor Configuration

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)

Write Error Handling

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)

Add Support for Channel Icons

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)

Create Seperate Dev and Prod environments

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)

Write createChannel Unit Test in ChannelDataService

(From GitLab)

Videos will not play

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

Write getChannel Unit Test in ChannelDataService

(From GitLab)

Write queryVideo Unit Test in VideoDataService

(From GitLab)

No channels are shown in channel tab

No channels are shown in the channel tab.

Content Is Cloned

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)

Move CI/CD to Github Actions

Focus on backend testing and backend deployment.

Implement updateChannel in ChannelDataService

(From GitLab)

Add watch time to mobile app

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

Write Unit Test for createVideo in VideoDataService

(From GitLab)

Write Unit Test for uploadVideo in VideoContentService

(From GitLab)

Implement deleteVideo in VideoContentService

(From GitLab)

Write queryChannel Unit Test in ChannelDataService

(From GitLab)

Add SEO to Web App

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.

Write Unit Test for uploadIcon

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

Use a Secret Management solution

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)

Video.content is null after uploading video

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

Implement deleteChannel in ChannelDataService

(From GitLab)

Switch GKE deployment to Workload Identity

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.

Write Unit Test for getVideo in VideoContentService

(From GitLab)

Handle Mux Callback

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)

Add Resource Limits

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)

Write Tests for Mux Handlers

(From GitLab)

Prevent unlimited uploads on one video

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.

Add GA Support

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

Standardize Unit Test Configuration

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)

Transition to Terraform

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.

Full API Integration Test

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)

Write CI/CD Pipeline

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

Implement Auth

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)

Add Tracing

Add code tracing with Stackdriver to improve visibility of performance.

https://opentelemetry.io/

Implement SearchService

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

Write Tests for Errors

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)

Fix Random Webapp 401s

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.

Add log out button

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

Cleanup Documentation

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)

Touchup Mobile UI

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)

Adopt Git Flow

Useful diagram: