https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm Раздел 5.3.2, приятного чтения.

У меня вопрос к руководителю SpaceWeb: Ну поставили вы джуна руководить разработкой, бывает, но зачем позориться-то на весь интернет?

Человек же совершенно не понимает, что такое рест и что он к протоколу, никаким боком не привязан (у нас, например, рест апи единообразно работает поверх http, websocket, sse и даже webrtc); не способен сделать тривиальный фасад к апи, без отдельных роутингов для каждого метода; просто взял первый попавшийся кривой фремворк (fastapi) и сделал поверхностные выводы об архитектурном принципе (rest); даже не рассмотрел ни graphql, ни odata, ни даже harp (про решаемые ими проблемы, очевидно, даже не в курсе, так что ждите в скором времени костылей); высасывает из пальца разницу в необходимости описывать входящие и исходящие типы, которой на самом деле нет (более того, в ресте типов надо описывать меньше, так как число ресурсов кратно меньше числа методов в эквивалентном рпц, а валидация и интроспекция нужна в обоих случаях и в обоих же случаях может быть автоматизирована).

Понимаю, звучит обидно, но вас же дети читают - чему вы их учите? Что достаточно взять 2 самых популярных среди хомячков решения, проигнорировав все остальные достижения человечества, провести поверхностный анализ, наговорить глупостей, выбрать посредственное решение и пустить его в прод?

Похоже зумеры изобрели HTML.. Скоро ещё CSS изобретут, вот тогда заживём.

Следите за руками:

Shape shape( Type, Args ... )( Args args ) {
    "create %s%s".format( Type.stringof, [args] ).writeln;
    return Type( args ).Shape;
}

shapes ~= Point(1,2).Shape; // no log
shapes ~= shape!Point( 1, 2 ); // create Point[1, 2]

Неужели не хочется писать простой и лаконичный код?

Переписал ваш код на нормальном языке:

import std.stdio, std.format, std.sumtype, std.range;

struct Point {
    int x, y;
    int area() { return 0; }
    string toString() {
        return "[%s,%s]".format( this.x, this.y );
    }
}

struct Rect {
    Point pos, size;
    int area() { return this.size.x * this.size.y; }
    string toString() {
        return "[rect:%s#%s]".format( this.pos, this.size );
    }
}

struct Line {
    Point from, to;
    int area() { return 0; }
    string toString() {
        return "[line:%s->%s]".format( this.from, this.to );
    }
}

alias Shape = SumType!( Point, Rect, Line );

void main() {
    Shape[] shapes;
    shapes ~= Shape( Point(1,2) );
    shapes ~= Shape( Rect( Point(1,2), Point(1,2) ) );
    shapes ~= Shape( Line( Point(1,2), Point(3,4) ) );
    foreach( shape; shapes ) shape.writeln;
    pragma(msg,Shape.Types);
}

(Point, Rect, Line)
[1,2]
[rect:[1,2]#[1,2]]
[line:[1,2]->[3,4]]

Считайте, что Shape - это и есть ваша фабрика.

Как-то я не уловил смысла в этой VariantFactory. Для разных типов нужны разные наборы по разному подготавливаемых аргументов. Тот, кто их предоставляет, может сразу и создавать вариант соответствующего им типа. Единственное применение, которое я вижу для подобной фабрики, - это обобщённая (де)сериализация. Но ваше решение для этого не применимо.

О том и речь..

С поиском-то всё понятно, а как быть с добавлением данных? Повсеместно используемый в СУБД B-tree использует букеты, выстраивая их в самобалансирующееся дерево, что неизбежно приводит к логарифмическому поиску. Причём далеко не бинарному, то есть степень логарифма не 2, а исчисляется десятками, а то и сотнями. Предложенный же тут алгоритм работает лишь на плоских списках. А если его применять к не плоским, то вновь выползет логарифм на доступ к каждому элементу. Для равномерно распределённых данных таким образом лучше подходит какой-нибудь trie, который по префиксу очень быстро скачет по букетам, и поиск в котором для фиксированной длины ключа даёт константную сложность.

Ну вот если сделаете PWA, то у вас даже и FCP уменьшится. А так, смотрели бы лучше на TBT, а то он у вас зашкаливает.

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

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

Заходим в ростер, проваливаемся в диалог, возвращаемся назад - фриз на 2 секунды (а на low-end mobile всё ещё в 2-3 раза хуже). Я ведь только что там был - все необходимые данные уже загружены, нужно лишь показать тривиальный список контактов.

Если уж говорить про метрики загрузки страницы, то там тоже полный швах даже без очистки хранилища:

А какая разница? Ну будет несколько диалогов с разными людьми.

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

Любым удобным способом.

Просто даёшь ему ссылку на веб приложение и всё, можно общаться.

Если видишь товар, значит ты лежишь на полке в магазине. Ты в любом случае товар, если не владеешь магазином.

Клиент может быть написан так, что становится совершенно не важно, что там на сервере вплоть до п2п коммуникации без серверов. Это, конечно, не про Телеграм.

Мемоизацию тоже добавьте по вкусу.