Я пока не вижу особых достоинств у этой технологии.
За то, чтобы фронтенд получал меньший объем данных, идет довольно высокая плата в виде QL в URI, а на бекенде и вовсе не понятно что получается. Либо это постоянно гоняется сложный запрос и выгребает все данные из базы и внешних сервисов, либо прячется за какой-то монстроузорный механизм по работе с базой, как кто-то говорил в этом треде, – адаптеры GraphQL к ORM.
По-моему, крайне небольшое преимущество. И скорее всего, это все будет работать хорошо только в случае: JS -> NodeJS + MongoDB, А в других случаях – от этой технологии будет больше проблем, чем пользы.
У Вконтакте есть API вида: /api/user.get?user_id=34124123&fields=name,age,email
/api/friends.get?user_id=34124123&limit=30
Это однозначно не REST, это некий HTTP/WEB API, альтернативно можно назвать RPC.
Учитывая, что бекенду нужно все так же делать маппинг и создавать все ту же схему данных ( как сказал zelenin в https://habrahabr.ru/post/335158/?reply_to=10351014#comment_10350990 ), то получается, что не так уж это и гибко, как вы говорите.
Если в модели нету дополнительных полей, бекенду нужно будет их добавлять (расширять схему).
т.е. GraphQL – это просто специфичный формат запроса, который в себе будет содержать схему для ответа? и как сказал alibertino, при этом бекенд должен предоставлять конкретную схему ответа.
правильно ли я понимаю, что у бекенда есть своя модель, а GraphQL лишь говорит, какие данные из той модели нужно отдать клиенту?
просто не закладывайте в схему GraphQL таких возможностей.
Спасибо, это уже звучит как ответ.
т.е. GraphQL подразумевает, что бекенд будет предоставлять какую-то конкретную схему ответа?
Если так, то это не сильно отличается от какого-то простого HTTP/WEB API, и отличие только в том, что в ответ приходит ограниченный набор данных.
Отличный ответ из разряда: «Проблема на вашей стороне» ;-)
Конкретная проблема:
Есть Книги, есть Автора, есть Комментарии к книгам, все это в разных таблицах.
Через GraphQL делается 2 запроса на книгу с bookId:
1. запрос на книгу + автора книги
2. запрос на книгу + автора + комменты
Я вижу 3 варианта реализации на бекенде:
1. делать маппинг «в лоб» (как показано в статье), это будет 2 запроса к базе в первом случае и 3 во втором.
2. делать «оптимизацию», то получим 1 большой запрос и в маппинге просто результаты будем разгребать.
но в этом случае будет сложный запрос как в случае с комментами, так и без них. Это тоже плохо.
3. делать «по-умному», но это будет очень сложная логика по созданию запроса к базе, грубо говоря, нужно будет сделать конвертор «GraphQL to SQL» для конкретного проекта и любое небольшое изменение будет требовать большого объема работ.
Я не силен в GraphQL особенно со стороны бекенда, потому мне интересно: как это должно быть? Какой подход правильный?
Из всех статей про GraphQL я видел только радостные отзывы, как это удобно для фронтенда и ни разу не видел примеров как это выглядит со стороны бекенда.
Вы можете подсказать, как это должно быть на стороне бекенда? У вас есть с этим опыт?
GraphQL невероятно вкусно выглядит со стороны фронтенда, когда тебе нужно вытащить конкретные поля и это можно сделать за 1 запрос к серверу!
Facebook API – отличный пример работы GraphQL.
Но лично для меня так и не понятно, как же это все будет работать на стороне сервера.
В статье приведены два примера уровня Hello World, где все элементарно просто и красиво.
Но как это будет в случае, когда запрос должен будет выгребать данные из Реляционной СУБД (Postgres)?
К примеру все тот же элементарный пример: Books + Author + Comments.
В моем представлении, для реализации этого подхода на стороне сервера начинается полная вакханалия. Нужно отдать информации про автора из одной таблицы, про книгу из другой, а про комменты из третьей.
А это значит, что нужно сделать 3 запроса к СУБД для того. Или это нормально?
Если попробовать оптимизировать и сразу доставать все, то можем нарваться на ситуацию, что фронтенд не запрашивал этих данных, а значит на базу будет идти лишняя нагрузка.
По-моему, вы промазали с комментом. Я не агитировал ни за какой язык в этом треде. А то, что вы написали для меня вообще крайне дико выглядит. Уж извините, но я лишь выразил мысль, что перегрузка операторов – это фича которая усложняет понимание и последующую поддержку кода в случаях, когда используется для «это прикольно выглядит».
И в реальности перегрузка операторов нужна лишь в крайне редких случаях.
Да, я не отрицаю этого. Но согласитесь, что без этой «замечательной» особенности поддержка становится проще.
На счет функций, немного проще: тут есть есть правило хорошего стиля – не использовать одинаковый порядок параметров внутри одного класса / библиотеки.
А на счет операторов — тут сложнее. тут все зависит от того, как каждый из классов реализует свою логику перегрузки: т.е. смотреть уже нужно будет сразу в нескольких местах.
Поясните. Я вот ощущаю гораздо больше боли от её отсутствия в некоторых языках.
Я не знаю позицию почему это не нравится pawlo16, но в том, что это не самая лучшая фича, я с ним полностью согласен.
Это крутая фича, она позволяет сократить код и позволяет сделать его «красивее» для некоторых очень узких задач. Но, когда вопрос заходит про поддержку проекта, тут начинается боль. Оператор + может быть перегружен несколькими способами и то, какой из них будет вызван, зависит от порядка операндов, если они отличаются по типу.
Это увеличивает количество возможных путей выполнения кода и количество нюансов при написании и поддержке.
лично мое мнение: язык должен быть таким, чтобы проект на нем можно было легко поддерживать, т.к. большую часть жизни проекта занимает фаза поддержки.
Да, вывести продукт на рынок как можно быстрее – это очень важно, но обеспечивать легкую поддержку на протяжении его жизни, – это еще важнее.
Тут дело в другом: JS на столько полиморфный язык, что на этой базе можно разработать десятки стилей написания кода.
В столь не постоянной и хаотечиской среде есть только 2 способа получить знания: Потыкать самому и Почитать статью, в которой кто-то рассказывает про свой опыт потыкать.
Соответственно, любые книги по JS в этом скоростном «хаосе» бесполезны. Пока кто-то напишет книгу, она уже успеет 2 раза устареть. А к тому времени, когда сделают перевод, книга будет похожа на «история первобытных людей».
Потому и черпают знания из статей и маркетинговых презентаций, т.к. больше нету откуда.
Воу-воу-воу! Если будут логи – это уже признак, что не все потеряно ;-)
Из тех JS команд, с которыми/в которых я работал практически все негативно относятся к логгированию, мотивируя тем, что «есть же дебаггер, зачем нам логи писать? может еще аллертами дебажить?».
А учитывая, что эти же ребята хотят писать бекенды на JS, то и про логгирование может будет забыть; хотя, если какой-то airbnb напишет статью о том, что писать логи — это хорошо, тогда и логи будут)))
С этим тоже проблем нету, строка подключения берется из файла конфигураций.
А приведенный пример «проблемы», спокойно решается путем NuGet (composer в мире PHP). Так что уверяю вас, это надуманная проблема.
Даже строку в готовом виде не получить, только отдельные поля читать.
На самом деле,
reader
это и есть Строка из из базы, вы к ней потом обращаетесь, чтобы взять нужные поля. И если я не ошибаюсь, есть синтаксис по-проще:
reader["name"]
Даже если не обращать внимания, что код отличается по смыслу, можно заметить, что особых проблем нету. Да, есть небольшое неудобство с тем, чтобы закинуть параметры по одному, а в остальном – практически идентичный код.
Или на 2 строчки больше кода – это для вас большая проблема?
За то, чтобы фронтенд получал меньший объем данных, идет довольно высокая плата в виде QL в URI, а на бекенде и вовсе не понятно что получается. Либо это постоянно гоняется сложный запрос и выгребает все данные из базы и внешних сервисов, либо прячется за какой-то монстроузорный механизм по работе с базой, как кто-то говорил в этом треде, – адаптеры GraphQL к ORM.
По-моему, крайне небольшое преимущество. И скорее всего, это все будет работать хорошо только в случае: JS -> NodeJS + MongoDB, А в других случаях – от этой технологии будет больше проблем, чем пользы.
Но, поживем, увидим.
/api/user.get?user_id=34124123&fields=name,age,email/api/friends.get?user_id=34124123&limit=30
Это однозначно не REST, это некий HTTP/WEB API, альтернативно можно назвать RPC.
Если в модели нету дополнительных полей, бекенду нужно будет их добавлять (расширять схему).
GraphQL<->NodeJs<->"REST"<->PHP<-><->Doctrine<->SQL"Web API"<->PHP<-><->Doctrine<->SQLв данном случае, Web API делает все то же, что делал бы с GraphQL, только без «QL» в URI запроса.
В чем тогда преимущество перед обычным «Web API»?
правильно ли я понимаю, что у бекенда есть своя модель, а GraphQL лишь говорит, какие данные из той модели нужно отдать клиенту?
т.е. GraphQL подразумевает, что бекенд будет предоставлять какую-то конкретную схему ответа?
Если так, то это не сильно отличается от какого-то простого HTTP/WEB API, и отличие только в том, что в ответ приходит ограниченный набор данных.
Конкретная проблема:
Есть Книги, есть Автора, есть Комментарии к книгам, все это в разных таблицах.
Через GraphQL делается 2 запроса на книгу с bookId:
1. запрос на книгу + автора книги
2. запрос на книгу + автора + комменты
Я вижу 3 варианта реализации на бекенде:
1. делать маппинг «в лоб» (как показано в статье), это будет 2 запроса к базе в первом случае и 3 во втором.
2. делать «оптимизацию», то получим 1 большой запрос и в маппинге просто результаты будем разгребать.
но в этом случае будет сложный запрос как в случае с комментами, так и без них. Это тоже плохо.
3. делать «по-умному», но это будет очень сложная логика по созданию запроса к базе, грубо говоря, нужно будет сделать конвертор «GraphQL to SQL» для конкретного проекта и любое небольшое изменение будет требовать большого объема работ.
Я не силен в GraphQL особенно со стороны бекенда, потому мне интересно: как это должно быть? Какой подход правильный?
Из всех статей про GraphQL я видел только радостные отзывы, как это удобно для фронтенда и ни разу не видел примеров как это выглядит со стороны бекенда.
Вы можете подсказать, как это должно быть на стороне бекенда? У вас есть с этим опыт?
+ А как работать в ситуации, когда у тебя часть данных должны придти с внешнего сервиса? к примеру: геолокация или какие-то инвентори/прайсы т.д.
Facebook API – отличный пример работы GraphQL.
Но лично для меня так и не понятно, как же это все будет работать на стороне сервера.
В статье приведены два примера уровня Hello World, где все элементарно просто и красиво.
Но как это будет в случае, когда запрос должен будет выгребать данные из Реляционной СУБД (Postgres)?
К примеру все тот же элементарный пример: Books + Author + Comments.
В моем представлении, для реализации этого подхода на стороне сервера начинается полная вакханалия. Нужно отдать информации про автора из одной таблицы, про книгу из другой, а про комменты из третьей.
А это значит, что нужно сделать 3 запроса к СУБД для того. Или это нормально?
Если попробовать оптимизировать и сразу доставать все, то можем нарваться на ситуацию, что фронтенд не запрашивал этих данных, а значит на базу будет идти лишняя нагрузка.
И в реальности перегрузка операторов нужна лишь в крайне редких случаях.
– пример взят из опыта работы с .NET, и вот даже в документации есть:
https://msdn.microsoft.com/en-us/library/aa645739(v=vs.71).aspx
~ – Побитовая инверсия, это унарный оператор.
~= – такого не существует (по крайней мере в Си).
вот так было бы правильнее:
Но это требует неплохой подготовки для понимания. Сейчас далеко не все разбираются в побитовых операциях.
Но вот с удалением тогда не получится так просто и красиво.
А вот когда начинают переопределять операторы просто, потому, что это прикольнее выглядит – это уже не особо круто, по-моему.
по-моему второй вариант выглядит понятнее, чем первый.
Оно может быть и будет понятнее со временем (человек привыкает ко всему), но по началу это будет выглядеть очень дико.
А если учесть, что так пишутся и другие API, типа «клево же», то эта фича принесет больше вреда, чем пользы.
Хороший код должен вызывать минимум удивления и минимум WTF?
На счет функций, немного проще: тут есть есть правило хорошего стиля – не использовать одинаковый порядок параметров внутри одного класса / библиотеки.
А на счет операторов — тут сложнее. тут все зависит от того, как каждый из классов реализует свою логику перегрузки: т.е. смотреть уже нужно будет сразу в нескольких местах.
Это крутая фича, она позволяет сократить код и позволяет сделать его «красивее» для некоторых очень узких задач. Но, когда вопрос заходит про поддержку проекта, тут начинается боль. Оператор + может быть перегружен несколькими способами и то, какой из них будет вызван, зависит от порядка операндов, если они отличаются по типу.
Это увеличивает количество возможных путей выполнения кода и количество нюансов при написании и поддержке.
лично мое мнение: язык должен быть таким, чтобы проект на нем можно было легко поддерживать, т.к. большую часть жизни проекта занимает фаза поддержки.
Да, вывести продукт на рынок как можно быстрее – это очень важно, но обеспечивать легкую поддержку на протяжении его жизни, – это еще важнее.
хотя, за мои 5 лет в java мире на проектах различной сложности, я еще ни разу не сталкивался с этой проблемой.
Тут дело в другом: JS на столько полиморфный язык, что на этой базе можно разработать десятки стилей написания кода.
В столь не постоянной и хаотечиской среде есть только 2 способа получить знания: Потыкать самому и Почитать статью, в которой кто-то рассказывает про свой опыт потыкать.
Соответственно, любые книги по JS в этом скоростном «хаосе» бесполезны. Пока кто-то напишет книгу, она уже успеет 2 раза устареть. А к тому времени, когда сделают перевод, книга будет похожа на «история первобытных людей».
Потому и черпают знания из статей и маркетинговых презентаций, т.к. больше нету откуда.
Из тех JS команд, с которыми/в которых я работал практически все негативно относятся к логгированию, мотивируя тем, что «есть же дебаггер, зачем нам логи писать? может еще аллертами дебажить?».
А учитывая, что эти же ребята хотят писать бекенды на JS, то и про логгирование может будет забыть; хотя, если какой-то airbnb напишет статью о том, что писать логи — это хорошо, тогда и логи будут)))
Но это уже выходит за рамки «простого для понимания», так что это точно не в тему.
А приведенный пример «проблемы», спокойно решается путем NuGet (composer в мире PHP). Так что уверяю вас, это надуманная проблема.
На самом деле, это и есть Строка из из базы, вы к ней потом обращаетесь, чтобы взять нужные поля. И если я не ошибаюсь, есть синтаксис по-проще:
Даже если не обращать внимания, что код отличается по смыслу, можно заметить, что особых проблем нету. Да, есть небольшое неудобство с тем, чтобы закинуть параметры по одному, а в остальном – практически идентичный код.
Или на 2 строчки больше кода – это для вас большая проблема?