упарываюсь по асинхронным интерфейсам

упарываюсь по асинхронным интерфейсам

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

Это псевдо асинхронность. Так как интерфейс все равно фризится до получения ответа раз. Во время рендеринга ответа "все пляшет" так как виджеты перестраиваютс в дереве - два.

Настоящая асинхронность достигается только через паттерн паблишер/сабскрайбер. Если не ошибаюсь - когда писали plan 9 (это такая операционка из которой родились например golang и utf8) - авторы закладывали в нее именно такую - настоящую асинхронность. Допустим я вожу мышкой по экрану - мышка не взаимодействует с осью напрямую - она шлет куда то в сокет сигналы - позиция x:100,y:112. А сабскрайберы слушают сигналы - например - сабскрайбер - экран - рендерит курсор.

Это позволяет изолировать все от всего раз. Становится похер на связанность устройств. Экран может быть на сервере в чикаго, а юзер водит жалом по экрану в москве - для операционки ничего не меняется - два. Унифицируются интерфейсы - вожу я пальцем по тачу смартфона или джойстиком на игровой консоли - не важно, в сокеты шлются координаты точно также - три. И самое главное - инерфейс не фризится никогда, бай дефаулт. Программы не "висят". Вот что они закладывали. Но только через десять лет мы допирать начинаем как это круто. Так часто бывает - идеи были слишком революционны для того времени.

Перейдем к практике. Есть приложуха на флаттер - которая рендерит статьи. Она умеет только рендерить объекты. Есть сервер на go (grpc) который умеет публиковать события в канал и слушать "приказы". Соединяем это вместе. Приложение стартует встроенный go сервер и подписывается на событие "статьи". Сервер (go) парсит rss, и по мере парсинга, каждой статьи - публикует их в канал. Клиент просто рендерит события из канала. Клиент только рисует. Сервер делает всю тяжелую работу. Так же работает база данных. Нет "фриза" - дай статьи. Клиент просто подписан на канал, а сервер сам решает - взять статью из базы или из инета. Более того - сервер может быть как встроен прям в аппу, так и вынесен в "Чикаго".

А на выходе? Плавный интерфейс- рендерящий статьи (события) по мере поступления. Так писать гораздо сложнее - чем как дебил. Но и работать это будет на любой операционке и никто не связан друг с другом.