zpi-2023 / sensobackend Goto Github PK

• creating alerts (with different types)
• displaying alert history for a senior

We need API versioning to ensure we can later make breaking changes without major problems.
Useful links:

• https://github.com/dotnet/aspnet-api-versioning
• https://blog.christian-schou.dk/how-to-use-api-versioning-in-net-core-web-api
• https://www.youtube.com/watch?v=8Asq7ymF1R8
• https://www.youtube.com/watch?v=iVHtKG0eU_s

Blocked by:

• #15
• #21

POST /api/v1/account/profiles/senior

• no payload
• response:
  • 204 No Content and creates a senior profile if this account doesn't have it already
  • 409 Conflict if this account already has a senior profile

GET /api/v1/account/profiles/senior - used to display QR code as a senior

• no payload
• response:
  • 200 OK with { "encodedSeniorId": string } if this account has a senior profile, this response should be encoded the same way as POST /api/v1/account/profiles/caretaker
  • 404 Not Found if this account doesn't have a senior profile

POST /api/v1/account/profiles/caretaker - called after scanning a senior's QR code

• payload: { "encodedSeniorId": string, "seniorAlias": string } - account ID of senior which you want to pair with, encoded with a symmetric algorithm and a secret key
• response:
  • 204 No Content and creates the caretaker profile if the encodedSeniorId matches an existing senior in the DB
  • 403 Forbidden if the encodedSeniorId is invalid

NOTE: GET /api/v1/account/profiles/caretaker should not exist, since we always pair starting with senior for safety/security reasons

See full medication specification here: https://github.com/zpi-2023/thesis/issues/25

• https://github.com/zpi-2023/SensoBackend/pull/57/files#r1385219474 - refactor SeniorIdRepo
• SeniorIdRepo tests
• Tests for HasPermission middleware
• Tests for handlers
• Change DateTime to DateTimeOffset for SeniorDataToEncode

• Embed database diagrams

https://www.youtube.com/watch?v=PlbAuNvR16s&fbclid=IwAR3KWXLY1Fx5ogDlIX_Fyqo1Isglo1kUkne8PJAB6ogTW16Yo964COCfzO8

Discovered during #20.

The tests using Moq are pretty ugly, don't interplay with FluentAssertions and require a lot of boilerplate. Check if NSubstitute would be any better.

Tests, code formatter, artifacts?

• https://devblogs.microsoft.com/dotnet/announcing-dotnet-8/
• https://devblogs.microsoft.com/dotnet/announcing-csharp-12/

Kind of blocked by https://github.com/zpi-2023/thesis/issues/24, which will decide which tables are up to deletion.

We can use for example: Husky.Net
We should have rule that does not allow to commit to main
and to commit only correctly formatted code by csharpier

GET /api/v1/dashboard/:seniorId
PUT /api/v1/dashboard/:seniorId

Example response (up to consideration):

{
  "gadgets": ["games", "medication"]
}

• Backend uses account ID from token combined with seniorId from path to determine the correct dashboard.
• Get and update should be supported.
• Many forms of data storage should be considered: Postgres JSON blob, Postgres array type, 3NF3.
• There should be some validation in place, for example regarding the maximum length.

Helpful links:

• https://www.youtube.com/watch?v=YzOBrVlthMk
• https://www.youtube.com/watch?v=Ve__md8LeDY
• https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs
• https://mikolaj-kaminski.com/elegant-command-query-validation-mediatr-fluentvalidation
• https://mbarkt3sto.hashnode.dev/aspnet-core-how-to-use-fluent-validation-with-cqrs-mediatr
• https://code-maze.com/cqrs-mediatr-fluentvalidation
• https://codeopinion.com/thin-controllers-cqrs-mediatr
• https://www.youtube.com/watch?v=o9ON9nbJc3k
• https://www.youtube.com/watch?v=yozD5Tnd8nw

Tasks:

• Add a mediator design pattern library (for example MediatR).
• Add a validator library (for example FluentValidation).
• Maybe add logs on all requests?
• Setup CQRS pattern with thin controllers.
• Setup error handling (this should be protocol-agnostic, and generic errors should only be mapped to HTTP-specific errors near the controller).
• Update tests

We need a public deployment of the app to have it actually work. We should probably use Azure or FlyIO.

• Add LICENSE section to README
• Add LICENSE file to the project

A lot of things can go wrong with the frontend<->backend communication: server down, configuration issues, invalid auth, etc. We can rule out many of such failure causes using a healthcheck route. It would be a simple endpoint which returns a 200 OK status code if the server is ready and other status codes for failures.

We can then call this endpoint from frontend at the start of an app and display an error in case of failure to easily detect issues with invalid backend setup. Without this, if we for instance get errors on the login screen, we cannot be immediately sure whether it is bug in the app or an issue with connection, hosting, CORS, etc.

Additionally, Dockerfiles support HEALTHCHECK instructions which can help us detect regressions.

GET /api/v1/health

• https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/health-checks?view=aspnetcore-7.0
• https://scoutapm.com/blog/how-to-use-docker-healthcheck
• https://www.youtube.com/watch?v=p2faw9DCSsY

https://github.com/zpi-2023/SensoBackend/pull/64/files/2cd8872fa90489976e09a2057f86bdb842c77eca#r1390442810

See full medication specification here: https://github.com/zpi-2023/thesis/issues/25

https://github.com/zpi-2023/thesis/pull/23

https://learn.microsoft.com/en-us/aspnet/core/tutorials/getting-started-with-swashbuckle?view=aspnetcore-7.0&tabs=visual-studio#xml-comments

Blocked by:

• #15

GET /api/v1/account/profiles

Example response:

{
  "profiles": [
    { "type": "caretaker", "seniorId": 2137, "seniorAlias": "John" },
    { "type": "caretaker", "seniorId": 123, "seniorAlias": "Kate" },
    { "type": "senior", "seniorId": 789 }
  ]
}

• Backend uses the token from the request to find account's profiles and returns all of them.
  • The endpoint may also return 0, or 1 entries.
• There can be only one entry with type senior per account.
• seniorId is unique within the list and required on each entry.
  • For type caretaker, seniorId of senior taken care of should be returned and their seniorAlias set by this caretaker.
  • For type senior, seniorId should be this account's ID.

Since the ERD diagram is complete, we can add all of the entities as classes to the backend, to make it easier to work on future capabilities.

See full medication specification here: https://github.com/zpi-2023/thesis/issues/25

Useful links:

• https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/overview
• https://learn.microsoft.com/en-us/visualstudio/code-quality/roslyn-analyzers-overview

Preferably via JWT.