Вот это да!!!

Будет мясо👏👍

Идея хорошая, но работает пока не очень

используем пока только для видеосозвонов. единственный минус - больше 150 участников не тянет. Железо не тянет наверное.
а еще брендировать можно интерфейс
а что не очень для вас?

Нагрузка на железо большая, во время звонков все время лаги, плохой noise cancellation (может его вообще нет).

А, ну и шаринг экрана глючит

шаринг экрана и подавление шума глючат да. (не критично)

а с дискордом что не так)

Я конечно не увидел електронjs в deprecated списке вождя но подозреваю что он был в одной из прошлых его итераций

Добрый день! Я опять с теоретическим вопросом.
С помощью какой технологии в клиент-серверном приложении можно разделить функции бекендера так, чтобы бизнес логику  писал один разраб, а способы доставки данных (rest, rpc) описывает фронтендер? я только что описал graphQL или это что-то другое?

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

bff?

но бек будет тоже пилить презентацию, которую будет юзать бфф

Фронтенд согласно чистой архитектуре находится на периферии приложения, а значит зависим от бл на бэке. И графкл не про это, там мы всё равно зависим от документации api. Я думаю, такое возможно организовать с помощью каких-то  неебических мапперов, но зачем оно тебе...

не знаю. Розділи просто на бекенді ці речі і хай фронендер там комітить в папочки інфраструктури)

Наймите фулкека

Вебмастера!

Скрам мастера

scum master

Данжен мастер

For three hundred bucks