Алгоритм создания бесшовного списка данных

[nin-jin]

Рассмотрим второй вариант.

А первый вариант вы не рассмотрели, потому что бэкенд у вас гвоздями прибит к одному единственному клиенту? Или предлагается на каждом клиенте переизобретать "алгоритм" каждый раз, когда меняется способ хранения данных на бэкенде?

[FantasyOR]

*прошу прощения за сбои в форматировании, подправил статью
Не понял про клиента, если имеется ввиду фронт, то их 2 web и мобильный Flutter.

Алгоритм не нужно изобретать каждый раз, т.к.: utils и repo реализована как дженерик и выделяется в библиотеку.
Поэтому к новому модулю подключается библиотека и далее используется как:
Repository<Pays> payList

Repository<Mail> mailList

На web перенести данный код не составит труда, тоже 1 раз.

[nin-jin]

А флаттер уже научился не тянуть на фронт 2 мегабайта рантайма?

[avdosev]

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

[Ivan22]

"логика но фронте - за и против", собрание из 10 томов

[avdosev]

использовать параллельный запрос данных (в dart это реализуется с помощью изолятов);

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

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

Я это к тому, что данное улучшение находится в совершенно в другой плоскости и напрямую не является улучшением алгоритма.

[FantasyOR]

асинхронно и параллельно не одно и то же, особенно в рамках Flutter, но согласен пачки данных не такие большие чтоб уделять этому внимание.
Однако есть такой показатель как "H" вместо "4G" на телефоне, не все наши клиенты работают в крупных населённых пунктах.