Alexander
а если сравнивать доку то тоже самое
Alexander
ну только источники данных для генерации разные
Alexander
Alexander
продвигают его под видом того что на разные клиенты нужны разные данные от API
Alexander
ну не знаю сколько клиентов надо с разными требованиями чтобы было целесообразно такое использовать
Mike
В реактовом чате его очень любят кст
Alexander
возможно у таких компаний как Facebook такие вопросы очень остро стоят
Pawel
http://tonsky.livejournal.com/309037.html - складно глаголит про это дело
Aleksandr
продвигают его под видом того что на разные клиенты нужны разные данные от API
несовсем так. решаются все проблемы практически, которые есть у rest-оподобных api. Основная суть: можешь в одном запросе вытащить все необходимые данные в необходимой структуре.
Максим
Подскажите, пожалуйста, есть что-то лучше BundDB среди встраиваемых БД?
Slava
Alexander
Alexander
Про структуру вообще интересно. Эта проблема может возникнуть если сначала был разработан клиент а потом независимо от клиента API
Aleksandr
Я про это как раз и написал
вообще-то нет. ты написал про разные клиенты и разные данные, а я про нужный респонс на один запрос. не надо собирать данные с разных эндпойнтов, как делается в парадигме rest, а можно сделать один запрос и получить правильно структурированные и все необходимые данные - хоть один клиент, хоть много. это именно query language со всеми вытекающими
Alexander
Так это причина - разные требования к получаемым данным
Alexander
Просто если такое со старта требуется то что-то не так в проектировании пошло
Alexander
Кроме того как мне кажется никакой проблемы в нормализации на клиенте нет
Alexander
Зачем это делать на сервере?
Alexander
Мне думается с тем же успехом можно rpc использовать и закидывать туда sql запросы
Alexander
Выполнять на сервере и отдавать ответ
Мерль
Aleksandr
Просто если такое со старта требуется то что-то не так в проектировании пошло
пример: на одной странице нужно получить листинг постов, топ-10 юзеров (причем не объекты из 10 полей, а только имена), топ-10 комментариев. REST частично это позволит сделать через 3 запроса. Частично потому, что грузится все объекты будут полностью.
И вот это начальные требования большинства проектов и к проектирование здесь не причем. Ты просто возможно противопоставлячешь graphql своему кастомному апи, но graphql - готовая спека, и противопоставлять надо готовым спекам или парадигмам
Aleksandr
мы же о ФБ говорим
Alexander
Нет
Alexander
Я про обычные проекты. На пример сразу думаю кому бы из клиентов могло такое понадобится
Alexander
Aleksandr
Мне думается с тем же успехом можно rpc использовать и закидывать туда sql запросы
но ты знаешь что на сервере sql только в своем проекте. graphql - спецификация, абстрагимрующая тебя от этого знания
Aleksandr
Pawel
ну да
Alexander
Какой трафик?
Alexander
Если ты пишешь API то сразу продумаваешь как и где эти данные используются. Если есть не стыковки то API корректируется
Aleksandr
ребят, это спецификация. не надо сравнивать ее со своим кастомным api. Спецификация создана для стандартизации и унификации опыта.
Alexander
И таким образом у тебя меньше запросов
Aleksandr
понятно, что в своем проекте вы можете все хотелки реализовать в своем кастомном апи. но тут вам уже дали готовую спеку и готовые клиенты
Alexander
А вообще реально rpc с пересылкой slq зароса - который еще и на web-сокетах будет работать будет в разы производительней да и трафика в разы меньше будет
Alexander
так чем же этот graphql лучше ?
Pawel
ребят, это спецификация. не надо сравнивать ее со своим кастомным api. Спецификация создана для стандартизации и унификации опыта.
имхо как язык описания данных grpahql имхо не очень swаgger прям в разы лучше. А когда транспорт вебсокеты, особо кипеть на сжате трафика смысла нет
Aleksandr
делать меньше хттп, меньше хедеров и служебных транспортных пакетов
речь идет об экономии не на спичках. выбрать 1000 объектов с 10 полями и выбрать 1000 объектов с двумя полями - это огромная экономия на трафике и огромный плюс юзер экспириенсу за счет более быстрого отклика
Alexander
речь идет об экономии не на спичках. выбрать 1000 объектов с 10 полями и выбрать 1000 объектов с двумя полями - это огромная экономия на трафике и огромный плюс юзер экспириенсу за счет более быстрого отклика
я же говорю используй web-сокеты с rpc и передавай sql-запрос
Aleksandr
так чем же этот graphql лучше ?
ты читаешь меня? я написал это не спека vs кастом. Это спека vs спека.
Alexander
есть один момент если запросы будут формироваться на строне клиента то это потенциально опасно
Alexander
никто не сможет гарантировать что один такой запрос не уложит тебе сервер
Aleksandr
никто не сможет гарантировать что один такой запрос не уложит тебе сервер
это вопрос твоей реализации серверной части. если ты в своем апи даешь воможность совершать тяжелые запросы - это же вопросы к тебе, а не клиенту?
Aleksandr
то есть этот упрек работает же для любого апи
Alexander
никто не сможет гарантировать что один такой запрос не уложит тебе сервер
ибо проектировать серверную часть и клиентскую с высокой долей вероятности будут разные люди
Alexander
там ты сам формируешь выборку
Alexander
и эти запросы ограничены твоей спецификацией
Alexander
на клиенте ты можешь только дернуть метод через запрос
Alexander
и получить данные
Pawel
я же говорю используй web-сокеты с rpc и передавай sql-запрос
мне кажется тут надо конкретный пример рассмотреть чтобы прийти к какому-то заключению. swagger rest api VS. graphQL, в обеих случаях websockets gzip RFC 7692 в качестве транспорта.
Alexander
а все эти методы уже давно оттестированы заранее
Alexander
и под нагрузкой
Aleksandr
на клиенте ты можешь только дернуть метод через запрос
именно. я и говорю - вопрос реализации сервера
Alexander
мне кажется тут надо конкретный пример рассмотреть чтобы прийти к какому-то заключению. swagger rest api VS. graphQL, в обеих случаях websockets gzip RFC 7692 в качестве транспорта.
websockets и rest api это взаимоисключающие вещи. Вебсокеты работают через сообщения считай тот же rpc (где тоже нет жесткой спецификации)
Pawel
не суть. яимею ввиду чисто формат данных. насколько сильно он влияет на перфрманс при сжатии и с вебсокетами
Aleksandr
не суть. яимею ввиду чисто формат данных. насколько сильно он влияет на перфрманс при сжатии и с вебсокетами
так в чем вопрос? что будет быстрее: три запроса с избыточными данными или один запрос с без избыточных?
Pawel
так тут вопрос в том, насколько это качественно влияет. Очевидно в случае фейсбука - таки да, профит есть. А в общем случае стоит ли замарачиваться с таким .. хм, странным форматом?
Alexander
суть в том что цена внедрения graphQL высока
Alexander
проще доработать API под клиент
Pawel
именно. когнитивная нагрузка)
Alexander
если остро стоит вопрос с трафиком то лучшего решения чем websockets нет
Alexander
если остро стоит вопрос с трафиком то лучшего решения чем websockets нет
и да,туда тоже можно гонять этот формат
Aleksandr
так тут вопрос в том, насколько это качественно влияет. Очевидно в случае фейсбука - таки да, профит есть. А в общем случае стоит ли замарачиваться с таким .. хм, странным форматом?
еще раз: мы говорим про спеку против спеки. Сам ты можешь сделать апи быстрее и заточеннее под твои требования. Если же мы говорим про другие спеки, то они просто не решают решаемые в graphql проблемы.
Как качественно: на больших листингах разница будет в сотни кб на запрос. Профит для плохих мобильных соединений. Плюс уменьшение кол-ва запросов, которые могут виснуть еще только на открытии соединения на моб. соединениях. Ну конечно профитно.
Но еще раз: сам ручками ты сможешь сделать лучше.
Alexander
только смысл ?
Aleksandr
суть в том что цена внедрения graphQL высока
с нуля цена ниже чем разрабатывать свое, за счет готовых серверных реализаций. Рефакторинг готового проекта конечно дорог
Alexander
еще раз: мы говорим про спеку против спеки. Сам ты можешь сделать апи быстрее и заточеннее под твои требования. Если же мы говорим про другие спеки, то они просто не решают решаемые в graphql проблемы.
Как качественно: на больших листингах разница будет в сотни кб на запрос. Профит для плохих мобильных соединений. Плюс уменьшение кол-ва запросов, которые могут виснуть еще только на открытии соединения на моб. соединениях. Ну конечно профитно.
Но еще раз: сам ручками ты сможешь сделать лучше.
websockets - один запрос и ты подписан на изменение данных, сервер тебе будет их отправлять сам
Alexander
ладно давай так ты уже использовал это на реальных проектах ?
Alexander
я про серверную часть