Skip to content

Construct a proper server schema #5

Description

@edwardshturman

What

Right now, the Server schema we maintain with MongoDB is reliable...enough. We have yet to use types (#4) and that definitely extends to the database schema. (This is not good practice....) The focus of this issue is threefold:

  • Finish our early model of what the server schema looks like: what does the config object look like? How will we handle migrations?
  • Should we consider a different database paradigm and service provider? Relational → Postgres → Supabase?
  • Implement types for our schema, such as via Prisma.

Why

As discussed in #4, types are a safe long-term strategy for interacting with APIs, and that includes our own. Additionally, we'll almost certainly have to change the structure down the line, especially when making a new feature set. We ought to have a plan in place for that.

How

  • Consider alternative database paradigms and service providers

This'll be updated from there....

Metadata

Metadata

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions