• Publish MVC project on Azure: ✅
• Set up with AuthDbContext: ✅
• Rename TempContext to MatchContext: ✅
• Publish backend/API on Azure: ✅
• Set up with MatchDbContext: ✅

Possibly with use of Serilog and Humio

Proposals/ideas:

• Filter by time control
• Filter by color
• Filter by opening

See the following on migrating the Web-project to .NET 5: https://docs.microsoft.com/en-us/aspnet/core/migration/31-to-50?view=aspnetcore-5.0&tabs=visual-studio

Proposed solution:

• Add UserName property to MatchEntity (db) and pass AspNetUsers.Username in requests to return user's data

Possible resource: https://stackoverflow.com/questions/44783744/how-to-authorize-a-user-to-only-see-his-own-records-with-asp-net-identity-2-0

This solution is sub-optimal and will require refactor.

Among other things, the .suo file should be ignored.

Issue 6 needs to be solved at the same time.

Should be implemented after #18

Comply with REST principles

• Implement caching
• Implement HATEOAS (research how this should be done for a frontend client). Update: On a second thought, this may not be relevant since I don't expose the API.

Might require slight refactor in the frontend as well.

Probably want a command like git rm --cached file.suo, so that my local settings aren't removed

• "Reason for loss or draw" should probably be renamed to "Analysis"
• "Time control" should probably be an enum of Bullet, Blitz, Rapid and Classical instead of a text-field/string

For example:

• Implement unit tests, integration tests, maybe benchmarking etc.
• Afterwards, set it up with GitHub Action pipelines #4

As a user, I am able to:

• register and save PGN
• link to game on e.g. lichess or chess.com
• specify time control
• specify playing color
• specify opening

Requires investigation into how to go about saving pgns, and consideration of importance of saving playing color as well as opening.

Playing color should probably be enum.

Initially, the following is required

• Basic error/exception handling (.e.g try-catch) and validation
• Appropriate HTTP Status Code responses
• Produces-annotation for control and Swagger documentation (however, Swagger-docs is only for internal use, so lower priority)

Might require slight refactor in the frontend as well.

Due: Sunday, October 31

Add properties such as Date (which date was the game played), opponent (name), and reason for loss.

The MVC-View layer is going to be exchanged with Angular 2.0.

This task as a whole needs to be divided into several subtasks. As a first task, just one of the simpler pages, e.g. the page "About" or "Changelog will be ported/converted to Angular.

If the website hasn't been visited/used for a while, it takes extra time to load the website upon first visit (spins up MVC project) and first login (spins up API project) - maybe around 3-5 seconds for each.

It would be nice to have some loading animation or similar meanwhile, if it's possible, or figure out how to avoid the extra initial load times.

• Fix Update-method in repository
• Put code into appropriate folders to make it easier to overview/manage

• After creating a new match (and in all cases where it doesn't happen) ✅
• If user is logged in when going to homepage (from Home/Index) ✅

First of all, pros and cons of using AutoMapper should be researched a bit more. In general, it can be assumed, that it will give better performance to do manual mapping, but it will also result in more boilerplate code.

If it is decided to keep AutoMapper:

• Investigate whether it is possible to exclusively register AutoMapper-dependencies in repository-project with ServiceCollectionExtension, so that it is possible to remove the AutoMapper NuGet-package from API-project.

• At the same time, investigate whether the service lifetime of IMapper is appropriate or should be changed. It is not an issue in itself, which is why I attach the starting point of the following interesting discussion on this issue for now instead: AutoMapper/AutoMapper#2569

Split queries and commands etc. in accordance to CQRS. Can be supported with MediatR-library.

This is not a part of Release 1.0.0. Initially, API requests will be handled in a simpler manner to allow for faster development.

Tasks

• It doesn't neccessarily have to be HttpClient; research alternatives, make a decision and then research best practices
• Create a net5.0 backend API project with a simple/sample endpoint to start with

Resources:

• https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient?view=net-5.0
• https://www.thecodebuzz.com/using-httpclient-best-practices-and-anti-patterns/

Makes more sense to do this after #34

For example:

• CreatedAt
• LastLogin (however it is not very useful, if they keep being logged in)