Giter VIP home page Giter VIP logo

catalog's Introduction

catalog

A full-stack SaaS application for the music industry, to help individual artists and labels manage their releases.

Built with Next.JS, TypeScript, Prisma and PostgreSQL.

Frontend

Docs to be completed.

API

Docs to be completed.

Data Model

At a glance, pretty comprehensive information can be found about the data model by inspecting the Prisma schema for information about each data model.

Limitations

Due to limitations in the Prisma schema, we cannot currently support polymorphic associations nor table inheritance in the data model. This means certain product concepts, like generic 'tasks' for releases, are currently implemented using a single table, with foreign keys for task-type-specific data. This wil likely change in a future version in-case Prisma supports polymorphic associations or table inheritance.

JSON fields

Continuing on with the Prisma schema, we can see that the data model contains a few fields that are not natively supported by Prisma. These are JSON fields, which are stored as strings in the database, but are parsed into JSON objects when queried. Though we lose the DB's type system and type support in our Prisma schema, it is the only way we can scalably represent certain data shapes.

Activity on Release Tasks

When a release task is being completed, users will update the status of the task, they may write some notes, managers may comment, assignees may be updated, etc. As a key feature, we want to support differential data like in GitHub issues, where users can write notes, and managers can comment, but most importantly, we can see what changed, and who changed it, for each item of activity.

We can easily capture the type of activity occuring using a Prisma enum, but the data itself representing each change would have to be stored in separate tables with foreign keys in order to store it in the database. This is not great, and won't scale.

This is why the payloads for each activity are stored as JSON strings in the database. This allows us to store the data in a single table, and parse it when queried.

Here are the shape of the JSON payloads for each activity's extra data:

// TaskEventType.TASK_CREATED
extraData: {
}

// TaskEventType.NEW_COMMENT
extraData: {
  newComment: string; // The comment text as a Markdown string
}

// TaskEventType.UPDATE_COMMENT
extraData: {
  commentId: string; // The ID of the comment being updated
  newComment: string; // The new comment text as a Markdown string
}

// TaskEventType.DELETE_COMMENT
extraData: {
  user: string; // The user who commented originally
}

// TaskEventType.UPDATE_ASSIGNEES
extraData: {
  oldAssignees: string[]; // The IDs of the previous assignees
  newAssignees: string[]; // The IDs of the new assignees
}

// TaskEventType.UPDATE_STATUS
extraData: {
  oldStatus: TaskStatus; // The IDs of the previous assignees
  newStatus: TaskStatus; // The IDs of the new assignees
}

// TaskEventType.UPDATE_DATE
extraData: {
  oldDueDate: string // ISO timestamp of the previous date
  newDueDate: string // ISO timestamp of the new date
}

// TaskEventType.UPDATE_NAME
extraData: {
  oldName: string // ISO timestamp of the previous date
  newName: string // ISO timestamp of the new date
}

Environments

Environment info is stored in a private gist, here.

catalog's People

Contributors

sebastiancarroll avatar tpjnorton avatar

Watchers

 avatar  avatar

catalog's Issues

Notifications

Support for notifications in UI for users to manage.

Integrate with reminder job to create notifications once a day.

Only support tasks becoming overdue for now.

Bugs & Feedback From JP

Messages

Did some first tests
work wells
in de pdf some bugs I found.
It might need some more features for me personally before I would use it. Compared to the other tools i'm using right now.
maybe more segments or task possibilities within the release part.

Bugs

PDF with screencaps

Suggestions and features

Invite User

Proposed flow:

  1. Admin sends invite from UI
  2. User clicks link in email
  3. If not signed in, sign in and then come back to verify page
  4. If not a match / invalid / etc, sign out and show error
  5. If a match, redirect to home and show success toast

Task Reminders

Blocked by #19 and optionally #20

We need a concrete way to remind users when their tasks are about to become overdue.

Could be TZ sensitive.

Proper Prisma Error Handling

Right now, we handle most of our errors by raising proper exceptions to return the correct error code over the wire.

However, we don't catch Prisma errors appropriately.

We need to determine a good way to catch these errors at scale (without API routes growing out of control).

Design & Build Marketing Site

We need to design a marketing site for our product, and implement the technical side to go from "hey I landed here" to "hey I'm a customer on the pro trial".

Release-Level Permissions

Could invite users to view/edit something?

Use case: Want to involve external contact with one item of release schedule, but not give them team membership of any kind.

Could add FK to release / task table as 'viewers' and one for 'editors' maybe? (keeps permissions out of it and is explicit) OR

Could have ExtraAccess table associated with release / task with an email and some permissions.

Onboarding

As per some studies done on here, it'd be great to get some onboarding stuff into place for users.

This isn't super necessary for LA1, but reduces the amount of pain early adopters will have getting on the platform.

Also did a UX study into Loom's onboarding (as they have a similar slant to us) and some new things should be doable.

We should do two things:

Add a new user screen (for setting workspace name initially and stuff)
Include a popover for onboarding like this:

image

Not sure exactly what to put but ideally all of this could be solved with as little extra db data as possible.

Creating an artist? (easy! artists > 0)
Creating a release? (can't do it without an artist!)
Adding team info? Should be done at welcome screen, else check for updated at later than created at.
Adding some tasks? Should be possible to see with a quick release query.

Ideally we could add some more state or something here to ensure once this journey has been completed, we don't show this again.

404 Pages, Error States, Retries & More

Currently there isn't much we do on the frontend to react to errors like 404 when we receive them for the primary data-fetching method for a page, such as /tasks/[task_id].

I'm thinking there's gotta be a way to make some of those tasks pre-fetch on the server.

The initial setup for Server-Side queries was done according to the guide, but there currently aren't any queries being made server-side explicitly.

On top of that, we need something other than the default pages for 404 / 500 / etc.

Stripe Integration & Webhooks

We need a basic implementation of Stripe's webhooks etc and integrate that with plans to start collecting payments from users.

Integrations, Integrations, Integrations

Explore integrations to build into product. Baseline view here is that it's not useful for teams unless we can integrate it with stuff people already have.

Calendars

  • Google Calendar
  • O365 Calendar
  • Notion?

General Connections

  • Slack (Channel per release, task updates go in there?)
  • Email (baseline)
  • Spotify (for stats on artists / releases?)
  • Distributors (if they have an API)
  • Some kind of invoicing stuff?

Basic User Documentation

Maybe could hire a tech writer for some of this?

We need a basic documentation site for users. Could be rolled into this Next.js app and statically rendered?

Create Release From Plan(s), Custom Release Plans, Etc.

Right now, we have a wizard-style data-entry experience for entering release information. This works great for entering data about a release we've already started planning, have dates for, or are backfilling.

We should design an experience focused around what was discussed here, for new releases.

This way it can be super low-touch:

As a user, I want to enter my release's target date and basic info, and pre-fill all the sub tasks and generate the summary page according to a plan, while letting me change each of the dates in the plan, and having all the others update relative to release.

As a user, I would like to be able to select from several plans when coming up with a new release.

As a user, I would like to be able to make my own plans, to re-use for subsequent releases.

LA 1 ๐Ÿž ๐Ÿ› Bug Hunt ๐Ÿ› ๐Ÿž

Gonna take a swing at cracking some UI bugs.

  • Client Error on Tasks Page
  • Bad summary data rendering on new Release Wizard
  • Can't access Notifications popover on mobile at all
  • Various Mobile issues
  • The team logo by default in the manage team page doesn't match the default Avatar.
  • 'View in planner' in the release card doesn't work
  • Flashing outline on the Account Switcher Button
  • #61
  • Looking at a release in the planner makes no sense (Task-type view?)
  • Z-Index issues on Popovers

Overloading DB connections on Heroku

Heroku doesn't support connection pooling for free -> we should move to DigitalOcean, which gives us pgbouncer.

Basically as soon as we start connecting to postgres we're overloading the connection limit.

Customer Support

Although #17 would be a start for this, as soon as people are paying for our product we need to offer them bare-minimum support.

Possible pro-active solutions:

  • Sentry (to capture exceptions as they happen)
  • Intercom (so users can message us directly)
  • Freshdesk (for more structured support, though this likely won't be necessary initially)

We need at least something in place, it's not good enough to be ad-hoc with paying customers.

Limit DB Usage Based on Plan

Kind of a coda to #100.

Right now all plans have access to all features.

However there are some features that will create very large numbers of database rows (release task events, for example), that won't be visible to some product tiers anyway, creating bloat for us and $$$ spent on infra for no reason.

Our goal right now is not to upsell free-tier users (much) to the mgr plan as they likely as artists won't be able to buy the product.

So any features that are "off" for the free plan should not exist in the database.

Preliminary List

  • Release Task Events (comments, etc)
  • Audit Log-type stuff
  • Default Contact Labels for a workspace ? not too bad, like 20 rows per workspace at most

As we grow there'll likely be more stuff we need to manage here, but we just need to make sure we do this.

We really don't want 20M rows of data nobody is likely to see.

Contacts

Basic contact mgmt API, reserved for teams, bound to a team, and a table UI for managing them. Allow tasks to be "assigned" to a contact, e.g. outsourced.

Data model for contacts:

  • name
  • email
  • telephone
  • website
  • notes? - info about them, whether they did a good job or not
  • tags / type / skills / something(producer, mastering, photographer, social media mgr) etc.

Keen to get some feedback here!

Deliver Notifications By Email

When a notification is generated, it should be possible to deliver it by email too. Users should be able to disable this.

Audit Log

Update the actions on the db to also add an entry to the audit log table
Update the UI to collect the relevant logs for that team and display

Test Approach

We need to come up with a solid way of testing our system.

Do we use a test database and go e2e straight away?

Or do we test API and FE separately for now?

Analytics

Both in-app and on marketing site - will become extremely important as we get spending on ads to figure out why we aren't converting.

Possible sources:

  • Hotjar
  • Google Analytics
  • Segment
  • Heap

SEO Review

Tasks

  • Make sure OpenGraph stuff works
  • Canonical URLs
  • Add a sitemap
  • Check LIghthouse scores

Allow Email Sign-in

Means we need an extra onboarding step, but other than that doesn't change much!

We'll have a new email template, and some new onboarding logic.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.