Здравствуйте, 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.
МД>Неважно что, но главное запилить чтото новое.
У них есть определенная цель и они идут к ней. Представь, что ты искуственный интеллект фейсбука и вокруг тебя сайты говорящие с тобой на одном языке, твоем языке — разве не достойная цель.
МД>Чем старое то всё не устраивает?
А старого то и нет. Раньше ни один сайт не разговаривал на языке понятном роботам фейсбука.
Здравствуйте, _Raz_, Вы писали:
_R_>Здравствуйте, Мёртвый Даун, Вы писали:
МД>>Немного оффтопа. Объясните эту нездоровую тягу к изобретательству?
_R_>Изобретательство тут ни при чем. Это здоровая тяга к деньгам в Facebook Inc.
Меня почему то воспитывали, что тяга к деньгам — это уже само по себе нездоровое явление.
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
Здравствуйте, Мёртвый Даун, Вы писали:
_R_>>Изобретательство тут ни при чем. Это здоровая тяга к деньгам в Facebook Inc. МД>Меня почему то воспитывали, что тяга к деньгам — это уже само по себе нездоровое явление.
Здравствуйте, Masterspline, Вы писали:
M>Язык запросов к сайтам. Если стандартный REST что-то типа "дай мне 10-ю запись из таблицы 'статьи'", то GraphQL позволяет делать запросы типа SQL "дай мне 10 M> последних записей из таблицы 'статьи' столбцы 'название' и 'автор' и добавь для каждой статьи массив комментариев с полями 'текст', 'автор' и 'дата', а также добавь отдельный список последних 5-ти постов на форум". Это все в виде одного запроса.
Здравствуйте, 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, плюсовик будет пилить неделю, а потом еще три отлаживать.
Такие претензии мне напоминают дельфистов: да вот мы форму за пять минут накидаем мышкой, а сколько вам на ваших Си такое же клепать?
Если есть готовые примитивы — на любом языке пишется быстро.
А чё ты у меня-то спрашиваешь? Я тут всего-лишь отвечаю на вопросы людей, которые гуглить и читать не умеют не хотят.
Про 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 это недостаточно хипстерски.
