Admin

Microservices

Notification scheduler / Interval manager

Inputs: Interval[]
Function: Calculate Idea:
This service keeps track of regular, but not daily activities - like gratitude journaling which may be scheduled for example every 14 days. The reason why this service is needed is that the user might not visit regularly enough to reliably allow interval calculations to be updated. In the example of the 14-day intervaled gratitude journaling, the user sets an interval configuration which is then sent to the service, which adds the intervals to a simple database and handles desired actions. CRUD methods should be in place to modify the intervals
A distinction could be made between unidirectional and birectional emissions. On one side, we have tasks, which would emit tickets that need to be "closed" by the client in order to not cause some escalation. On the other hand, simple notifications like updates or information ("Your weekly review is in, check it out!" or "New pattern noticed (p=0.001), click to read."), could just be emitted with no further action required. In the case of an important task reminder (like taking medicine), every dose should be tracked. But instead of escalating every missed day in a separate thread, they should probably be pooled like (you missed your x last doses of y). This would necessitate some kind of area code for the notifications, to join events with related origins.
(Later) There should be configurable logic to what should happen if an interval event is not "ticked off" in time. In the context of a medication tracker, it would be suitable to have an option to just skip missed doses and not compensate for missed doses. There is also the question of how to handle adjustment of preferred times of action. If I take my medicine at 18.00, but later take it at 23.00, should I (with a new 24h interval) take the next dose at 23.00 or should the intervals always be from the initial time? In most cases, the simplest case is probably the best. Like:
Medication x: 1 interval object of startTime: 18.00, interval: 24h, timeZoneAdjustment: false
On time zones: I just don't want to deal with that shit at all, but ultimately it is going to matter. One more advances, but probably necessary option is to have the intervals be absolute or relative. In most cases, the "common sense" implementation is that a 24h interval meansthat events occur at the same time every day, and not always at 24 hours apart. Take DST days. If a user wants to walk their dog at 09.00 every day, they will probably mean that

endpoints:

• intervals: Main input for defintions. Intervals are handled here.
• status: This endpoint can be used to query the status of a task, or to e.g. tick off a living ticket.
• time-zone: For relative mode, the user's time zone matters for intervals. The sveltekit hooks could probably have a check for the user's time zone and if it matches the previously known, stored in locals. If a change occurs, the notification server should be informed.

Fitbit integration manager.

Although it would be nice to offload to the client, something like 3rd party integrations is a good candidate for a separate service.