Вот сейчас идет массированная пропоганда GraphQL. Как я понял, он позиционируется как замена REST и теперь API нужно писать на нем.

Что скажете?

Здравствуйте, Shmj, Вы писали:

S>Вот сейчас идет массированная пропоганда GraphQL. Как я понял, он позиционируется как замена REST и теперь API нужно писать на нем.

S>Что скажете?

Да.

Здравствуйте, Shmj, Вы писали:

S>Вот сейчас идет массированная пропоганда GraphQL. Как я понял, он позиционируется как замена REST и теперь API нужно писать на нем.

S>Что скажете?

Эта якобы "массированная пропоганда" впервые появилась только с твоим постом. Где вы её берёте??

Даже не буду искать, что это такое, просто скажу: IPC стандартов — десятки, каждый по-своему бестолковый, но даже среди них некоторые приняты отраслью. Написана куча софта, сервисов, поэтому без явного преимущества "нового над старым", никто на новичка переходить не будет. Люди как бы делом заняты и чисто утилитарная, низкоуровневая чепуха "как передать три байта" вообще не достойна наших умов.

Здравствуйте, Shmj, Вы писали:

S>Вот сейчас идет массированная пропоганда GraphQL. Как я понял, он позиционируется как замена REST и теперь API нужно писать на нем.

S>Что скажете?

Что это?

Отрыжка фейсбука имхо. Я не нашёл нормальных реализаций сервера на Java, например. Конкретно GraphQL не взлетит. Но что-то похожее, надеюсь, взлетит, REST это редкая лажа. А может и он взлетит. Принципы у него хорошие.

S>Вот сейчас идет массированная пропоганда GraphQL. Как я понял, он позиционируется как замена REST и теперь API нужно писать на нем.
S>Что скажете?

Нет, проблемы которые он решает как по мне высосаны из пальца.

Здравствуйте, Kolesiki, Вы писали:

K>Эта якобы "массированная пропоганда" впервые появилась только с твоим постом. Где вы её берёте??

K>Даже не буду искать, что это такое, просто скажу: IPC стандартов — десятки, каждый по-своему бестолковый, но даже среди них некоторые приняты отраслью. Написана куча софта, сервисов, поэтому без явного преимущества "нового над старым", никто на новичка переходить не будет. Люди как бы делом заняты и чисто утилитарная, низкоуровневая чепуха "как передать три байта" вообще не достойна наших умов.

А самая чо прекольное, т.е. просто обычные человеки придумали очередную хероту, обзовут красивым звучным словом, а потом на каком нить хеадхантере HR будут писать: знание GraphQL — must have. И куча тупоголовых абитуриентов будут забивать себе голову этим шлаком, который через год сменится очередным шлаком. А смысл всей этой шляпы, чтобы правильно показывать лайки под кол-ом постов!

УЧИТЕ С/С++. Этого достаточно для всего! Остальное не нужно.

МД>УЧИТЕ С/С++. Этого достаточно для всего! Остальное не нужно.

И вот однажды ты разговариваешь с дизайнером, весь из себя с десятилетним опытом C++,
а она тебя спрашивает "ну ты хотя бы на php-то писать умеешь?"

Здравствуйте, Arsen.Shnurkov, Вы писали:

МД>>УЧИТЕ С/С++. Этого достаточно для всего! Остальное не нужно.

AS>И вот однажды ты разговариваешь с дизайнером, весь из себя с десятилетним опытом C++,
AS>а она тебя спрашивает "ну ты хотя бы на php-то писать умеешь?"

Хмм... если ты хотел спетросянить, то я не понял. Если нет, то я тоже не понял.

И сам PHP написан на C/C++.

Здравствуйте, Arsen.Shnurkov, Вы писали:

AS>И вот однажды ты разговариваешь с дизайнером, весь из себя с десятилетним опытом C++,
AS>а она тебя спрашивает "ну ты хотя бы на php-то писать умеешь?"
Ичо? Можно смело говорить "да", писать на плюсах и радовать скоростью работы

Здравствуйте, Arsen.Shnurkov, Вы писали:

AS>И вот однажды ты разговариваешь с дизайнером, весь из себя с десятилетним опытом C++,
AS>а она тебя спрашивает "ну ты хотя бы на php-то писать умеешь?"

А ты такой: "В сортах говна не разбираюсь!"

Здравствуйте, Sheridan, Вы писали:

S>Ичо? Можно смело говорить "да", писать на плюсах и радовать скоростью работы

Но не скоростью разработки. То что современный паренек сделает за час на каком-нибудь Go, плюсовик будет пилить неделю, а потом еще три отлаживать.

Здравствуйте, Shmj, Вы писали:

S>Вот сейчас идет массированная пропоганда GraphQL. Как я понял, он позиционируется как замена REST и теперь API нужно писать на нем.

Я так и знал что кто-нибудь после вчерашней статьи на хабре притащит GraphQL сюда.

S>Что скажете?

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

МД>>>УЧИТЕ С/С++. Этого достаточно для всего! Остальное не нужно.

AS>>И вот однажды ты разговариваешь с дизайнером, весь из себя с десятилетним опытом C++,
AS>>а она тебя спрашивает "ну ты хотя бы на php-то писать умеешь?"

МД>Хмм... если ты хотел спетросянить, то я не понял. Если нет, то я тоже не понял.

Это случай из моей жизни. Я хотел сказать, что C/C++ достаточно не для всего (например для маркетинга и продаж может быть недостаточно).

Здравствуйте, pestis, Вы писали:

P>Проблемы, которые якобы решает GraphQL, либо высосаны из пальца, либо решаются на том же REST если приложить немного усилий. Меньше чем придется вложить в изучение нового протокола, протаскивание его во все клиенты и разработку для него инструментов.

Немного оффтопа. Объясните эту нездоровую тягу к изобретательству? Неважно что, но главное запилить чтото новое. Чем старое то всё не устраивает?

Здравствуйте, Мёртвый Даун, Вы писали:

МД>Немного оффтопа. Объясните эту нездоровую тягу к изобретательству? Неважно что, но главное запилить чтото новое. Чем старое то всё не устраивает?

Что для тебя новое, а что старое? SOAP и прочие говноRPC против REST или REST vs. GraphQL?

Здравствуйте, Shmj, Вы писали:

S>Вот сейчас идет массированная пропоганда GraphQL. Как я понял, он позиционируется как замена REST и теперь API нужно писать на нем.
S>Что скажете?

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

S> взлетит или помрет?

S>Что скажете?

Насколько я понял, GraphQL упрощает фронтэнд и усложняет бакенд. При этом разработчики фронтэнда визжат от восторга по поводу GraphQL. Так что либо твой суперсайт поддерживает его, либо API твоего сайта никто кроме тебя использовать не будет (при наличии конкурентов). Кроме того, GraphQL упрощает обратную совместимость, поэтому даже тебе если со своим API сайта работаешь только ты, GraphQL будет полезен (про цену в виде усложнения бакенда я уже сказал).

P.S. Уже влетел.

M>Что это?

Язык запросов к сайтам. Если стандартный REST что-то типа "дай мне 10-ю запись из таблицы 'статьи'", то GraphQL позволяет делать запросы типа SQL "дай мне 10
последних записей из таблицы 'статьи' столбцы 'название' и 'автор' и добавь для каждой статьи массив комментариев с полями 'текст', 'автор' и 'дата', а также добавь отдельный список последних 5-ти постов на форум". Это все в виде одного запроса.

M>Язык запросов к сайтам. Если стандартный REST что-то типа "дай мне 10-ю запись из таблицы 'статьи'", то GraphQL позволяет делать запросы типа SQL "дай мне 10
M> последних записей из таблицы 'статьи' столбцы 'название' и 'автор' и добавь для каждой статьи массив комментариев с полями 'текст', 'автор' и 'дата', а также добавь отдельный список последних 5-ти постов на форум". Это все в виде одного запроса.

Это выходит какой то "SQL" наружу.

Здравствуйте, Arsen.Shnurkov, Вы писали:

МД>>УЧИТЕ С/С++. Этого достаточно для всего! Остальное не нужно.

AS>И вот однажды ты разговариваешь с дизайнером, весь из себя с десятилетним опытом C++,

А зачем разговаривать с дизайнером?

Здравствуйте, Masterspline, Вы писали:

M>>Что это?

M>Язык запросов к сайтам. Если стандартный REST что-то типа "дай мне 10-ю запись из таблицы 'статьи'", то GraphQL позволяет делать запросы типа SQL "дай мне 10
M> последних записей из таблицы 'статьи' столбцы 'название' и 'автор' и добавь для каждой статьи массив комментариев с полями 'текст', 'автор' и 'дата', а также добавь отдельный список последних 5-ти постов на форум". Это все в виде одного запроса.

Как упал уровень разработчиков. Генерация строки для передачи команд на сервер и парсинг этой сроки на сервере называется: архитектурой, технологией. Скилом, достойным употребления в резюме. Причем сам протокол разрабатывать не нужно, потому что REST — стандарт, и всякие парсеры уже кем-то готовы. И когда меняется структура протокола в виде ее расширения, мозг у кодера вскипает. "Перейду-ка я на новую модную технологию". Нет, "ТЕХНОЛОГИЮ".
Какого хрена REST изначально не мог возвращать "10-ю строку" с джойном комментариев? Что-там там такого заумного для реализации?

Здравствуйте, int64, Вы писали:

I>Как упал уровень разработчиков.

как постарели юзера кывта!

I>Генерация строки для передачи команд на сервер и парсинг этой сроки на сервере называется: архитектурой, технологией. Скилом, достойным употребления в резюме.

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

I>Какого хрена REST изначально не мог возвращать "10-ю строку" с джойном комментариев? Что-там там такого заумного для реализации?

проблема в том, что комментарии находятся в одном физическом кластере, авторы их — в другом, "строки" — в третьем, который доступен только через четвёртый.
graphql — это просто многоуровневая адресация. в вебе давно напрашивается такой стандарт.

Здравствуйте, Мёртвый Даун, Вы писали:

МД>Немного оффтопа. Объясните эту нездоровую тягу к изобретательству?

Изобретательство тут ни при чем. Это здоровая тяга к деньгам в Facebook Inc.

МД>Неважно что, но главное запилить чтото новое.

У них есть определенная цель и они идут к ней. Представь, что ты искуственный интеллект фейсбука и вокруг тебя сайты говорящие с тобой на одном языке, твоем языке — разве не достойная цель.

МД>Чем старое то всё не устраивает?

А старого то и нет. Раньше ни один сайт не разговаривал на языке понятном роботам фейсбука.

Здравствуйте, neFormal, Вы писали:

F>в вебе давно напрашивается такой стандарт.

Кем напрашивается то? Разработчиками парсеров?

Здравствуйте, _Raz_, Вы писали:

_R_>Здравствуйте, Мёртвый Даун, Вы писали:

МД>>Немного оффтопа. Объясните эту нездоровую тягу к изобретательству?

_R_>Изобретательство тут ни при чем. Это здоровая тяга к деньгам в Facebook Inc.

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

Здравствуйте, Мёртвый Даун, Вы писали:

_R_>>Изобретательство тут ни при чем. Это здоровая тяга к деньгам в Facebook Inc.
МД>Меня почему то воспитывали, что тяга к деньгам — это уже само по себе нездоровое явление.

Речь про коммерческую компанию

Здравствуйте, Masterspline, Вы писали:

M>Язык запросов к сайтам. Если стандартный REST что-то типа "дай мне 10-ю запись из таблицы 'статьи'", то GraphQL позволяет делать запросы типа SQL "дай мне 10
M> последних записей из таблицы 'статьи' столбцы 'название' и 'автор' и добавь для каждой статьи массив комментариев с полями 'текст', 'автор' и 'дата', а также добавь отдельный список последних 5-ти постов на форум". Это все в виде одного запроса.

А в OData чего, найден фатальный недостаток?

Здравствуйте, _Raz_, Вы писали:

F>>в вебе давно напрашивается такой стандарт.
_R_>Кем напрашивается то? Разработчиками парсеров?

веб-приложениями с микросервисами.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>А в OData чего, найден фатальный недостаток?

она умеет в запросы сразу к нескольким частям бэкенда? судя по туторам — нет.

Здравствуйте, vsb, Вы писали:

vsb>Отрыжка фейсбука имхо. Я не нашёл нормальных реализаций сервера на Java, например. Конкретно GraphQL не взлетит. Но что-то похожее, надеюсь, взлетит, REST это редкая лажа. А может и он взлетит. Принципы у него хорошие.

Мы graphql-java использовали, косяки были, но, в принципе, работает.

Здравствуйте, int64, Вы писали:

I>Какого хрена REST изначально не мог возвращать "10-ю строку" с джойном комментариев? Что-там там такого заумного для реализации?

REST никак не помогает, когда есть пачка разных клиентов, которым нужны разные проекции данных. Например,

1) Выдержка из страхового полиса
2) Выдержка + все водители
3) Выдержка + все автомобили
4) Выдержка + основной контакт + заданные автомобили с полной информацией по покрытиям
5) И.т.д

Конечно же, можно делать разные API для разных клиентов, но это неудобно. Можно возвращать все данные, но это не всегда возможно (старым клиентам могут не понравиться новые данные, производительность, и.т.д). Можно придумывать свои ad-hoc способы фильтрации (параметры запроса типа full/summary, includeVehicles, и.т.д), но это неуклюже.

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

Здравствуйте, pestis, Вы писали:

P>Но не скоростью разработки. То что современный паренек сделает за час на каком-нибудь Go, плюсовик будет пилить неделю, а потом еще три отлаживать.
Такие претензии мне напоминают дельфистов: да вот мы форму за пять минут накидаем мышкой, а сколько вам на ваших Си такое же клепать?
Если есть готовые примитивы — на любом языке пишется быстро.

НС>А в OData чего, найден фатальный недостаток?

А чё ты у меня-то спрашиваешь? Я тут всего-лишь отвечаю на вопросы людей, которые гуглить и читать не умеют не хотят.

Про GraphQL я читал на хабре раза два уже (причем первый раз несколько месяцев — год назад), про OData только в комментариях к последней статье узнал. Вообще, задача, которую решает GraphQL довольно стандартная для веба, наверняка уже напридумывали множество решений. Но популяризуют то, которое придумал FaceBook и реализовал у себя GitHub для своих API. В результате API гораздо проще и удобнее, так что штука должна стать популярной у всех более-менее сложных сайтов.

Здравствуйте, Мёртвый Даун, Вы писали:

МД>Чем старое то всё не устраивает?

В старом фатальный недостаток.

Здравствуйте, CreatorCray, Вы писали:

CC>Такие претензии мне напоминают дельфистов: да вот мы форму за пять минут накидаем мышкой, а сколько вам на ваших Си такое же клепать?
CC>Если есть готовые примитивы — на любом языке пишется быстро.

Вроде писали в умных книжках, что хорошие инструменты экономят до 20% времени. Не в 10 раз, но 20% сэкономить можно.

Здравствуйте, Shmj, Вы писали:

S>Вот сейчас идет массированная пропоганда GraphQL. Как я понял, он позиционируется как замена REST и теперь API нужно писать на нем.

S>Что скажете?

Выглядит интересно. В свое время я пытался заставить работать реализации OData на Java (точнее для JPA) — так и не заработало. Вот если кто-нибудь напишет реализацию сабжа на основе JPA/Hibernate, а лучше Apache Kundera, чтобы получить почти настоящий polyglot persistence на основе одного API — может и взлетит. Хах, думаю, самому что ли взяться.

Здравствуйте, Иван Дубров, Вы писали:

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

Во-первых, сразу в полный рост встаёт вопрос о защите. Все ли клиенты могут всё смотреть?? Во-вторых, нельзя просто так взять и простой перделкой заменить сложную систему. Для чего мы изобретали 3-звенную модель? Вот как раз для этого — чтобы на самом низком уровне — запросы данных, выше — бизнес логика и совсем наверху — клиент, от действий которого ничего не зависит — он в принципе не способен поломать защиту. А теперь вы вытаскиваете "уровень запросов к БД" поверх сервера приложений и... что? Шляпа навыворот, вот что.

Я не вижу ничего плохого в обилии функций. На то они и API, что это они решают, как и что ты будешь делать с сервером. Да и не припомню каких-то таких страшных сценариев, где нужна вот такая вот навороченная "модель запросов". Это скорее криворукие громозеки с фэйспука пытаются натянуть своё незнание на теорию IPC. Да и про производительность они, походу, слышали ещё меньше, чем изобретатели WPF.

На сегодня нет особых проблем с IPC — уже всё решено и не по одному разу, просто приходят школотроны-архитекторы без знаний в отрасли и начинают переизобретать то, что работает годами. Попрыгают, деньги профукают, да и вернутся на веб-сервисы. А я даже над этими сервисами смеюсь — мой JSON-RPC ещё десяток лет проработает без колыханий.

I>>Какого хрена REST изначально не мог возвращать "10-ю строку" с джойном комментариев? Что-там там такого заумного для реализации?
ИД>REST никак не помогает, когда есть пачка разных клиентов, которым нужны разные проекции данных.

Выгрузить базу данных на клиента и там же её фильтровать через JavaScript — это супер идея.

Здравствуйте, neFormal, Вы писали:

НС>>А в OData чего, найден фатальный недостаток?
F>она умеет в запросы сразу к нескольким частям бэкенда?

OData это просто протокол. А уж откуда и как наполнены источники данных, для которых он используется, это уже вопросы реализации. Но я понял, OData это недостаточно хипстерски.

Здравствуйте, turbocode, Вы писали:

ИД>>REST никак не помогает, когда есть пачка разных клиентов, которым нужны разные проекции данных.
T>Выгрузить базу данных на клиента и там же её фильтровать через JavaScript — это супер идея.

Настоящий хипста-стайл. Веб, как обычно, рулится толпой ажитирующих мелкоплавающих товарищей, верящих в серебрянную пулю.

Здравствуйте, turbocode, Вы писали:

T>Выгрузить базу данных на клиента и там же её фильтровать через JavaScript — это супер идея.

Так я о чём и говорю -- поэтому и GraphQL (который делает фильтрацию на сервере)

Здравствуйте, Kolesiki, Вы писали:

K>Во-первых, сразу в полный рост встаёт вопрос о защите. Все ли клиенты могут всё смотреть?? Во-вторых, нельзя просто так взять и простой перделкой заменить сложную систему. Для чего мы изобретали 3-звенную модель? Вот как раз для этого — чтобы на самом низком уровне — запросы данных, выше — бизнес логика и совсем наверху — клиент, от действий которого ничего не зависит — он в принципе не способен поломать защиту. А теперь вы вытаскиваете "уровень запросов к БД" поверх сервера приложений и... что? Шляпа навыворот, вот что.

В GraphQL нет запросов в их традиционном представлении. GraphQL -- это скорее про фильтрацию данных, чем про произвольные запросы. Ты объявляешь схему данных, которые ты готов выставить клиентам, а клиенты запрашивают, какие кусочки им интересны.

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

Это не то же самое, что выставить наружу, например, SQL для запросов к твоей внутренней БД.

Почему-то многие, прочитав по верхам, начинают фантазировать в эту сторону. GraphQL -- это просто способ задать API так, что клиент автоматом получает контроль над тем, какие данные ему надо вернуть из результата.

K>Я не вижу ничего плохого в обилии функций. На то они и API, что это они решают, как и что ты будешь делать с сервером.

Да. И GraphQL позволяет тебе сразу задать спектр возможных API функций, см выше пример со страховым полисом.

Что-то подобное GraphQL может быть полезно для интеграций в энтерпрайзе. Там постоянно возникает задача выгрузки разных проекций данных и делать (и поддерживать) API на каждый случай трудно (особенно, если модель данных может произвольно расширятся во время имплементации).

Для backend for frontend сервисов тоже полезно. Когда тебе нужно поддерживать старые API на несколько лет назад, возникает желание делать более гибкие API, чтобы не приходилось каждый раз запиливать новые. Опять же, зачем старым клиентам отправлять данные, которые им не нужны? Это лишний траффик.

K>Да и не припомню каких-то таких страшных сценариев, где нужна вот такая вот навороченная "модель запросов".

Ещё раз, навороченной модели запросов в GraphQL нет.

K>А я даже над этими сервисами смеюсь — мой JSON-RPC ещё десяток лет проработает без колыханий.

Ой, ну нашёл чем гордиться. Наши убогие SOAP сервисы поди и через 30 лет ещё где-то будут работать

Здравствуйте, int64, Вы писали:

I>Как упал уровень разработчиков. Генерация строки для передачи команд на сервер и парсинг этой сроки на сервере называется: архитектурой, технологией. Скилом, достойным употребления в резюме.

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

Индустрия не просто катится в говно, она уже грохнулась туда и медленно тонет.

Здравствуйте, Shmj, Вы писали:

S>Вроде писали в умных книжках, что хорошие инструменты экономят до 20% времени. Не в 10 раз, но 20% сэкономить можно.

За 20% я не буду отрывать задницу от дивана.

Здравствуйте, alpha21264, Вы писали:

A>За 20% я не буду отрывать задницу от дивана.

Если бюджет разработки 10 млн. -- то 20% это $2 млн. Мало?

Здравствуйте, Shmj, Вы писали:

S>Вроде писали в умных книжках, что хорошие инструменты экономят до 20% времени. Не в 10 раз, но 20% сэкономить можно.
Это глупые книжки.
Хорошие инструменты могут и в 100 раз быстрее результат получить. Причём есть хороший шанс что результат будет лучше.
Например, авторы вот этой штуки http://halide-lang.org/
За один день написали алгоритм, на оптимизацию которого программист из Adobe убил 3 месяца. Причем результат получился в 2 раза быстрее.

Здравствуйте, Shmj, Вы писали:

S>Вроде писали в умных книжках, что хорошие инструменты экономят до 20% времени. Не в 10 раз, но 20% сэкономить можно.
Похоже что реально хорошие инструменты этих книжек не читали и потому экономят гораздо больше.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>OData это просто протокол. А уж откуда и как наполнены источники данных, для которых он используется, это уже вопросы реализации. Но я понял, OData это недостаточно хипстерски.

адресация может быть к одному источнику и к нескольким.
одата умеет адресоваться к нескольким источникам? или она — слишком старпёрский унылый наколенный протокол для домашних страничек на пхп?

Здравствуйте, StandAlone, Вы писали:

SA>Индустрия не просто катится в говно, она уже грохнулась туда и медленно тонет.

вот и наступила старость.

Здравствуйте, neFormal, Вы писали:

F>или она — слишком старпёрский унылый наколенный протокол для домашних страничек на пхп?

Ну я и говорю, фатальный недостаток, недостаточно хипстерский.

ИД>Так я о чём и говорю -- поэтому и GraphQL (который делает фильтрацию на сервере)
На сервере можно сделать фильтрацию и без GraphQL.

Здравствуйте, Ночной Смотрящий, Вы писали:

F>>или она — слишком старпёрский унылый наколенный протокол для домашних страничек на пхп?
НС>Ну я и говорю, фатальный недостаток, недостаточно хипстерский.

ясно, понятно. ничего не знаешь, но имеешь мнение.

Здравствуйте, turbocode, Вы писали:

ИД>>Так я о чём и говорю -- поэтому и GraphQL (который делает фильтрацию на сервере)

T>На сервере можно сделать фильтрацию и без GraphQL.

И как ты сделаешь фильтрацию, если не знаешь что фильтровать?
GraphQL это как язык описания, что именно клиенту нужно, только и всего. Типа SQL.

Решаемая проблема в том, что если клиенту требуется какой-то запрос который не был предусмотрен сервером, сервер приходится менять.
С GraphQL сервер просто говорит какие данные у него в принципе есть (предоставляет схему данных) а клиент может запрашивать любую ее часть.
Также можно например легко добавлять новые данные в модель без страха поломать клиентов (особенно актуально если клиентов много и они разные)

Здравствуйте, neFormal, Вы писали:

НС>>Ну я и говорю, фатальный недостаток, недостаточно хипстерский.
F>ясно, понятно. ничего не знаешь, но имеешь мнение.

Вот только это ты и велосипедеры из фейсбучека не знали про OData. Причем это, судя по всему, принципиальная позиция у хипста-стайл архитектов — существующие решения всегда плохие, и все надо делать с нуля.

P.S. Перешел на личности — слил.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Вот только это ты и велосипедеры из фейсбучека не знали про OData.

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

НС>P.S. Перешел на личности — слил.

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

bnk>И как ты сделаешь фильтрацию, если не знаешь что фильтровать?
На сервер передать параметры фильтра.

bnk>GraphQL это как язык описания, что именно клиенту нужно, только и всего. Типа SQL.
bnk>Решаемая проблема в том, что если клиенту требуется какой-то запрос который не был предусмотрен сервером, сервер приходится менять.
Ну да выставить SQL наружу к базе и ничего менять на сервере не придется.

bnk>С GraphQL сервер просто говорит какие данные у него в принципе есть (предоставляет схему данных) а клиент может запрашивать любую ее часть.
Все это мне напоминает OLAP кубы, там тоже юзер получает многомерный куб данных и клиент может получать какой то срез данных из этого куба динамическими запросами.

bnk>Также можно например легко добавлять новые данные в модель без страха поломать клиентов (особенно актуально если клиентов много и они разные)
Новые данные в любом случае не должны ломать обратную совместимость.

Здравствуйте, neFormal, Вы писали:

НС>>Вот только это ты и велосипедеры из фейсбучека не знали про OData.
F>но ты не ответил на вопрос.

Какой?

НС>>P.S. Перешел на личности — слил.
F>аа, так ты посраться сюда пришёл.

Перешел на личности ты, а посраться пришел я. Логика ...

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Вот только это ты и велосипедеры из фейсбучека не знали про OData.
F>>но ты не ответил на вопрос.
НС>Какой?

http://rsdn.org/forum/flame.comp/6854345.1

Автор: neFormal
Дата: 30.07.17

НС>>>P.S. Перешел на личности — слил.
F>>аа, так ты посраться сюда пришёл.
НС>Перешел на личности ты, а посраться пришел я. Логика ...

я задаю конкретные вопросы и не занимаюсь демагогией.

Здравствуйте, turbocode, Вы писали:

ИД>>Так я о чём и говорю -- поэтому и GraphQL (который делает фильтрацию на сервере)
T>На сервере можно сделать фильтрацию и без GraphQL.

Спасибо, кэп!

Здравствуйте, neFormal, Вы писали:

F>http://rsdn.org/forum/flame.comp/6854345.1

Автор: neFormal
Дата: 30.07.17

Если коротко, то да.

НС>>Перешел на личности ты, а посраться пришел я. Логика ...
F>я задаю конкретные вопросы и не занимаюсь демагогией.

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

Здравствуйте, Ночной Смотрящий, Вы писали:

F>>http://rsdn.org/forum/flame.comp/6854345.1

Автор: neFormal
Дата: 30.07.17

НС>Если коротко, то да.

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

НС>>>Перешел на личности ты, а посраться пришел я. Логика ...
F>>я задаю конкретные вопросы и не занимаюсь демагогией.
НС>"ничего не знаешь, но имеешь мнение" это не вопрос, а та самая демагогия, в которой у тебя еще и хватает наглости обвинить меня.

нефиг было начинать кидать понты.

Здравствуйте, neFormal, Вы писали:

F>>>http://rsdn.org/forum/flame.comp/6854345.1

Автор: neFormal
Дата: 30.07.17

НС>>Если коротко, то да.
F>я никуда не тороплюсь, показывай.

https://www.youtube.com/watch?v=Vt98pqsddLM

НС>>"ничего не знаешь, но имеешь мнение" это не вопрос, а та самая демагогия, в которой у тебя еще и хватает наглости обвинить меня.
F>нефиг было начинать кидать понты.

Повторюсь — перешел на личности — слил.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Если коротко, то да.
F>>я никуда не тороплюсь, показывай.
НС>https://www.youtube.com/watch?v=Vt98pqsddLM

Progress DataDirect Cloud — молодцы. только OData тут ни при чём.
ты даже не смотришь то, что присылаешь.

НС>>>"ничего не знаешь, но имеешь мнение" это не вопрос, а та самая демагогия, в которой у тебя еще и хватает наглости обвинить меня.
F>>нефиг было начинать кидать понты.
НС>Повторюсь — перешел на личности — слил.

да меня как-то не заботят "форумные понятия".
если ты начинаешь нести чушь, не жди, что тебя за это приголубят.

Здравствуйте, neFormal, Вы писали:

НС>>https://www.youtube.com/watch?v=Vt98pqsddLM
F>Progress DataDirect Cloud — молодцы. только OData тут ни при чём.

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

F>ты даже не смотришь то, что присылаешь.

Или ты не читаешь что я пишу.

F>да меня как-то не заботят "форумные понятия".

Это не форумные понятия, это суть. Переход на личности означает, что аргументов у тебя нет, а возразить хочется. http://www.jvanetsky.ru/data/text/t7/stili_spora/

Здравствуйте, neFormal, Вы писали:

F>аа, так ты посраться сюда пришёл.
Кто бы мог подумать! И давно в КСВ ходят за чем то другим?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Это не форумные понятия, это суть. Переход на личности означает, что аргументов у тебя нет, а возразить хочется. http://www.jvanetsky.ru/data/text/t7/stili_spora/
Ты первый начал:

OData это просто протокол. А уж откуда и как наполнены источники данных, для которых он используется, это уже вопросы реализации. Но я понял, OData это недостаточно хипстерски.

Re[5]: GraphQL -- взлетит или помрет?

Автор: Ночной Смотрящий
Дата: 29.07.17

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>О чем я тебе несколько раз уже писал.

похоже, ты ещё и лжец.

НС>OData это протокол, источники данных это дело конкретной реализации. В саом протоколе ограничений на источники нет.-

т.е. ты не понимаешь, о чём речь, но мнение имеешь. Ч.Т.Д.

F>>да меня как-то не заботят "форумные понятия".
НС>Это не форумные понятия, это суть. Переход на личности означает, что аргументов у тебя нет, а возразить хочется. http://www.jvanetsky.ru/data/text/t7/stili_spora/

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

Здравствуйте, WolfHound, Вы писали:

WH>Ты первый начал:

Нет.

WH>

WH>OData это просто протокол. А уж откуда и как наполнены источники данных, для которых он используется, это уже вопросы реализации. Но я понял, OData это недостаточно хипстерски.

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

Здравствуйте, neFormal, Вы писали:

НС>>О чем я тебе несколько раз уже писал.
F>похоже, ты ещё и лжец.

В ход пошел весь арсенал демагогии?
Re[5]: GraphQL -- взлетит или помрет?

Автор: Ночной Смотрящий
Дата: 29.07.17

OData это просто протокол. А уж откуда и как наполнены источники данных, для которых он используется, это уже вопросы реализации.

F>т.е. ты не понимаешь, о чём речь, но мнение имеешь. Ч.Т.Д.

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

F>тем не менее, это не переход на личности, а констатация факта

Это самый натуральный переход на личности. Аргументов строго ноль во всех твоих сообщениях, зато хамства хоть отчерпывай.

Здравствуйте, Ночной Смотрящий, Вы писали:

WH>>

WH>>OData это просто протокол. А уж откуда и как наполнены источники данных, для которых он используется, это уже вопросы реализации. Но я понял, OData это недостаточно хипстерски.

НС>Здесь нет перехода на личность, здесь личность собеседника не упоминается, ни прямо, ни косвенно.
Тут ты назвал всех пользователей GraphQL и neFormal'а в частности хипстерами.
На что neFormal назвал пользователей OData старпёрами.
Вы тут оба хороши. Но ты начал первым.

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

Здравствуйте, WolfHound, Вы писали:

НС>>Здесь нет перехода на личность, здесь личность собеседника не упоминается, ни прямо, ни косвенно.
WH>Тут ты назвал всех пользователей GraphQL и neFormal'а в частности хипстерами.

Не пользователей, а разработчиков. Не пользователи же cабж свелосипедили.

WH>На что neFormal назвал пользователей OData старпёрами.

Да и фик бы с ним. Переход на личности был не там.

WH>Короче предлагаю вам обоим сбавить обороты и перейти к обсуждению технических деталей.

А я обороты и не набирал. Но на любые мои ответы возвращается очередной поток хамства с кучей эпитетов касательно меня лично.

Здравствуйте, Ночной Смотрящий, Вы писали:

\НС>>>О чем я тебе несколько раз уже писал.
F>>похоже, ты ещё и лжец.
НС>В ход пошел весь арсенал демагогии?
НС>Re[5]: GraphQL -- взлетит или помрет?

Автор: Ночной Смотрящий
Дата: 29.07.17

НС>

НС>OData это просто протокол. А уж откуда и как наполнены источники данных, для которых он используется, это уже вопросы реализации.

ещё и считать не умеешь. о, боги!

F>>тем не менее, это не переход на личности, а констатация факта
НС>Это самый натуральный переход на личности. Аргументов строго ноль во всех твоих сообщениях, зато хамства хоть отчерпывай.

сам начал теперь хлебай полной ложкой.

F>>т.е. ты не понимаешь, о чём речь, но мнение имеешь. Ч.Т.Д.
НС>Давай поподробнее, поясни что именно я не понимаю и почему ты так решил. И, желательно, без перехода на личности.

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

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Вот только это ты и велосипедеры из фейсбучека не знали про OData. Причем это, судя по всему, принципиальная позиция у хипста-стайл архитектов — существующие решения всегда плохие, и все надо делать с нуля.

Не понимаю сакральности "использования всего готового". Использование готового тоже не бесплатно в терминах денег/времени/качества, и разница вообще может оказаться на уровне погрешности (относительно стоимости всего проекта). И если так, то не всё ли равно, велосипед или тщательно подобранное "готовое" решение?

Это ещё при том, что GraphQL, на мой взгляд, сильно проще и, соответственно, ближе к массам.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>А в OData чего, найден фатальный недостаток?

По-моему, OData немного про другое

. OData больше про запросы к коллекциям данных. Например, в OData предлагается стандартные механизмы фильтрации и постраничной выборки, что накладывает определённые ограничения.

Но в каких-то случаях (потенциально бесконечные коллекции) будет удобнее делать постраничную выборку по какому-то сквозному параметру, типа timestamp, а не по сквозному номеру объекта.

В GraphQL ты легко реализуешь такой API, например, запрос будет выглядеть типа "Events(after: 8971267324) { name, after }".

На мой взгляд, GraphQL больше подходит именно для API (для современных хипстерских API, что бы это ни значило). Это чуть-чуть более высокая абстракция, чем в случае REST или JSON/RPC, но при этом практически не накладывающая каких-то новых ограничений.


Плюс, субъективно, OData в плане языка запросов и формата ответов -- это ужас какой-то, в лучших традициях XML.

Я потратил аж 10 минут на изучение OData. Но этого же достаточно для этого форума, да?

Здравствуйте, Arsen.Shnurkov, Вы писали:

AS>И вот однажды ты разговариваешь с дизайнером, весь из себя с десятилетним опытом C++,
AS>а она тебя спрашивает "ну ты хотя бы на php-то писать умеешь?"

Ну тут только пойти застрелится, как можно самого ДИЗАЙНЕРА разочаровать?

Здравствуйте, CreatorCray, Вы писали:

CC>Такие претензии мне напоминают дельфистов: да вот мы форму за пять минут накидаем мышкой, а сколько вам на ваших Си такое же клепать?

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

CC>Если есть готовые примитивы — на любом языке пишется быстро.

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

Здравствуйте, Иван Дубров, Вы писали:

НС>>Вот только это ты и велосипедеры из фейсбучека не знали про OData. Причем это, судя по всему, принципиальная позиция у хипста-стайл архитектов — существующие решения всегда плохие, и все надо делать с нуля.

ИД>Не понимаю сакральности "использования всего готового". Использование готового тоже не бесплатно в терминах денег/времени/качества, и разница вообще может оказаться на уровне погрешности (относительно стоимости всего проекта). И если так, то не всё ли равно, велосипед или тщательно подобранное "готовое" решение?

Спасибо за иллюстрацию моих слов.

Здравствуйте, Иван Дубров, Вы писали:

ИД>По-моему, OData немного про другое

Ровно про то же. В деталях, разумеется, отличия есть.

ИД>Плюс, субъективно, OData в плане языка запросов и формата ответов -- это ужас какой-то, в лучших традициях XML.

OData запросы обычно руками не пишут, в коде это просто лямбда.

Здравствуйте, Иван Дубров, Вы писали:



ИД>Плюс, субъективно, OData в плане языка запросов и формата ответов -- это ужас какой-то, в лучших традициях XML.

ИД>

Я потратил аж 10 минут на изучение OData. Но этого же достаточно для этого форума, да?

Так для информации
Linq to ODATA

Очень близко к Linq to EF.
Ну и ODATA поддерживает JSON

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Спасибо за иллюстрацию моих слов.

Всё-таки есть разница между "существующие решения всегда плохие" (то, что ты сказал) и "в терминах сроков, денег и качества существующие решения не обязательно дают (большую) выгоду" (то, что я пытаюсь донести).

Здравствуйте, Serginio1, Вы писали:

S>Так для информации
S>Linq to ODATA

S> Очень близко к Linq to EF.
S> Ну и ODATA поддерживает JSON

Именно эта попытка представить сервер как какую-то базу данных меня и смущает. Не все запросы, которые имеют смысл при доступе к СУБД могут иметь смысл при доступе к API. Хочется в API выставлять только те обязательства, которые я готов соблюдать. Вот не хочу я давать возможность сортировать по заданному полю, и всё (потому что глобализация -- это очень сложно и я не хочу усложнять сервис).

Здравствуйте, Иван Дубров, Вы писали:

ИД>... Вот не хочу я давать возможность сортировать по заданному полю, и всё (потому что глобализация -- это очень сложно и я не хочу усложнять сервис).
ЕМНИП, все это настраивается при реализации сервиса OData

Здравствуйте, Иван Дубров, Вы писали:

ИД>Здравствуйте, Serginio1, Вы писали:

S>>Так для информации
S>>Linq to ODATA

S>> Очень близко к Linq to EF.
S>> Ну и ODATA поддерживает JSON

ИД>Именно эта попытка представить сервер как какую-то базу данных меня и смущает. Не все запросы, которые имеют смысл при доступе к СУБД могут иметь смысл при доступе к API. Хочется в API выставлять только те обязательства, которые я готов соблюдать. Вот не хочу я давать возможность сортировать по заданному полю, и всё (потому что глобализация -- это очень сложно и я не хочу усложнять сервис).

Глобализация на сервере SQL.
ODATA это прежде всего Rest интерфейс к базе данных.
И автоматческая генерация прокси классов, по аналогии с EF.


Если у тебя свой движок, то игнорируй. В чем проблема?

Здравствуйте, Shmj, Вы писали:

S>Что скажете?

С разморозкой. У нас тут много интересного произошло за последние 10 лет!

Здравствуйте, Иван Дубров, Вы писали:

ИД>Всё-таки есть разница между "существующие решения всегда плохие" (то, что ты сказал) и "в терминах сроков, денег и качества существующие решения не обязательно дают (большую) выгоду" (то, что я пытаюсь донести).

Главное, что нет разницы в результате

Здравствуйте, Serginio1, Вы писали:

S>Если у тебя свой движок, то игнорируй. В чем проблема?

В том что у OData "в терминах сроков, денег и качества существующие решения не обязательно дают (большую) выгоду". Проще говоря, найден фатальный недостаток.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>В том что у OData "в терминах сроков, денег и качества существующие решения не обязательно дают (большую) выгоду". Проще говоря, найден фатальный недостаток.

А что ещё кроме денег, сроков и качества должно волновать коммерческую компанию?

Тем более, что Facebook-у-то уж точно выгоднее всех нагнуть под себя. Причём им даже на обучение тратиться особо не надо -- всё сами разнесут и в блогах напишут.

Здравствуйте, Иван Дубров, Вы писали:

ИД>Тем более, что Facebook-у-то уж точно выгоднее всех нагнуть под себя. Причём им даже на обучение тратиться особо не надо -- всё сами разнесут и в блогах напишут.

Да при чем здесь гнуть ? Фремворки крайне трдны в разработке, тестировании, майнтенансе. Единственный способ побороть эту проблему — привлечь людей, которые сами по своей инициативе будут помогать.

Тебя же никто с пистолетом не заставляет использовать фейсбучные технологии. Пиши на чем хошь. Но вот мулька в том, что эпоха самопальных фремворков закончилась. Практически каждый доморощенный фремворк это какая то содомия. Единицы заслуживают какого то внимания. Соответственно гнёт не фейсбук — гнёт рынок.

Здравствуйте, Иван Дубров, Вы писали:

ИД>Не понимаю сакральности "использования всего готового". Использование готового тоже не бесплатно в терминах денег/времени/качества, и разница вообще может оказаться на уровне погрешности (относительно стоимости всего проекта). И если так, то не всё ли равно, велосипед или тщательно подобранное "готовое" решение?

Теоретически ты прав. Но в эту модель надо вписать рынок труда и перспективы развития. А дела здесь обстоят крайне плачевно — ИТ индустрия интенсивно поглощает необученый контингент. Уже есть ПТУ где учат паре-тройке алгоритмов уровня сортировок, пхп, sql и, вуаля, новый девелопер пытается потрясти мир и оставить вмятину во вселенной.

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

Здравствуйте, Ikemefula, Вы писали:

I>Уже есть ПТУ где учат паре-тройке алгоритмов уровня сортировок, пхп, sql и, вуаля, новый девелопер пытается потрясти мир и оставить вмятину во вселенной.

из вузов приходят такие же.
а где взять лучше?

DoS'ить новые сайты на GraphQL как удобно теперь будет! Через малюсенькую дырочку, запросом вида "... в доме который построил джек ...", можно будет жёстко бак-энд в медитацию отправить, и никакой CloudFlare не спасёт Что характерно для нашего века — спасаться от проблемы "специалисты" предлагают таймаутами

Здравствуйте, hi_octane, Вы писали:

_>DoS'ить новые сайты на GraphQL как удобно теперь будет! Через малюсенькую дырочку, запросом вида "... в доме который построил джек ...", можно будет жёстко бак-энд в медитацию отправить, и никакой CloudFlare не спасёт Что характерно для нашего века — спасаться от проблемы "специалисты" предлагают таймаутами

Жёстко не получится, только мягко. Все запросы в GraphQL -- это то, что сервер тебе на выбор предлагает, à la carte.

То есть можно, конечно, делать что-нибудь вроде:

{
 p1: Policy(id = xxx)
 p2: Policy(id = xxx)
 ...
 p1000000: Policy(id = xxx)
}

Т.е запросить какое-то поле много-много раз.

Или так:

{
  Policy { Vehicles { Driver { Vehicle { Driver { Vehicle { Name }...}
}

Т.е по циклу в данных прогуляться.

В обоих случаях ещё и объём запроса вырастет, что позволит заблокировать его, если он не укладывается в лимиты. Плюс клиенту нужно пропорционально больше работы сделать, чтобы как-то нагрузить сервер.


Вот, пожалуй, и всё. Все остальные способы, которые приходят в голову, например, большие постраничные выборки, будут ровно так же применимы и к эндпоинтам другого типа, будь то REST или SOAP или что-то другое.

ИД>Жёстко не получится, только мягко. Все запросы в GraphQL -- это то, что сервер тебе на выбор предлагает, à la carte.
Ага, и на первой же демке с фильмами и актёрами пишем: "Получить Все Фильмы / Получить всех актёров в них / Получить Все Фильмы В которых Снимался Актёр / Всех Актёров в этих фильмах / ... / Тыдыщ"

Здравствуйте, hi_octane, Вы писали:

_>Ага, и на первой же демке с фильмами и актёрами пишем: "Получить Все Фильмы / Получить всех актёров в них / Получить Все Фильмы В которых Снимался Актёр / Всех Актёров в этих фильмах / ... / Тыдыщ"

Да, ты прав. Так можно.

Это аргумент за то, чтобы не выставлять внутреннюю схему данных "как есть". Как вариант, тип "актёр-внутри-фильма" не должен иметь поле "фильмы в которых снимался актёр".

_>>Ага, и на первой же демке с фильмами и актёрами пишем: "Получить Все Фильмы / Получить всех актёров в них / Получить Все Фильмы В которых Снимался Актёр / Всех Актёров в этих фильмах / ... / Тыдыщ"
ИД>Да, ты прав. Так можно.
ИД>Это аргумент за то, чтобы не выставлять внутреннюю схему данных "как есть". Как вариант, тип "актёр-внутри-фильма" не должен иметь поле "фильмы в которых снимался актёр".

Для разумной реализации этой схемы фронт-ендщик должен работать на пару с бэк-ендщиком да ещё и оба иметь какие-то задатки хакера чтобы предвидеть где нужно создавать тип "актёр-внутри-фильма" а где нет. По итогу умственной (и заодно рукопашной) работы становится не меньше (чего хочется от любой новой технологии), а больше. И квалификация обоих нужна уровнем повыше чем ваять 100500-й типовой REST-метод размером в один linq запрос. В Facebook, не спорю, даже уборщица будет подходящего уровня, а для остальных компаний этот GraphQL пока выглядит как культ карго и кактус бесконечной высоты.
Вот если залепят какие-нить аттрибуты на все основные бэк-энды, типа "MaxQueryDepth=2", тогда можно будет говорить о зрелости технологии. Пока основные советы пропагандистов заставляют делать И это при том что самой технологии уже года 3.

Здравствуйте, hi_octane, Вы писали:

_>DoS'ить новые сайты на GraphQL как удобно теперь будет! Через малюсенькую дырочку, запросом вида "... в доме который построил джек ...", можно будет жёстко бак-энд в медитацию отправить, и никакой CloudFlare не спасёт Что характерно для нашего века — спасаться от проблемы "специалисты" предлагают таймаутами

Вы как-то преувеличиваете автоматичность graphql. Думаете оно вам сразу даст произвольные джойны делать? )
На самом grpahql — это простой вызов функции, только с возможностью возвращать не все поля результата, а только те что попросит клиент.
Т.е. оно позволяет только уменьшить набор полей который возвращается на клиента, по сравнению с тем что предусмотрел разработчик бэкенда.

Если же на бэкенде предусмотрен запрос котороый позвовляет заддосить сервер — то какая разница graphql он или json-rpc или soap?

КБ>Вы как-то преувеличиваете автоматичность graphql. Думаете оно вам сразу даст произвольные джойны делать? )

Таки думаю да — полсотни форков, под 800 звёзд, в общем взлетает У них там сейчас спец-олимпиада идёт, кто больше возможностей искаропки добавит. Основной лозунг самого Фэйсбука: "Fetching all the data for a view hierarchy.", и гуру с SO не отстают: "Purpose of using GraphQL is to provide a schema over your entire application data to allow fetching it in a single roundtrip". Да и фронт-ендщикам проще — хорошая база, GraphQL движок, и бак-энд для всяких CRUD становится как бы и не нужен.

Здравствуйте, neFormal, Вы писали:

I>>Уже есть ПТУ где учат паре-тройке алгоритмов уровня сортировок, пхп, sql и, вуаля, новый девелопер пытается потрясти мир и оставить вмятину во вселенной.

F>из вузов приходят такие же.
F>а где взять лучше?

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

Здравствуйте, Shmj, Вы писали:

S>Вот сейчас идет массированная пропоганда GraphQL. Как я понял, он позиционируется как замена REST и теперь API нужно писать на нем.

S>Что скажете?

Вот сравнение
REST API Industry Debate: OData vs GraphQL vs ORDS

Здравствуйте, Shmj, Вы писали:
S>Вот сейчас идет массированная пропоганда GraphQL. Как я понял, он позиционируется как замена REST и теперь API нужно писать на нем.

imho
если нужно написать какой-нить несложный, но необычный запрос, например специфичный для субд,
то никакой orm и gprahql не спасёт, а наоборот всё усложнит,
эти штуки нужны не для бэкенда, а наверное для того, чтобы фронтенд не мешал бэкенду работать,
фулстэк разработчику проще обычные запросы писать