Andrei SunnyPh

1. В Refresh токене уже есть нужная информация. И в ответ выдается новый Access Token
2. В подписанном Access Token не получится подменить exp. Так что новый
3. Откуда выходим? В Web client можно просто забыть Access Token. Но если у кого-то останется refresh token, то можно получить новый Access Token.
Если хочется чтобы его нельзя было использовать после выхода, то в Access Token и Refresh token, добавляется RefId. И если RefID в заблокирован, то новый получить Access Token из Refresh будет нельзя.
4. Каждый конект имеет свой Refresh token, так что не получите и там и там одинаковый

И все таки лучше делать сразу нормально: с БД, с АПИ, с клиентом.
Вряд ли при необходимости обновить статус товара работник магазина побежит драться за планшет с посетителем.
Можно даже без АПИ обойтись: напрямую к БД обращаться, в самой БД все менять. Да можно даже без БД - хранить все в файле, доступном по сети. Но то, что с клиента нужно выносить изменяемые данные - факт.

Нет примера вызова методов из вашего класса, но могу предположить, что вы каждый раз инициализируете его. Вам нужно сделать ваш класс Singleton'ом. Для этого в Startup ConfigureServices зарегистрируйте ваш сервис:

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddSingleton<ВашСервис>();
    }
}

И затем в Program:

public class Program
{
    public static async Task Main(string[] args)
    {
        var host = CreateHostBuilder(args).Build();
        var service = host.Services.GetRequiredService<ВашСервис>();
        service.ConnectToServer(); //Подключаемся к SignalR

        host.Run();
    }
}

UPD:
Советую поменять название класса на более общее, например, SignalrService, а метод SendToSignalR на Connect.

Используй Pomelo.EntityFrameworkCore.MySql

информации насчёт того, как делать миграции в MySQL средствами Visual Studio

Сейчас миграции делаются не средствами студии, а средствами efcore cli - в этом плане раскатка миграций никак не отличается от любой другой СУБД.

и как, собственно настраивать проект под ASP.NET (options, builder, Swagger (не удивляйтесь, пока я именно его использую, т.к. при обкатке новой СУБД такой выбор очевиден) и прочее).

Они ортогональны и никак не зависят от СУБД.

PS: зачем тебе mysql, когда есть postgres?

Ответ на вопрос "как хранить" зависит от того, какие данные вы будете запрашивать. То есть - от представлений данных, с которыми работает ваша программа (программы). Именно на основе этих представлений синтезируется полная модель даннных, хранящаяся в БД.
В свое время, лет 25 назад, был (может, и сейчас есть) стандартизированный подход, называвшийся IDEF1 (это имя из стандарта) или Entity-RelationShip (это название процедуры), позволявший формальным образом синтезировать из этих, частных, представлений полную модель данных. И были программы, которые позволяли это делать. Я одной такой пользовался, ERwin называлась (AFAIK она жива и сейчас), но, в принципе, нужные процедуры можно выполнять и вручную. Описание процедуры на русском есть, как минимум одно, которое я знаю - в старой книге "Мартин Дж. Организация баз данных в вычислительных..."
Короче, синтез модели ваших данных - это ваша задача, связанная со специфическими вашими задачами.
Судя по информации из вашего вопроса, я могу только сказать, что:
1. этот вариант вам явно не походит: данные из представления "Товары в корзине" включают товары из всех категорий, так что отделные таблицы для каждой категории - это костыль: ходить можно, а бежать - уже нет.
2. В ItemOptions можно хранить данные для всех категорий - достаточно указать в каждой записи дополнительно к идентификатору товара идентификатор категории и идентификатор свойства. Потребуются ещё таблица категорий (идентификатор категории как первичный ключ плюс дополнительная информаци) и таблица свойств для каждой из категорий (идентифкатор свойства как первичный ключ, идентификатор категории - внешний, плюс дополнительная информация). Схема получается не очень уклюжая, но для работы в рамках реляционной модели более-менее годная (я когда-то такую и делал и с ней работал, но это было жутко давно). Насколько для вас такая схема пригодна - зависит от ваших моделей предствалений: например, будете ли вы в Корзине указывать дополнительную информацию из ItemOptions.
3. NoSQL - это название больше коммерческое, а не техничекое: оно включает много разных технологий хранения в БД, единственным общим признаком которых является, что они - не реляционные. Под эту задачу мне видится годным вариант навигационной БД (это где каждая запись содержит физические ссылки на связанные с ней записи): сетевая, например. В настоящее время такие БД иногда ещё проходят под псевдонимом "графовая". Но, опять же, смотрите на нужные вам представления, в данном случае - обращайте внимание на пути доступа к данным (эти самые ссылки): навигационные БД в этом плане не так гибки, как реляционные, и отсутствие нужных ссылок может заставить ходить по кривым путям и убить тем самым производительность.
Но это все теория, а что там сейчас на практике творится - я с уверенностью сказать не могу. Насколько я понимаю, там надо смотреь возможности конкретной СУБД - тем более, что производители часто называют их словом "гибридная", и надо понимать, что в этот гибрид попадает.

Да, сейчас все работает, но правильно ли это? Или включение этой опции спасает даже при отправке условно данных на 1гб?

На ASP.NET Core есть ограничение на размер запроса в 50 Мб (или около того). Нам это не подходило - мы увеличили лимит. Но проблема лежит в другом - аллокация памяти. Большие чанки заставляют аллоцировать объекты в LOH. А там они могут лежать долго и не выгружаться.

Я думаю разбить отправку по частям, но проблема в том, что отправляемые данные - коллекция классов

Судя по примеру класса Details вроде ничего не мешает отправить сначала Added, а затем Removed. А если и это не поможет, то можно стримить каждый элемент: например, сначала отправляешь кол-во элементов, а потом по одному за раз.
Смысл в том, чтобы не сериализовать один большой объект.

А если у тебя 1Гб. то это скорее файл. Его лучше чанками отправлять и на диск сохранять. А по завершении отправки начинать читать (не полностью в память загружать, а постепенно)

SignalR.
Но с передачей 20гб вы, конечно, загнули, обычно это делают через отдельный файловый сервер-api.

если я не хочу создавать переменную

А вы её и так, и так не создаете: экземпляр исключения создается при возбуждении исключения (помните синтаксис - throw new Exception() )? А вот чтобы обратиться к полям/свойствам/методам этого экземпляра, надо дать ему имя в конструкции catch и обращаться к нему по этому имени. А при указании в качестве имени экземпляра имени класса, вы, как выше вам написал Василий Банников , как и в любом другом месте, обращаетесь к статическому полю (или свойству) этого класса. Такой вот синтаксис у языка C#: обработчик исключения у него - это обычный блок, никаких специальных соглашений там нет( пока что, по крайне мере ;-) ).

В реальном времени ты в html так их не вставишь.
У тебя два варианта:
1. Если стрим конечный, то ты можешь собрать все айтемы в лист и вернуть его как обычно.

2. Использовать websocket - тут надо будет подумать, как лучше это подружить со сложившейся у тебя архитектурой.
Как минимум нужно будет добавить js на фронт и создавать долгоживущую задачу на бэке

Предположим, вы – учитель, чья задача научить школьника/студента программированию. С чего можно начать первое занятие? Можно начать рассказывать о системах счисления, архитектуре процессора, компиляции, интерпретации и прочих вещах, но разве они и вправду так нужны новичку, которому надо просто написать змейку?

Начинать нужно с того, зачем вообще это нужно ученику, и что у него должно получиться в результате.
А что именно изучать - проще посмотреть как это сделано у других. Например глянь как устроен курс CS50 - это не только лишь программирование, а в целом компьютерные науки.

Это цели атрибутов - то для чего атрибут предназначается.
RTFM

package main

import (
    "encoding/json"
    "net/http"
)

func main() {
    http.HandleFunc("/api/data", func(w http.ResponseWriter, r *http.Request) {
        data := struct {
            Message string `json:"message"`
        }{
            Message: "Привет, мир!",
        }

        w.Header().Set("Content-Type", "application/json")
        w.WriteHeader(http.StatusOK)

        if err := json.NewEncoder(w).Encode(data); err != nil {
            http.Error(w, err.Error(), http.StatusInternalServerError)
        }
    })

    http.ListenAndServe(":3001", nil)
}

В целом так же как и на node, python, dotnet)
Делаешь небольшой сервер с endpoint, в этом случае /api/data и делаешь на него запрос с react, localhost:3001/api-data, делать запросы можно через fetch, axios. Ну и описываешь route дальше. таких роутов можно делать много, это вариант http запросов. Еще есть gRCP, ну для начала лучше разобраться с этим)

Используй GetFromJsonAsync<T>(url) метод у HttpClient.

В T указываешь объект, который нужно десериализовать, а в url - адрес, по которому нужно послать запрос. Для httpbin, например

client.GetFromJsonAsync<SomeObject>("httpbin.org/get");

Класс объекта создаешь сам.

Туториал на метаните