Почему я отказался от GraphQL

Учимся правильно готовить рест и не говорить глупости.

Почему я отказался от GraphQL

Вы, видимо, считаете себя очень умным, но это определённо не так, если не видите противоречия между следующими отличительными свойствами GQL:

• Рекурсивные выборки

• Денормализованная выдача

Только полнейший профан мог такое спроектировать. И только бездумные овощи делают вид, будто этой проблемы нет.

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

Монолиты и микросервисы: что выбрать разработчику

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

Как мы выбирали протокол для клиентского API. Сравнение JSON-RPC 2.0 и RESTful API

В это и суть реста как бы - ограниченный набор методов для работы с неограниченным набором ресурсов.

Как мы выбирали протокол для клиентского API. Сравнение JSON-RPC 2.0 и RESTful API

Вот пример.

Как мы выбирали протокол для клиентского API. Сравнение JSON-RPC 2.0 и RESTful API

Ну то есть и в этом автор наврал? graphql тоже кривой так-то.

Как мы выбирали протокол для клиентского API. Сравнение JSON-RPC 2.0 и RESTful API

Пруфы в статье:

• Необходимость писать роуты для каждого метода.

• Прибитость гвоздями к хттп.

Как мы выбирали протокол для клиентского API. Сравнение JSON-RPC 2.0 и RESTful API

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

Как мы выбирали протокол для клиентского API. Сравнение JSON-RPC 2.0 и RESTful API

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

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

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

Bricks: новый подход к управлению интерфейсами

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

Фабрика для std::variant: как объединить compile-time и run-time, чтобы получить выигрыш от обоих

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

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]

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

Фабрика для std::variant: как объединить compile-time и run-time, чтобы получить выигрыш от обоих

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

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 - это и есть ваша фабрика.

Фабрика для std::variant: как объединить compile-time и run-time, чтобы получить выигрыш от обоих

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

Двоичный поиск против вероятностного

О том и речь..

Двоичный поиск против вероятностного

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

Неожиданный факт о JavaScript всплыл, и снова стал...

Не мучайтесь с JSON. Используйте более подходящие форматы.

Как мы в 4 раза ускорили мобильную версию ВКонтакте

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

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

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

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

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

Дуров: Telegram (в отличие от Signal) позволяет проверить, что все его приложения используют один и тот же открытый код

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

Строители пирамид

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

Строители пирамид

Фрактальная организация