Просто пример классный на vue, gj'njve cghjcbk pltcm

+++

Поэтому спросил здесь

Кури ман

Тут нету вью в примере никак вообще

В вопросе нет, в примере (по ссылке) есть

Ты не знаешь что такое коллбек, зачем тебе этот пример

Кто-нибудь из вас уже использует GraphQL?

Мне не нравится синтаксис

Кто-нибудь из вас уже использует GraphQL?

думал, но как-то так и не решился пока

Мне не нравится синтаксис

ты про GraphQL?

Да

По моему нлборот прикольный там синтаксис, статическая типизация. Песочница вообще супер. Тестировать одно удовольствие апи

Я очень хочу поизучать Но времени нету

синтаксис это-ж незначительный аргумент... вещь на самом деле очень прогрессивная

но даже не могу представить что может не нравиться в синтаксисте GQL

единственная "проблема" которая возможно ещё недоработана так это caching / cache invalidation

Пагинация тоже говорят так себе? Но не изучал вопрос

в GQL кэш должен быть нормализован, а для инвалидации есть subscriptions.. однако пока что думаю в плане библиотек ещё сыровато

Пагинация тоже говорят так себе? Но не изучал вопрос

в смысле? в чём проблема с paging'ом?

Я не знаю, четсно) за что купил за то продалл Надо изучать

У меня даже есть проект, где попробовать хочу это

Пагинация тоже говорят так себе? Но не изучал вопрос

http://graphql.org/learn/pagination/

Спасиб

синтаксис это-ж незначительный аргумент... вещь на самом деле очень прогрессивная

Ну как сказать... Я предпочитаю более SQL подобный подход

Ну как сказать... Я предпочитаю более SQL подобный подход

постой, а причём тут SQL? SQL это для RDBMS

GraphQL это всего-лишь язык коммуникации клиента с API

вот вроде есть JS клиент библиотека: http://dev.apollodata.com/core/

постой, а причём тут SQL? SQL это для RDBMS

ПРи том, что это уродство: query: gql`query PingMessage($message: String!) { ping(message: $message) }`,

Не прозрачно

Я вот знаю SQL норм. Я никогда его не учил. Он просто ясен.

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