Planning Docs

[mashuDuek]

Db Setup:

1. Snake case all column names
2. I would not have a chefs table, but rather an is_chef boolean column on users table. That being said, this may change once we handle auth with Tim. You may want to check this with him.
3. ratings table should have a rating probably.
4. I would include a way to book/hire a chef. So perhaps a chef has a certain availability. And if you want to book them during non-booked times, you can book them, and that creates a booking. A booking should probably have a user that requested the booking (user_id), a chef that is trying to be booked (chef_id), could probably have start and end DateTime fields, whether is was accepted by the chef, and lastly, if you want to add a price to a booking, that may make sense.
5. Once we have bookings, the ratings should not have a chef_id, but rather should have a booking_id. So a rating pertains to a specific "booking", and through that booking you can get to the chef. Let us know if questions on this.

Backend Routes:

1. This will likely change significantly after we update the database.
2. We must include routes for bookings here as well.

Frontend Routes:

1. I'm thinking once we implement bookings it may makes sense to write the rating/review on the bookings page. Kind of like: "how was you meal with <<chef.name>>???", and you give them a review there. So this might need to happen from a bookings completion page or something like that.
2. I don't think we should add the ability to delete a chef, even from the show page. Seems unnecessarily dangerous.
3. Chefs should not be their own kind of users. They should be regular users that are also chefs. If I'm a chef, and want to hire another chef, I want to have all the abilities to do so a regular user has.

User Stories:

1. Images - this is a big thing you casually sprung there. We'd need to setup some external host for our images, like AWS.
2. Messaging system - another one you casually added there. Theres no mention of this in the database, backend, or frontend setup. This is kind of a big deal too. We're talking about 2+ tables in the database, plus websocket connection. I would scrap this feature and leave it as a super bonus.
3. Reviews - not mentioned anywhere either. If you want reviews, then I would add them along with ratings. Meaning, instead of ratings have reviews that has a star_rating (typically 1-5).
4. Favorites - Another item that is subtly mentioned but does not appear in the db, frontend, or backend. This could be a stretch feature in my eyes. This would include a favorites table to make the chef:user relationship a many to many.
5. Searching by zip code means we'll have a map? This one I like cause it'll be visually appealing.