currently the project is a bit messy and doesn't really follow flask/python best practices, so going to change that and change the corresponding docs to match the new setup

• Admins
  • Are able to see all information about users + products
  • Are able to edit user and product information
• Users
  • Are only able to see products and their own balance

So that the front-end developer in these parts (me) can actually have something to work off of. I am unfortunately not a designer. This design could also serve for other people (not me) as a good exercise in javascript.

Complete with schemas and resources. An example of these is found with the Products schema and resources.

Currently, when doing pipenv install <package> the Pipfile puts an asteriks instead of the version number. This needs to be changed as to avoid dependency issues. Research into how to limit version upgrades like in npm, where it is done with a caret (^) or comparison signs

Need to update the backend with the help of @tudurom in order to get it ready for deployment.

In case the database appears, we need to write a migration script

Properly route every documented route.

We need to pick a programming language to write the backend in. It has to be easy to use for backends (so no C), easy to learn, and popular enough to not discourage future students from touching the project.

Two very good languages would be Python and Go.

Python

Pros:

• Known by virtually anybody
• Heavily used in webdev
• Large ecosystem of everything

Cons:

• It's a scripting language
• No type safety
• So many libraries to choose from that you don't even know where to start (also a pro?)

Go

Pros:

• Very simple language
• Great tooling built in
• Generates self-contained executables
• Not a scripting language
• Has type safety
• Very popular for CLIs, container tooling (docker and friends), and network servers (see Google, Cloudflare)
• Built in HTTP library and JSON and whatever you want

Cons:

• Not as popular as python (but still very popular for doing networked applications)
• "Rigid" at times, although very debatable (the whole tfw no exceptions, you have to check with an if every error condition stuff)

Proposals for how users, products and orders should be represented in the database, basically what data we need to store.

• Research - what tech to use
• Beautification
• Initial design
• Dummy implementation with dummy data

What is needed:

• Flask setup information
• Nuxt setup information
• Extra information
  • simple instructions about database, flask-restful, models and schemas, etc
• Relevant documentation

For the time being, there is a minimal sqlite db on the repo in order to deal with users and products. Next step is to figure out where the real database is going to be.

MVP should actually have a very robust documentation on the backend. This needs to be completed after the peer reviews are over.

I'd argue against any kind of Single Page Application thing (so no routing libraries and whatnot).

To guarantee underlying simplicity for this application and low resource usage for the client, I propose doing the client "like in the good old days": make the backend server (also) serve the HTML/CSS/JS. If done correctly, you can get a very snappy application, without having to deal with routers, state management and so on. You can even make it go faster with things like Turbo (similar to Turbolinks if you dipped your toes in Ruby on Rails before).

To do list for now:

• Basic layout wireframe

• Barebones implementation of UserIndex page

• Communication with backend for UserIndex page

• Barebone implementation of Product page

• Communication with backend for Product page

• Router between the pages

• API key hiding (SSR)

Complete with Schemas and Resources.
For an example, see what the Product schemas and resources look like.

API:

• Products
  Create, read, update, delete products.
• Orders
  Place orders. Users need to be authenticated to place an order, which also
  takes money from their account (obviously). Orders should be anonymised (don't store which user bought what)?
  - Conscribo API might be useful here
• Users
  • Schema and basic API #6
  • Creating, updating and deleting only possible by admins / webshop (for moneys).
    Reading (unauthenticated) only for listing them.
• #15
  • For users, to buy stuff.
    Once authenticated, a user may see all their details.
  • For the webshop, to put money.
  • For admins, to have full access.
• #19

I will later add issues / PRs next to the items of concern.