Repository Evolution

[briosheje]

Proposal and ideas about further evolutions:

1) Project and Repository Name. Project and repository name should become "EnhancedTodo" 2) Multiple backends The application may rely on multiple backend implementing the same feature. 3) New features The application may follow this roadmap:

• Milestone 1.0.0
  • Authentication System.
  • Todos by category.
  • PWA instead of SPA.
• Milestone 1.1.0
  • Authentication System: User Groups.
  • Enhanced Todo data: images.
• Milestone 1.2.0
  • Enhanced Todo data: audio and videos.
• Milestone 1.3.0
  • PUSH notifications.

[Attersson]

For milestone 1.0.0 : Backend specifics will require more details. Without usergroups yet, but with authentication already implemented, shall we:

• keep todos shared like they are now, but only allow access and CRUD to logged users?

or

• every user, by logging, accesses a personal todo list

or even

• agnostic front end, merely cares about communication and backend will decide.

[Attersson]

For milestone 1.1.0 it is yet to be defined what usergroups do. I find more flexible for instance to have a list of permissions per single "todo category". Which might be better queried otherwise. Whenm a user logs in, they shall have access to their todos (in their categories) as well as todo categories they are invited to (different owners). Maybe every invite has a token and this token is checked at API time. Emitting an invite (user John invited user Tom to category JohnTodos) will generate a token and provide this token to the recipient... so every account has a personal list of tokens and then at runtime the requests will succeed if these tokens match with the owner tokens. How about this?

Or else how could usergroups work?

[Attersson]

Note about loss of update: APIs for Edit operations should include old and new description, to detect changes (or deletes) since last read.

Separating Edit from Save-New might be advisable.