As of right now, the feed is just a list of the latest audios uploaded by the user's following artists. This is fine for now, but isn't as modular if we want to add more entities to the feed (like favorites, collections, etc.)

Right now, the information for audio includes: title, description, file size, duration, and tags.

Maybe we could add more information, like licensing, stem downloads, etc.

It may not be an issue right now, but eventually the application will have services that would really make sense if they were decoupled from the API service (feed, notification, identity, etc.)

The progress bar was acting weird (you cannot change the slider, onChangeStart function was not calling, and onChangeEnd was calling twice). There are currently issues regarding this, and the team is aware of the issues.

chakra-ui/chakra-ui#3919

chakra-ui/chakra-ui#3860

So I decided for now to just use RC-Slider as a replacement. However, I do want to use the Chakra UI's slider component so I could utilize their component style props.

So I am creating this issue to remind myself to do so.

As of right now, I created a service that would cleanup the audios that are unpublished for a day. Now I want to use that service on a scheduled job that runs everyday. I need to look more into this. I am thinking about using Hangfire for scheduled jobs.

As of right now, the backend tests are very messy, especially the integration tests. I want to look into it more and see where I could optimize it. Here are some thoughts:

• Create a AudioTestBuilder to build an audio for tests. I do not want to keep on adding methods in the builder for tests on the original Audio Builder.
• Rework the SliceFixture. A lot of tests requires getting services from the dependency injection container.
• Rework some of the tests. Some of the tests is just messy to look at. I kinda made it very quickly and didn't really think about it. Some of the tests now don't even work.

Dashboard will be a page where users can easily manage their uploaded audios or created playlists.

Although tests can be done by using Postman or Swagger, adding more unit and integration tests would be very useful (and good for my skills :D )

Right now, when a user clicks on a tag in the Audio details page, it will redirect them to the search page with the specified tag applied; however, no audios displayed. This is actually an expected feature, since audios will not be searched until a search query is applied, which it wasn't when clicking on a tag.

A simpler solution is to create another page where we filter the audios by tag.

For instance: /audios?tag=test

With an application that focuses on following your favorite artists and listening to some of your favorite tunes, a notification feature where you get notified when your favorite artist uploads a new audio, or someone likes your song.

This can be done with the current technology we have, but it would be synchronous, which is not ideal. So with this feature, we need to introduce a message broker that can sends messages to different services (like the notification service) to notify users and such.

Right now, the app is using token authentication. This is fine, but it is hard to maintain and secure. Going to try and implement cookie authentication in the backend.

As much as I enjoy not having to implement my own identity for this app, there are some things in AspNetCore identity I do not like, like having to pass in the whole user object for some of the user manager method. This means having to fetch all the user fields, when you just want to check if the password is valid.

I am probably ranting... but I may just suck it up... or implement my own... or use some third party

GraphQL has some appealing advantages over REST, such as having one endpoint and the lack of overfetching/underfetching.

GraphQL will be great for querying data for various sections of the UI, without having to make a bunch of REST endpoints, or wasting data from the response.

Have a way to display audio waveform on the page and/or audio player, or even on each list item.

Right now, a solution is to do all the calculations on the client side (using a library like Wavesurfer.js) because the calculation can be costly to performance.

My plan is to have some sort of worker where it listens to audio uploaded into the cloud storage, downloads the audio, and calculate the waveforms, then upload the waveform data into a separate storage.

Right now the audio player is very buggy. I may want to use a different audio player library, or create my own.

The current one is very hard to use for my use case.

This issue provides visibility into Renovate updates and their statuses. Learn more

This repository currently has no open or pending branches.

• Check this box to trigger a request for Renovate to run again on this repository

Right now, the frontend is barebones and I want to add some brand theming to the app. I also want to make it mobile responsive.

Right now, when the user is authenticated using their email/username and password, the client will receive a access token and a refresh token. The access token is used to access the (protected) API, while the refresh token is used to refresh the access token, since it is short-lived. On the client (web app) side, whenever a request receives a 401 error, the app will call the refresh access token endpoint using the refresh token to get a new access token, along with a new refresh token.

This is somewhat similar to OAuth2, but not quite, and I want to implement OpenID and OAuth2 into the API, since it is the open standard for authentication and authorization.

The frontend UI right now is okay, but it could be better, and more responsive....

TBA

Have a service that pulls a list of audios based on various parameters. This recommendation service will be useful for when a user views a track and can see possible tracks where the user might be interested in.

Use redis (using docker) to create a caching server for queries.

I see two ways of handling caching (so far)

1. Use a caching mechanism that has an expiration date. Whenever the expiration date expired for a cache, the cache becomes invalid. When requesting a query, and a cache is invalid, then we will go to the database to get query, and then cache the new query.
2. Whenever we are reading data, we get it from the cache server. Whenever we are writing data, we want to write to the cache server and the database. My only question is that what is the point of a database if we are reading and writing from cache.

Playlists

Users can create a playlist of uploaded audio.

Feedback

I want to implement a feature where users can send feedback on an audio to the user. The user can determine if that feedback is useful. I want the feedbacks to only be seen by the author since it is valuable to them and nobody else.

Featured Audios

This is a listing of audio that will be featured in the frontpage of the site. The listing is determine by the trending popularity, and whether the author of the audio have numerous amounts of HELPFUL feedback.