xmoonlight

https://amphp.org/ и "прямые руки" архитектора.

Напишите прокси-сервис со своей учёткой и давайте клиенту ссылку для коннекта на ваш прокси. Он будет авторизоввываться в "прозрачном" режиме для клиента в фигме и клиент сразу сможет править схему.

В несколько этапов:
1. Запрос на сортировку и саму активную запись (id) в позиции "курсора" (или порядковый номер позиции сначала всего списка, если вдруг нет активного "курсора") отправляем на бэк.

2. Делаем запрос сортировки/фильтрации в БД и сохраняем текущий результат выборки во временное хранилище.

3. На фронте, по готовности: забираем сразу список элементов относительно местоположения "курсора" в "окне отображения" (или количества элементов от начала списка), который полностью помещается в это "окно".

4. По мере прокрутки, забираем куски выборки с бэка аяксом (наборы элементов "окна отображения"), расположенные выше или ниже. Этот приём называется "виртуальное окно".

Архитектура кода проекта должна отрабатывать этот функционал в автоматическом режиме.
Исправляйте архитектуру!

Могу подсказать: если вы делаете что-то на ПК - вы именно обрабатываете входные данные.
Значит нужно проверять:
1. Что именно нужно обрабатывать - перечень обязательных и необязательных переменных.
2. Что соответствует допускам для обработки, а что является мусором - regex/isNull/etc.
3. Проверить наличие всех обязательных переменных перед началом обработки.

Если что-то отсутствует - выдать сразу ошибку при запуске кода.

Это всё должно быть сделано в самом начале проекта - в заголовочном блоке кода, где хранятся все негенерируемые переменные.
Если вы задаёте (инициализируете) переменные внутри блоков, зависящие от входных данных в этот блок - ЭТО СРАЗУ EPIC FAIL!

Можно сделать п.2, но так, что в программе ничего не нужно будет менять.

Здесь два манипулятора:
1. Получение данных с устр. ввода.
2. Запись в БД.

Считаем все объекты:
1. Внешние данные
2. Получатель данных с клавиатуры
3. БД

Порядок действий:
1. Получаем
2. Проверяем
3. Пишем

Итого: три функции:
1. Фильтруй всё из того,...
2. Что только что ввёл пользователь и сразу же..
3. Пиши в БД.

Кратко, так:
if(filter(input->val)) db->insert(input->val)

1. Проектирование
2. Кодирование
3. Тестирование

Инструменты и ЯП - зависят от типа, архитектуры, платформы и сферы применения приложения, указанных в ТЗ.

Любое мероприятие или событие - это узел графа.

Узел - имеет свой тип и содержит свои свойства в зависимости от выбранного типа.

Узлы имеют связи.

Для контроля узлов всего графа - создаётся событийный обсервер.
Он следит за корректностью статусов и целостности связанных/зависимых событий.
Также, он ведёт исторический лог смены статусов: открыто/завершено, и другие показатели мероприятий.

Любые другие объекты просто имеют связи по идентификатору с нужным узлом в "дереве" мероприятий (например, лектор).

Ядро этого - хороший headless браузер.
Начинать нужно с него.
Casper.js хороший, но я бы посмотрел весь ассортимент.

То, что может быть независимо - должно быть изначально независимо.
Если обработка нужна ВСЕГДА при поступлении данных - два потока: приём данных + обработка и интерфейс отображения.
Если данные поступают быстрее, чем обработка, или нужно их хранение в "сыром" виде для дальнейшей обработки - три потока: приём данных, обработка данных и интерфейс отображения.

Грамотную архитектуру ПО знает только вендор среды окружения функционирования этого ПО.
Там и ищите.

Есть одностороння ... т.е. в результате обработки события меняется модель

Есть двухсторонняя, когда интерфейс может изменить модель, и в интерфейсе отобразятся новые данные из модели.

И то, и то - происходит через событие.

Вопрос лишь в том, на что именно влияет это событие:
1. Если только на данные (через методы, например) - это односторонний
2. Если сначала на модель (правит логику работы с данными и затем, сразу на данные - п.1) - двухсторонний.

Очень сильно зависит от поставленных задач на реализацию при достижении требуемых целей, физического исполнения и специфики использования конкретного устройства, интерфейс (он не только графический!) опреационной системы которого Вы собрались проектировать.

https://www.rainmeter.net/

Скрин(ы):

draw.io ?

Роли - это множества (точнее - "деревья" множеств), содержащие пользователей.

Расписываю подробно на примере:
Есть пользователь User1, у него роль Admin и роль Curator.
Т.е. он имеет в своём личном кабинете 2 пункта меню: Администрирование и Курирование.
Всё что в базе - привязывается только через ID-шник этого пользователя (роли и поля ролей, и т.п.).

Ни один из перечисленных!
Добавить необязательный параметр для задания формата возвращаемого значения в метод getBalance и всё.

Мне нужно разработать архитектуру![именно архитектуру, так как сайт я собрать могу].

Посмотрите здесь.