>> Крч., получается ситуация почти как GraphQL.
> А что не так с GraphQL?Давно уже разбирался, сейчас, скорее, по памяти будет.
На первый взгляд смотрится интересно, но, как начинаешь разбираться...
По сути, эта штука является подобием абстрагированной БД в качестве бэка, поля у которой не только получаемые из реальной БД и ограниченно-вычисляемые на их основе, но и вычисляемые в т.ч на основе каких-либо сторонних данных и условий с задействование всех возможностей бэка.
Система в том виде, в котором ее изображают фейсбучники и рекламируют сторонние товарищи, фундаментально ущербна ввиду того, что не дает каких-либо явных и серьезных плюсов в сравнении со столетними штуками вроде JSON-RPC( которой, к примеру, вообще без разницы, каким путем осуществляется взаимодействие - HTTP ли запросами или, в приведенном к строке формате, пробрасывается через сокетное соединение, поскольку суть подхода одна - делать к серваку конкретные запросы, на которые от него получать конкретные ответы ).
В то же время пропагандирует слишком много свободы в плане обмена данными( на стороне клиента определяется какие конкретно данные оно хочет получить с бэка, какие конкретно поля должен содержать ответ и проч, хотя не без нюансов. При нескольких разных версиях клиента может возникнуть серьезнейший бардак в потоках данных ).
Это чем-т напоминает 5-10 летнее прошлое, когда разного рода NO-SQL БД отсутствие какой-либо схемы и возможность валить данные любой структуры в них изображали в качестве невероятного плюса.
Если убрать чрезмерную свободу в обращении с данными, то внятных плюсов, в общем-то, не остается.
Тогда как минусы в виде очень специфического и нишевого подхода к обмену данными, самой структуре и настройкам, тонн оверхеда и абстракций на ровном месте, хороших шансов получить полный бардак в обмене данными если слушать пиарщиков фейсбука итд итп в общем-то никуда не деваются.
Для себя в свое время принял как наиболее интересные и оптимальные - разные подобия JSON-RPC, поскольку нет привязки к способу обмена данными( HTTP кодами "сигналить" разные сообщения как некоторые любят, угу. Особенно, если потом требуется переезд на сокеты форменное веселье начинается ), клиент понятия не имеет о внутренней организации данных и прочего и ему в принципе не надо этого( т.к он просто отправляет на бэк название функции и ее аргументы и вполне логично ожидает получить ответ в известном диапазоне результатов ), один запрос может содержать в себе целую "пачку" RPC-запросов( массив объектов, в котором каждый объект - запрос, со своим именем, аргументами и проч ), а ответ - целую пачку ответов вместо кучи одиночных запросов и ответов.
Ну это по памяти, разбирался активно с этими штуками более года назад, так и не нашел в GraphQL чего-то реально интересного и однозначно перевешивающего все остальные решения и подходы. Штука интересная и.. и на этом все.
Почти как с блокчейном, который "классические" БД, как ни странно, так и не заменил, как бы его куда ни попадя не толкали бы годами напролет и вкидывали кучи денег.
На фоне нескончаемого фейсбучного бардака( у этих гениев постоянно то поддержка чего-то отваливается, то что-то где-то ломается в их SDK, API, какие-то апи и проч устаревают и проч ), складывается ощущение, что это просто подобие т.н техно-пиара( сегодня одно, завтра - другое. Главное - сохранить образ технологичности ), поскольку даже самим идейным разработчикам их "гениальные" подходы и решения не позволяют сделать реально отказоустойчивый продукт, с непрошибаемым API и SDK.
Зато, все тестами и типизациями обмазано. Правда, еще пару лет назад тупо не подключалось, поскольку гении SDK для яблока для разных кроссплатформенных штук ожидали увидеть в захардкоженной директории "/имя_пользователя/Documents/FacebookSDK" вне зависимости от местоположения проекта.
Хотя, подобным и гугл грешит - самая большая боль обычно возникает именно при интеграции продуктов от ФБ и Гугла.. хотя, вроде бы типо_мастера в ИТ, все такие протестированы да типизированные и весь остальной мир учат как код кодить.
