В чем преимущества использование GraphQL чем ручками?

Question

[lukoie]

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

Answer 1

[Сергей Горностаев]

Первая же ссылка в Google по запросу "GraphQL REST" - Сравнение REST и GraphQL. В конце статьи перечислены теги, если клацнуть по тегу "graphql" вывалится ещё 40 подобных публикаций.

Только я не понимаю, почему вы противопоставляете соглашение о форме обмена данными GraphQL с написанием "API ручками". Неважно, какая форма обмена у вас выбрана - SOAP, REST, GraphQL, обработчики запросов всё равно придётся писать, автоматом за вас никто ничего не сделает.

Comments

[lukoie]

Только я не понимаю, почему вы противопоставляете соглашение о форме обмена данными GraphQL с написанием "API ручками

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

За написание обработчиков запросов речи не идет. Та даже визуально можно наклацать, не суть важно. Я спрашивал о преимуществе именно Граф перед обычным самодельным рестом. Со своими роутами, придуманной логикой.
Если у меня 2 с половиной запроса, и их можно на коленке сделать, что мне может дать Граф, почему бы лучше внедрять именно граф, а не делать рест-самодеятельность?

[Сергей Горностаев]

lukoie, рест - ровно такая же стандартизированная методология. Разница только в том, что в рест описываешь эндпоинты, а в графе типы и запросы.

[lukoie]

Сергей Горностаев, согласно даже рекомендованных Вами же статей, при разработке рестфул апи, ты сам придумываешь логику, а граф через себя пропускает запросы. Потому посторонний разработчик при рест будет сначала долго втыкать как оно работает, а при графе - просто начнет работу, т.к. всё будет понятно.
собственно, примерно про это я и говорил вначале. Но если по апи надо отдавать только 2-3 значения, у графа все равно останется какое-то преимущество?

[Сергей Горностаев]

lukoie, вам стоит попробовать написать простой сервис на том и на другом. Это отнимет минут 15-20, но даст возможность осознать, что разницы для разработчика почти нет, объём работы и выполняемые действия практически идентичны.

[lukoie]

Сергей Горностаев, я понимаю что ПРАКТИЧЕСКИ. потому и спрашиваю - какие даст преимущество использование именно графа, чтобы делать выбор именно в его пользу?

[Сергей Горностаев]

lukoie, это зависит только от контекста. В контексте работы программистов никаких. В контексте эксплуатации пользователем тоже. Контекст эксплуатации системы зависит от нюансов её реализации, в одних случаях лучше будет REST, в других GraphQL. Однозначного и простого ответа просто не существует. Синтетический пример: Web-сервис позволяющий запрашивать информацию о книгах, авторах и издательствах. В случае использования GraphQL можно сократить количество запросов к сервису, запрашивая и получая информацию о сущности одним куском. С другой стороны, при использовании REST, можно на эндпоинты повесить идемпотентные узкоспециализированные обработчики, которые легче масштабируются и с которыми намного проще использовать кэширование. Что лучше для вашей системы зависит от языка, на котором она написана, платформы, которую она использует, динамики изменения количества запросов, их структуры и множества прочих факторов.

[Alexander Leonchik]

lukoie, от себя напишу плюсы, то что первое на ум пришло

- у тебя один входной url
- автогенерация документации
- валидация типов входящих значений
- количество запросов к серверу значительно меньше (в основном всегда 1)
- все структурировано и не дублируется (типы можно вкладывать друг в друга)
- не нужно объяснять фронтам что и как передавать или что он получит в ответ
- один запрос может вызывать множество преобразователей для построения вложенного ответа с несколькими ресурсами

[Сергей Горностаев]

Alexander Leonchik, это контекстозависимые плюсы. По пунктам:

• Один входной url, значит ты не можешь выделить в отдельный микросервис обработчик тех данных, к которым больше всего запросов и не можешь динамически масштабировать его. Точнее это связано с большим голавняком, чем с REST.
  
• Для REST есть swagger.
  
• ?
  
• Зато обработчик запроса вместо быстрых выборок грузит СУБД тяжёлыми выборками с объединениями. Если СУБД NoSQL, то вообще беда. Ещё хуже, если в половине случаев клиенту нужны только конкретные данные, без связей.
  
• В REST для каждой сущности просто отдельный эндпоинт, тоже никакого дублирования.
  
• Ох, если бы.
  
• Смотрим пункты про тяжелые запросы и невозможность масштабирования.
  

[Сергей Горностаев]

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

[lukoie]

Alexander Leonchik, спасибо. плз, оформите в отдельный ответ. это и будет ответом на мой вопрос.

[batyrmastyr]

lukoie, с полгода назад попробовал почти все имевшиеся библиотеки для php, остался недоволен их тормознутостью и архитектурной кривостью - минимальное время выполнения запроса было 50 мс против 4 - 8 у коробочного yii2 rest, на более нужных запросах выходило 100 - 150 мс против 20 - 30.

Answer 2

[Сергей Рогожкин]

Простыми словами в чем проблема Графа Куэль: https://tonsky.livejournal.com/309037.html