Open theawesomew opened 1 year ago
Are we not going with some sort of SQL database? That seems to be standard practice for this kinda stuff, and would make it easier to implement things like sold out items and quickly adding new items. (Also, are we going with an MVC architecture or what?)
This issue wasn't for storing purchase data - we can't write to JSON files from the client-side anyway. This was for creating a (potentially) useful abstraction for storing what products exist on the site. For examples we could have something like...
{
"products": [
{
"name": "Hoodie",
"description": "describing things",
"colours": ["black", "blue"],
"price": 20.00,
}
]
}
etc. And it meant that you don't have to create a new element in Co-op Soc shop if we add/remove items - you can just add the data to a JSON file and it will be reflected in the generated Next.js code.
However, talking about using or not using a database, using SOME kind of database is non-negotiable in my mind. I'm tempted by using Google Sheets purely because the API is surprisingly powerful and it's very easy to share the information with the rest of the executives/society. However, using something like SQLite or MongoDB makes plenty of sense too (not a fan of using SQL Server, PostgreSQL, or Oracle because they're too 'heavy' for want of a better word).
Oops! I retract my statement about SQLite - apparently it does connection locking which makes it really inapposite for this application. MySQL may be a better idea on this one!
This is probably a sensible abstraction for what items are in the store but, we might hardcode it?