Василий Банников

Avalonia ИМХО.
1. Производительнее.
2. Есть нормальная поддержка Linux

Jabber? Какие вообще требования, кроме "кроме matrix"?

Портировать не выйдет.

Если очень хорошо будешь писать код, то мб сможешь потом переехать на Xamarin/Maui/Avalonia/Uno, но UI всё равно придётся писать с нуля.

Из-за того что unity всё-таки игровой движок, то ты вероятно не сможешь в нём найти всего того, что есть в фреймворках для разработки МП.

Больше джоинов - нужно больше индексов и запрос дольше и сложнее будет выполняться из-за необходимости джоинить и обращаться к разным областям диска.

Больше колонок - больше места занимает отдельная запись, больше места занимает вся база, нужно больше индексов, если нужно по этим колонкам фильтроваться. Запрос дольше выполняется из-за необходимости больше данных с диска читать.

+ Учитывай, какой вариант тебе будет поддерживать легче, если нужны будут какие-то изменения.

Нужно смотреть на конкретное железо и статистику, чтобы понять, какой вариант будет эффективнее.

Конкретно в этом случае мне больше нравится вариант, где будет по колонке на каждую соцсеть - так СУБД сможет в один проход и без каких-либо индексов всё посчитать.

А ещё в вашем кейсе можно посмотреть в сторону БД временных рядов.
А ещё можно вообще не фиксировать каждый отдельный клик, а хранить уже в агрегированном виде количество кликов на каждом посте (может быть как дополнение к предыдущим вариантам, чтобы ускорить запросы)

Вообще это браком не считается, но в теории в сервисе могут починить.
Это значит, что подсветка неравномерная

Такое определяется только эмпирически. Вашу ЦА можно на всех площадках найти.
Так что попробуйте с небольшим бюджетом везде зайти и посчитать цену лида.

Использовать капчу. Хотя тоже не даёт никаких гарантий

Нет, нельзя.

Вот такой https://aliexpress.ru/item/1005004258871739.html

Я бы попробовал VS Code.
Он, конечно, жрёт сильно больше ресурсов, чем ST, но в нём работать будет гораздо комфортнее.
+ Остаётся ощущение легковесной среды, почти как от ST.

Проблема такого теста в том, что он тестирует сразу две вещи:
1. Что работает api
2. Что работает Model::factory()->make()->toArray(), которая генерирует аргументы для вызова api

От этого возникают следующие проблемы:
1. Без изменения кода api у тебя тест может неожиданно начать падать и наоборот.
Например ты поменял названия параметров. Тест зелёный, тк фабрика генерит параметры, а клиенты все теперь 400-е ошибки получают.
Контракт получается незафиксированный.
2. Ты не можешь при таком подходе нормально проверить негативный сценарий и граничные значения.
Чтобы их проверить - тебе всё также придётся отказаться от Model::factory()->make()->toArray() и составлять параметры руками.

Вообще, api-тесты часто пишут вообще без привязки к коду - при помощи сценариев для postman например.

Инициатор при блокировке переписки сразу может и удалить всю переписку с обоих сторон - это же сразу предлагает телега сделать, и можно сделать потом.