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

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

я тебе доказывать ничего не хочу:) но надеюсь что ты выйдешь из стадии отрицания и все-таки увидишь плюсы graphql ?

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

я тебе доказывать ничего не хочу:) но надеюсь что ты выйдешь из стадии отрицания и все-таки увидишь плюсы graphql ?

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

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

графкуэль это и делает

графкуэль это и делает

нет

он обозначет протокол взаимодействия

Единственный его плюс — относительно быстро наворотить решение, ну или быстро изменить

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

это не повод внедрять стандарт просто потому что так "красивее будет"

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

и вообще вряд ли будет

Преждевременная оптимизация это когда мы херячим бинарный протокол со сжатием на старте проекта

Единственный его плюс — относительно быстро наворотить решение, ну или быстро изменить

относительно быстро наворотить решение на Go, которое необязательно будет эффективным

да мы все уже поняли, что куча эндпоинтов лучше

Стоп, а причем тут го? Выше про питон же говорили, нет

?

Преждевременная оптимизация это когда мы херячим бинарный протокол со сжатием на старте проекта

или когда херачим json-подобный протокол уровня приложения, требующий точно так же хитрой логики на бэке. Нет разницы

Есть.

Стоп, а причем тут го? Выше про питон же говорили, нет

это я говорил. В питоне нет нормальной стабильной реализации GraphQL в принципе

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

сангрия стабильна

Есть.

какая?

сангрия стабильна

потому что у них на сайте так написано?

потому что у них на сайте так написано?

потому что я использую

потому что я использую

это фейспалм

Ник, ну ты же можешь лучше

тебе гомеопатия тоже помогает?

и поэтому она работает?

wat?

Я не защищаю протокол, я говорю что в процессе быстро изменяющегося проекта это решение имеет право на существование

wat?

ну, ты пытаешься привести "у меня работает", как аргумент в пользу технологии. Точно так же, как это делают сторонники гомеопатии.

потому что у них на сайте так написано?

Критерии стабильности в студию

ну, ты пытаешься привести "у меня работает", как аргумент в пользу технологии. Точно так же, как это делают сторонники гомеопатии.

а как ты стабильность еще измеряешь?

я тебе дал примеры компании, где это работает

Я не защищаю протокол, я говорю что в процессе быстро изменяющегося проекта это решение имеет право на существование

в процессе быстро изменяющегося проекта - с большой натяжкой, и то если затраты на внедрение технологии меньше, чем тяп-ляп на коленке

пока тут только Лев Толстой только ты, ниодного аргумента, только хейт

а как ты стабильность еще измеряешь?

по соответствию реализации спеке, в том числе прохождению стресс-тестирования и интеграционного тестирования

пока тут только Лев Толстой только ты, ниодного аргумента, только хейт

просто ты не читаешь, что я пишу

Вброшу еще, а как же html5?

просто ты не читаешь, что я пишу

внимательно читаю, и в основном эт дичь

я тебе дал примеры компании, где это работает

я тебе дал выше пример человека, которому "помогает" гомеопатия

Нет же утвержденной спеки

Как тогда жить?

Нет же утвержденной спеки

есть

Всеми признанной?

w3c таки согласовали html5?

аа, ты про html5)

внимательно читаю, и в основном эт дичь

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

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

разве я дрочу?

разве я дрочу?

наверное, мне отсюда не видно. Но судя по абсолютной глухости к аргументам - вполне может быть

наверное, мне отсюда не видно. Но судя по абсолютной глухости к аргументам - вполне может быть

от тебя не было аргументов

кстати даже референсная имплементация есть https://github.com/graphql/graphql-js

от тебя не было аргументов

от меня их была масса, в том числе опровержение твоего синтетического примера. 1) усложнение логики на бэке 2) отсутствие реализации для промышленных языков 3) возможность все те же проблемы решить без внесения в проект лишнего стандарта 4) физическая невозможность протестировать все возможные случаи запросов

ты их все проигнорировал

А можно список промышленных языков?)

А можно список промышленных языков?)

на чем там веб пишут сейчас? PHP, Python, Ruby, Java, Scala

Erlang

от меня их была масса, в том числе опровержение твоего синтетического примера. 1) усложнение логики на бэке 2) отсутствие реализации для промышленных языков 3) возможность все те же проблемы решить без внесения в проект лишнего стандарта 4) физическая невозможность протестировать все возможные случаи запросов

1) Не правда, нет никакого усложения 2) Scala,java есть точно 3) странная логика, эт не отменяет факт состоятельности данной технологии 4) нет это не так

Haskell

доволен?

1) Не правда, нет никакого усложения 2) Scala,java есть точно 3) странная логика, эт не отменяет факт состоятельности данной технологии 4) нет это не так

1) потому что ты так сказал? 2) агностичные к базе? покажи 3) но ставит под сомнение факт ее нужности и практичности 4) потому что ты так сказал?

GraphQL дает дикий оверхед, но если на него насрать реализация и изменение данных штук происходит очень быстро

1) потому что ты так сказал? 2) агностичные к базе? покажи 3) но ставит под сомнение факт ее нужности и практичности 4) потому что ты так сказал?

потому что я пишу код и вижу, что логика там простая https://github.com/graphql-java/graphql-java или sangria, 3) почему юзаешь интернет, а не шлешь голубей? 4) у меня написаны тесты

GraphQL дает дикий оверхед, но если на него насрать реализация и изменение данных штук происходит очень быстро

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

Это как RMI, дергаем удаленно метод, получаем данные, работаем с ними, все счастливы

GraphQL дает дикий оверхед, но если на него насрать реализация и изменение данных штук происходит очень быстро

оверхед на что?

потому что я пишу код и вижу, что логика там простая https://github.com/graphql-java/graphql-java или sangria, 3) почему юзаешь интернет, а не шлешь голубей? 4) у меня написаны тесты

1) с каких это пор "я считаю, что там логика простая, значит, простая" стало аргументом? 2) окей, надо посмотреть, что оно умеет 3) что ты несешь? 4) см. п.1

ERROR: S client not available

1) с каких это пор "я считаю, что там логика простая, значит, простая" стало аргументом? 2) окей, надо посмотреть, что оно умеет 3) что ты несешь? 4) см. п.1

4 https://github.com/sangria-graphql/sangria-relay/tree/master/src/test/scala/sangria/relay/starWars

оверхед на что?

Чем больше штука делает под капотом, тем больше времени это занимает

хватит уже аргументы гомеопатов приводить

4 https://github.com/sangria-graphql/sangria-relay/tree/master/src/test/scala/sangria/relay/starWars

что мне должна доказать эта ссылка?

Чем больше штука делает под капотом, тем больше времени это занимает

http сервер тоже много чего делает под капотом

что мне должна доказать эта ссылка?

что это тестируется

Может кто подкинуть пару учебников по Go на русском языке?

1) с каких это пор "я считаю, что там логика простая, значит, простая" стало аргументом? 2) окей, надо посмотреть, что оно умеет 3) что ты несешь? 4) см. п.1

3) пункт выкинуть нужно, это просто тупо

что это тестируется

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

3) пункт выкинуть нужно, это просто тупо

согласен

Боже прости меня за то, что я поднял тему GraphQL в этот вечер.

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

не совсем так, ты не все возможны query должен тестить

не совсем так, ты не все возможны query должен тестить

чигойто? а если у меня база хитрая и не все джойны одинаково работают?

чигойто? а если у меня база хитрая и не все джойны одинаково работают?

Открой пример схемы, я примерно обьясню

Открой пример схемы, я примерно обьясню

причем тут схема вообще? еще раз - у тебя есть граф сущностей. Неважно даже, маппится он напрямую на объекты в базе или нет. Тебе надо это все как-то интеграционно тестировать, что запрос связанных сущностей выполняется за приемлемое время и не приводит к поломке кода.

это почти что сраный полносвязный граф в случае graphql

ну или сильно разветвленное дерево, чем больше сущностей - тем больше вариантов надо тестить

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

ну или сильно разветвленное дерево, чем больше сущностей - тем больше вариантов надо тестить

https://github.com/sangria-graphql/sangria-playground/blob/master/app/models/SchemaDefinition.scala открой)

https://github.com/sangria-graphql/sangria-playground/blob/master/app/models/SchemaDefinition.scala открой)

не буду я открывать, ты аргумент по теме приведи, а не свой частный случай

глянь на то как делается resolve и поймешь, что достаточно тестить только отдельный тип

все возможные query тестить не нужно

ну и всегда можно тест дописать)

все возможные query тестить не нужно

это неверное утверждение по очевидным причинам

что и как нужно тестить - зависит от реализации бэка, а не от того, какой протокол используется при взаимодействии с фронтом

ну и всегда можно тест дописать)

или сотню, ага

ну ты тоже самое будешь делать и для реста

логично же

ну ты тоже самое будешь делать и для реста

для реста у меня есть идемпотентные функции, которые на одинаковый запрос отдают одинаковый ответ

именно поэтому рест можно написать даже чисто функционально, и все это будет охренительно тестироваться

для реста у меня есть идемпотентные функции, которые на одинаковый запрос отдают одинаковый ответ

exactly the same