patricianapp / patrician-api

The GraphQL API for interacting with the Patrician database

docker-compose exec -u postgres postgres psql \l \c \dt

patrician-api's Issues

Dockerize

Acceptance Criteria

• Dockerfile is created for our API using node:13 as the base image
• API is added to docker-compose file and routed to use Docker Postgres
• Maybe: eliminate external routing for Postgres container? (So that it's only used by the app and not exposed outside Docker)

Upon adding new album, clean artist/album name using metadata-filter

Dependencies

• #1 Authenticated CRUD for user collections
• metadata-filter

Acceptance Criteria

• The artist and album name, when passed in to the addToCollection mutation, should be cleaned using metadata-filter (for now, probably use getAmazonFilter)
• Include an opt-out option as an argument for this mutation

Pagination

Right now the query resolvers return all items in the db. We want paginated results, ideally using Relay specification.

Warthog plans to have a feature for this so we might wait until that is finalized.

ESLint/Prettier

Implement ESLint, Prettier, and pre-commit hooks for both.

Adding Items To Collection

Users should be able to:

• add items manually by artist and title
• add items manually by MBID
• add additional metadata in the creation payload (release date, etc)

The server should automatically:

• fetch metadata from MusicBrainz, either using MBID or by searching artist/title
• merge items that are the same
• follow every step in the chart below upon adding an item

This import function below is what will handle user imports, Spotify/Last.fm/RYM imports, and any other method of adding items.

Start writing and configuring tests

• Set up ts-jest with npm commands
• Pre-commit hooks
• Have tests written for all current functionality

Import Page (A): Last.fm/Spotify

The first iteration of our import page will allow manual imports from Last.fm and Spotify, since these two are the most important.

• Continuous imports will probably come at a later date.
• Adding the items to our database will be handled using the existing API function

To be created:

• UI page that authenticates the user, kicks off the Lambda functions below, and displays the collection queue
• Last.fm import Lambda function that fetches scrobble history and adds items to collection queue
• Spotify import Lambda function that fetches saved albums and adds them to collection queue

To be updated:

• Collection database needs to have "queue" functionality and store all of the fields that we want to display during this process (e.g. import source, Last.fm plays, etc)

Authenticated CRUD for user collections

Dependencies

• login mutation (#6)

Acceptance Criteria

• Get the basic authChecker working (from Warthog example)
• CRUD queries/mutations for signed-in user ("me" resolver)
• Parse JWT inside Server context function

Log in

Acceptance Criteria

• New login mutation has been created
• Returns some sort of auth token that can be used for future requests

Make "username" field the ID instead of using Warthog's autogenerated ID

Notes

• May have something to do with this getId() function in Warthog's basemodel

Acceptance Criteria

• user.ID field has been replaced everywhere with user.username as primary key

Import by ID

We have a searchByIdentifiers() function in "item.service.ts" that searches for a single item by mbid, artist and title, which is used to check if an item already exists in the database before adding to a user's collection.

We simply need to add an "id" parameter which will also search the item's ID, and then update the addItems() function to add the id into the searchInput if it exists.

If MBID is present, fetch metadata

Reviewing Items

Acceptance Criteria

• Add review to item
  • Includes rating, title
• See review on item page
• Review history: New reviews get added on top of old ones
  • Can only be viewed by the logged in user
• Can undo changes based on review history
• Limit how much history is saved (e.g. 50 reviews)
• Can delete review (this is permanent and deletes all history)
• Draft review (sets visibility to false)
• Integrate text editor plugin (Slate, Draft, etc)
  • Should save to database in Markdown or HTML format

Heroku Deployment

Automatically deploy to Heroku on all non-canary releases (x.x.x)

Create issue templates

Artist and album name properties available directly on collectionItem (instead of collectionItem.itemDetails)

We should be able to run this query:

query {
  user(where: {id: "userId"}) {
    collection {
      artist
      albumName
    }
  }
}

Right now, this information requires an extra layer:

query {
  user(where: {id: "userId"}) {
    collection {
      itemDetails {
        artist
        albumName
      }
    }
  }
}

Searching through collections

UI Features

• A new search query is sent with each letter typed, and the collection view auto-updates
  • (as long as the query is valid)
• You can filter items using the query syntax
• Filters are automatically syntax-highlighted
• There will also be a "Filters" expansion panel to set these through the UI
• "Sort by" dropdown: Artist A-Z, Plays, Rating
• Advanced: Each search query should not be grabbing full item info, just the IDs (since some item info will already be in browser session, and this will allow for smoother performance)

Query syntax (WIP)

Example queries

Searching for a specific album:

my bloody valentine loveless
artist:'my bloody valentine' loveless
artistId:'my-bloody-valentine-ir1' loveless
id:'my-bloody-valentine-loveless'

Browsing:

artist:'mastodon' released-before:2009 genre:'sludge metal'
list:'nostalgic-albums' tag:heavy rating-gt:8 has:review
added-in:2020 plays-gt:50

Comparing collections:

in:user/afantano 
in:user/afantano/loved-list     # This is a view within a user's collection

Seeing your play stats (note: you can sort by plays in the dropdown menu):

plays-gt:400
plays-after:2020-01-01 plays-before:2021-01-01   # Only count plays in 2020
plays-in:2020    # Same as above

Identifiers

(These are filters that can only return one or zero items, so all other filters will be ignored)

id:
mbid:
rymId:
spotifyId:

Basic

[date-qualifier] = before/after/in: (YYY0s, YYYY, YYYY-MM, YYYY-MM-DD), on: (YYYY-MM-DD)

"gt" and "lt" will probably equate to "greater/less than or equal to" instead of "greater/less than", because this is probably the more common use case

added-[date-qualifier]:
artist:
artistId:
first-listened-[date-qualifier]:
folder:
genre:
has:artist-review
has:favorite-tracks
has:likes-dislikes
has:review
in:wishlist
last-listened-[date-qualifier]:
list:
plays-gt:
plays-lt:
rating:
rating-gt:
rating-lt:
released-[date-qualifier]:
tag:
updated-[date-qualifier]:

Advanced

[custom-field]: Any custom field that the user has created, along with any valid value.
in: (user/[user] or user/[user]/[view]) Whether the item also exists in another user's collection
get:artists/items/tracks Which type of result should be returned (default: items)
plays-[before/after]: This can be used to create a date range for plays, similar to Last.fm's functionality. (This will not be possible until we are storing play/scrobble data which is way in the future)
view:[view] Whether the item exists in a view (which is basically a saved filter query)

CollectionItem primary key should be its relations (item and user)

Right now its primary key (as with all data models that implement Warthog's BaseModel) is an autogenerated ID. We want the primary key to instead be the item and user that the CollectionItem is connected to, because 1) the combination of these is unique, and 2) we want to be able to easily and quickly fetch these CollectionItems by their item and user IDs.

Use dataloader to return optional fields (e.g. `mbid`)

https://github.com/patricianapp/patrician-api/blob/master/src/modules/collection-item/collection-item.resolver.ts#L51

Not super important, since we can already access this using itemDetails, but it would be nice.