I am working on a simple side project, a self-hosted POS (Point of Sale) system for small retail businesses. I have decided to use a server/client architecture because it will be easier to separate and manage the backend and frontend.
I am certain that this project will not involve the internet or any type of microservices. It may only require a local network connection, but definitely no internet connection.
For the backend API, I am using C# Web API and incorporating Identity Framework Core for user authentication and authorization. However, the Identity Framework creates tables that I don’t actually need. The only table I require is ‘AspNetUsers’ to ensure that authentication is completed, and the cookie is set, allowing users to request API endpoints.
So, I have a few questions:
If I use Identity Framework solely for authentication, is it considered bad practice to leave unused tables like ‘AspNetRoles’, ‘AspNetUserClaims’, etc.? Should I try to delete them at the moment of creating the migration?
Considering that I don’t plan to use microservices and there is no internet connection involved (the API is self-hosted), is it a disadvantage or bad practice to use cookie-based authentication? Does it violate the principles of RESTful architecture?
Can I implement activity-based authorization using the tables already created by the Identity Framework, or would it be better to create my own tables for that purpose?
