Decide on the data schema

[0916dhkim]

We already have a draft here

Finalize db schema

Determine API request & response shapes.

[Jenna59]

@0916dhkim for finalize db schema, is it that you want me to go ahead in Postgres and start creating the tables? And for API request and response shapes, would it be something like what's in this doc: https://docs.beeswax.com/docs/api-requests-and-responses. Like, determine where we would need a message, an error message, etc? I'm familiar with res, req, next, I've just never heard the term request & response shapes. Would it be this: https://www.prisma.io/docs/concepts/components/prisma-schema? Thanks!

[Jenna59]

This is why I said I needed to read the docs! lol

[0916dhkim]

@Jenna59 About db schema, we don't need to create actual tables or write code at this point. Just an ERD or a written equivalent. What we have in the google doc looks sufficient tbh. We just need to add/remove some fields to match our wireframe.

By request & response shapes, I meant API specification. OpenAPI spec is most widely used (documentation), but we don't need to be super formal at this point. Any format is okay as long as we know the shape of the data we pass into the API request, and the shape of the data that is returned as the API response.

[0916dhkim]

The idea is to unblock people for UI & API implementation tasks. They need to know what kind of data they are dealing with before writing their code.

[Jenna59]

@0916dhkim do you want to take a look at this? https://www.figma.com/file/djA9GMoQoOJBSDaJZdWdDJ/Untitled?type=whiteboard&node-id=0-1&t=xLC7J5Jj5wWmGNu4-0

[0916dhkim]

@Jenna59 Looking great! I'll go through the comments today. In general, I think we should be able to remove the fields that are not immediately needed.

[0916dhkim]

I reviewed the figma file 👍

• There are some fields/tables we can remove for now. I think it will be simpler to start with a smaller schema.
• I think table names should be singular, following Prisma's naming convention.

[Jenna59]

@0916dhkim done. I was doing a SQL schema, hence the VARCHAR, etc. I think the last time I worked with SQL, I used Microsoft SQL server because the school had a deal with Microsoft. Postgres would be the actual db schema, no? And then Prisma would be the model and can do the introspective type mapping.

[Jenna59]

@0916dhkim also, I thought I asked you about this on Discord, but maybe I didn't or it got lost in the maelstrom. For the API schema shapes, are you looking to have those done in JSON? Or more of a use Figma/Google docs kind of thing? Is it kind of like dummy data where I write the .json file and then we go back and make changes when/if needed?

[0916dhkim]

@Jenna59 Awesome, I think we can remove "EVENT REGISTRATION COMPLETED" field from the user table and mark this issue as completed.

About Prisma, there are generally two ways to manage schema, depends on what we use as the source of truth.

1. Using schema.prisma file (doc). In this case, the source of truth is the schema.prisma file written in Prisma Schema Language. Prisma applies the schema to database through prisma migrate deploy command. To change the schema, we need to edit the schema.prisma file and deploy.
2. Using introspection (doc). The database is the source of truth. Prisma generates data models from existing database through prisma db pull command. To change the schema, we need to run SQL migration on the database and run prisma db pull.

I prefer using the first approach because it fits well with a CI/CD pipeline. We can run prisma migrate deploy in CI script. On the other hand, it will be a little unclear when to run prisma db pull if we use introspection.

[0916dhkim]

are you looking to have those done in JSON? Or More of a use Figma/Google docs kind of thing?

@Jenna59 You can post example JSONs in this issue :+1:

[Jenna59]

are you looking to have those done in JSON? Or More of a use Figma/Google docs kind of thing?

Cool. I'll probably do it tomorrow morning. I've been trying to take it a bit easier and recalibrate this weekend. I'll have stuff for you by Stand Up on Monday, for sure.

[0916dhkim]

Sounds good!

[Jenna59]

@0916dhkim Hi Danny, I'm not sure how to get the parse error on line 38 to go away. Tried everything I could think of. Also, do we need the EventType table? Or was that subsumed under events? Not sure if I put the right urls or did the content part right. Also for the routes, I just left them as "event" and "user" because idk what the FE wants to build out. We could presumably modify them to "eventcreate", "eventdelete", etc. I made everything arrays of strings.

api-structure.json.zip

[Jenna59]

^ or was I supposed to list the type of every piece of data in the table?

[0916dhkim]

@Jenna59

• I think the error happens because .json file only expects 1 object in it. It is an invalid syntax to list multiple objects in a single json file. You can just copy-paste the whole JSON as a text in this thread.
• Yes, we need an EventType table because we need to be able to create/delete event types on demand. Can't do it if it is a string field under Event table. We can flatten it when we return data from API endpoint tho. DB schema doesn't need to 100% match the response shape.
• If we want to go with OpenAPI specs, we should make the schema more specific. But I'm okay with just using dummy data as I said before.

OpenAPI schema example:

"schema": {
  "type": "array",
    "items": {
      "type": "object",
      "properties": {
        "id": { "type": "string" },
        "type": { "type": "string" },
        "ideaConfirmed": { "type": "boolean" },
        "volunteersNeeded": { "type": "integer" },
        ...
      }
    }
}

Dummy data example:

{
  "id": "abcdefg",
  "type": "In-Person Social",
  "ideaConfirmed": false,
  "volunteersNeeded": 5,
  ...
}

[Jenna59]

yeah, I kind of thought that was the JSON issue, but I also didn't want to dump a huge JSON file into the GitHub thread.

[0916dhkim]

@Jenna59 Right, it can be huge. You can open a PR to share the JSON files. It is actually quite common to use PRs to share ideas without an intention to merge. It becomes easier for everyone to view the files and comment on specific parts.

[Jenna59]

@0916dhkim plz see PR request #34. Also, let me know if db tables need to be created before work is done on APIs. The FE team was wondering what to work on next during stand-up.

[0916dhkim]

@Jenna59 Let's have frontend team review the PR and provide feedback on if the response has everything they need to render the page.

And yes, we need to write prisma.schema file before we can start working on the API implementation.