1. roundtrips - вместо десятков GET запросов - oдин запрос. на мобилках это значительное снижение задержки, lower time to content 2. over-fetching - меньшее потребление памяти и нагрузка сети, slightly lower TtC 3. versioning - легче чем с REST --> depracation & additions of individual fields instead of whole-api-versioning ala /v45/ 4. coupling - frontend команда менее зависит от backend команды, им не приходится постоянно вымогать у backend'а новые endpoint'ы для оптимизации.

хотя насчёт versioning на самом деле был не совсем прав, там REST с GQL практически на равне

1. Axios делает это. Никогда поодобных проблем не было. 2 Сколько конкретно памяти? 3 Это не проблема БД 4 Не пойму этого разделения (у меня нет таких больших проектов)

0.99 s | 8 mb большая страница

и особенно что касается Vue и модульной разработки приложений... представим себе что у нас много много много маленьких компонентов.. каждый из компонентов требует конкретный набор данных, например component X ---> {user{name, avatar}} component Y ---> {product(id:123){name, description}} component Z ---> {products(first:100, sort:'name')} и многие другие.. в случае с REST получится жутко убого... десятки запросов туда сюда, тонны ненужных данных с GQL клиент аггрегирует графы в один граф и посылает один запрос на сервер

И 2 больших по REST

Через all

1. Axios делает это. Никогда поодобных проблем не было. 2 Сколько конкретно памяти? 3 Это не проблема БД 4 Не пойму этого разделения (у меня нет таких больших проектов)

Axios это лишь HTTP библиотека, она не сможет аггрегировать 10 различных GET запросов на сервер в один единственный, серверу так или иначе придётся отвечать на 10 запросов GraphQL же выстраивает Graph, а граф можно сагрегировать в большой 1 граф. тем самым ты читаешь с сервера ТОЛЬКО те данные что тебе нужно и всё это одним запросом

Это я понял как работает

Это плюс

Но я могу на sql так же делать

Но я могу на sql так же делать

причём тут SQL? o_O

SQL это совсем другой уровень, это происходит уже позади API

надеюсь ты понимаешь что GraphQL это НЕ язык для обращения к бд?

это язык между клиентом и сервисом, т.е. API, а вот как этот сервис и откуда он эти данные уже будет доставать (SQL, noSQL, Filesystem, Object Storage.. what ever..) это совсем другой уровень абстракции

Вы тут спорите ни о чем, у netflix есть стоя реализация аналога graphql

Вы тут спорите ни о чем, у netflix есть стоя реализация аналога graphql

однако GQL более "стандарт" нежели что-то внутреннее там у Netflix'а

суть в том что GraphQL отлично подходит для модульных Vue приложений, поэтому было бы интересно пообщаться с единомышленниками

однако GQL более "стандарт" нежели что-то внутреннее там у Netflix'а

Не стандарт

http://tonsky.livejournal.com/309037.html

суть в том что GraphQL отлично подходит для модульных Vue приложений, поэтому было бы интересно пообщаться с единомышленниками

https://github.com/Folkloreatelier/laravel-graphql Только нахера он я не пойму, все равно. Чтоб потом статическими методами в базу лукаться?

Так, всем ставить звездочку https://bugs.chromium.org/p/chromium/issues/detail?id=758600

Короче - я считаю этот Граф - лишней абстракцией

Не стандарт

я не зря написал "стандарт" в ковычках, однако есть открытая спецификация, есть open source'ные реализации на разных языках, уже у некоторых как Github в продакшне

Так, всем ставить звездочку https://bugs.chromium.org/p/chromium/issues/detail?id=758600

не прошло и года

:)

я не зря написал "стандарт" в ковычках, однако есть открытая спецификация, есть open source'ные реализации на разных языках, уже у некоторых как Github в продакшне

Он требует сервер же

https://github.com/Folkloreatelier/laravel-graphql Только нахера он я не пойму, все равно. Чтоб потом статическими методами в базу лукаться?

это замена REST, и это НЕ замена SQL

это замена REST, и это НЕ замена SQL

Еще один сервак, кароч http://graphql.org/learn/serving-over-http/

http://tonsky.livejournal.com/309037.html

такое чувство что у чувака стоит на mysql и больше ничего не нрав. Не понял предъяв по поводу "формата". Мб потому что куча воды в статье

Он требует сервер же

а разве REST не требует сервера?)) да, REST сервер написать легче с нуля, но со временем когда сервис начнёт расти и усложняться - REST превратится в один большой кошмар

это замена REST, и это НЕ замена SQL

REST мне каж сокет заменит

такое чувство что у чувака стоит на mysql и больше ничего не нрав. Не понял предъяв по поводу "формата". Мб потому что куча воды в статье

По моему очень толково рассказано

REST мне каж сокет заменит

а сокеты тот тут причём?! o_O сокеты это транспортный уровень так же как и HTTP

На Хабре в комментах рассказали как 1м запросом ддосить бд на gql, просто офигенская увеличив вложенность запроса

а разве REST не требует сервера?)) да, REST сервер написать легче с нуля, но со временем когда сервис начнёт расти и усложняться - REST превратится в один большой кошмар

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

а сокеты тот тут причём?! o_O сокеты это транспортный уровень так же как и HTTP

И что?

По моему очень толково рассказано

ну смотри он на 10% расписал шо это лишний слой абстракции. Оставшиеся 90% он написал какую-то дичь про то шо фейсбук ему не командир и ему не нрав вид данных потому что не нрав

На Хабре в комментах рассказали как 1м запросом ддосить бд на gql, просто офигенская увеличив вложенность запроса

это контролируется, много способов борьбы с DoS

Короче - я считаю этот Граф - лишней абстракцией

И что?

ну так ты сравниваешь груши с огурцами

а сокеты тот тут причём?! o_O сокеты это транспортный уровень так же как и HTTP

с каких пор http = транспортный лвл?

с каких пор http = транспортный лвл?

а какой же это тогда уровень?

ну так ты сравниваешь груши с огурцами

Нет. Я сравниваю способы обмена данными

всегда был прикладной

Нет. Я сравниваю способы обмена данными

ты говоришь "давайте заменим HTTP - сокетами", но мы же не о том "как" данные передавать, а как к API серверу "обращаться", т.е. как API расписать то чего тебе нужно и тут у нас есть REST, SOAP, GraphQL и т.д. и т.п. поэтому сравнивать сокеты (транспортный уровень) с GraphQL (протокол общения с API) совсем неправильно

сокеты работают поверх tcp

ты говоришь "давайте заменим HTTP - сокетами", но мы же не о том "как" данные передавать, а как к API серверу "обращаться", т.е. как API расписать то чего тебе нужно и тут у нас есть REST, SOAP, GraphQL и т.д. и т.п. поэтому сравнивать сокеты (транспортный уровень) с GraphQL (протокол общения с API) совсем неправильно

Я буду все делать по сокетам, например...

тобишь это тоже не транспорт

сокеты работают поверх tcp

http

не совсем

http и вебсокеты похожи

но не same

и REST и GraphQL можно по сокетам передавать (хотя смысла в этом мало если HTTP keep alive активирован). Но это не меняет сути что в REST тебя так или иначе будет over-fetching и слишком много round-trips

шо бл

шо бл

мне так-же отвечать как ты вопросы задаёшь?))

та не я ору немного

та не я ору немного

если тебе тема неинтересна и ничего внести не можешь то зачем засорять беседу то?

я б не орал если бы не было интересно

@Romshark каким образом keep alive влияет на сокеты в браузере?

По моему очень толково рассказано

Тебе почемуто пламенный пост дейва тоже понравился)

Тебе почемуто пламенный пост дейва тоже понравился)

Мне каж по другой причине ))

@Romshark каким образом keep alive влияет на сокеты в браузере?

я лишь хотел сказать, что сильного прироста производительности в плане запросов не будет если заменить HTTP на WebSockets. Поскольку HTTP сам поверх TCP/IP и с включённой опцией "Keep-Alive" сокет не обрывается... единственный overhead HTTP это чуток лишних данных (header больше чем у WebSocket message) и парсинг, но overhead незаметно минимальный.. т.е. это совсем не то на что бы следовало тратить время на оптимизацию

причем тут производительность

причем тут производительность

+

ERROR: S client not available

причем тут производительность

а зачем тогда менять HTTP на WebSockets если мы говорим о простых запросах на сервер??

бож

обратная связь же не нужна

Такое ощущение что еж в капюшоне до конца не дочитали

я хоть и тупой, но мне смешно

Такое ощущение что еж в капюшоне до конца не дочитали

кого

Длиннотекст

читал

да тролит он походу..

я ж говорю - я тупой. У меня другое представление обо всем этом

да тролит он походу..

Он просто не понимает over fetching и round trips

короче я так понял никто ещё серьёзно не вдавался в GQL?

Он просто не понимает over fetching и round trips

да я уже понял

рей говорит шо не хорошо - так что вдаваться не буду

но если-бы хоть вопросы нормальные задавал, а так сидит и тролит.. ?

Он просто не понимает over fetching и round trips

Вроде понятно все же

но если-бы хоть вопросы нормальные задавал, а так сидит и тролит.. ?

Почему нельзя сделать только WS? Без XHR

короче я так понял никто ещё серьёзно не вдавался в GQL?

О gql заговорили ток недавно. Не знаю че там в 15 году было но активный треп о нем я ток с весны увидел

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

Почему нельзя сделать только WS? Без XHR

ты просто меняешь транспортный уровень... а речь идёт о протоколе коммуникации с API, не о протоколе передачи данных с точки А в точку Б

Почему нельзя сделать только WS? Без XHR

Так он же говорит можно заменить на сокеты

как инфу получать ? на пример о юзере. Она лежит в локал стораж. Как удобнее ее получить ? в родителе при старте получать ?

Да и ты сам от меня вроде узнал))

Рано или поздно все уйдут в лямбды или серверлесс или наносервисы, нужное подчеркнуть. Будут написаны простые функции, с открытыми конектами в базе. Которые тупо висят в умном облаке. Ты в рест 2 будешь бросаться джейсоном запросов. Рест 2 будет стартовать одновременно все лямбды по запросу. Формировать пакет ответа или ошибку или ответ и ошибки и отправлять на клиента. Как всё организовать будет решать архитектура как и в стандартном ресте, а не язык абстракции

В created мож?

как инфу получать ? на пример о юзере. Она лежит в локал стораж. Как удобнее ее получить ? в родителе при старте получать ?

created(){}

created(){}

не важно. Идие правильная ? или вынести в стор ?

Рано или поздно все уйдут в лямбды или серверлесс или наносервисы, нужное подчеркнуть. Будут написаны простые функции, с открытыми конектами в базе. Которые тупо висят в умном облаке. Ты в рест 2 будешь бросаться джейсоном запросов. Рест 2 будет стартовать одновременно все лямбды по запросу. Формировать пакет ответа или ошибку или ответ и ошибки и отправлять на клиента. Как всё организовать будет решать архитектура как и в стандартном ресте, а не язык абстракции

Расскажи про лямбду

я не знаю что ты делаешь и структуру проекта

если тебе нужен стор - юзай стор

если без него справляешься - нах не нужен