да там вовсе необязательно три эндпойнта даже

http://try.sangria-graphql.org/

вам бы вообще про osi почитать

мне не надо, спасибо. В моем мире http - не транспортный протокол. Собственно, в модели OSI тем более

да там вовсе необязательно три эндпойнта даже

1.

http://try.sangria-graphql.org/

нет, спасибо

ну просто представь что делаешь API, одному нужно список клиентов с их заказами и названием производителя каждого товара в заказе, а другому нужно список клиентов с их заказами и адресом производителя каждого товара в заказе

нет, спасибо

открывай

получается 2 разных эндпойнта?

получается 2 разных эндпойнта?

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

мне не надо, спасибо. В моем мире http - не транспортный протокол. Собственно, в модели OSI тем более

даже в твоем любимом гоу, http клиент в пакете transport лежит)

и еще один нужен - надо получить список клиентов с их заказами, без детализации по товарам

ну просто представь что делаешь API, одному нужно список клиентов с их заказами и названием производителя каждого товара в заказе, а другому нужно список клиентов с их заказами и адресом производителя каждого товара в заказе

Я понял. Вы имеете ввиду ту самую гибкость на уровне внутренностей респонса.

даже в твоем любимом гоу, http клиент в пакете transport лежит)

это не меняет того факта, что модель OSI говорит, что ты не прав)

эти все понятия относительны

и еще один нужен - надо получить список клиентов с их заказами, без детализации по товарам

а, то есть еще у нас сущность "товар" появилась или что?

то что http находится не на транспортном уровне osi не делает его не транспортом

в заказах должны быть товары, да)

в заказах должны быть товары, да)

то есть ты сейчас вот так взял и расширил ТЗ нехило)

а, то есть еще у нас сущность "товар" появилась или что?

открой пример, http://try.sangria-graphql.org/ проще будет

то есть ты сейчас вот так взял и расширил ТЗ нехило)

у тебя всегда идеальные тз?

а, то есть еще у нас сущность "товар" появилась или что?

Он имеет ввиду, из одного пакета с продуктами, овощами и так далее, каждый клиент захочет вытащить только свои помидоры, морковь и так далее. Кому-то нужно будет и то и то.

открой пример, http://try.sangria-graphql.org/ проще будет

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

Он имеет ввиду, из одного пакета с продуктами, овощами и так далее, каждый клиент захочет вытащить только свои помидоры, морковь и так далее. Кому-то нужно будет и то и то.

я не телепат, чтобы понять, что он имеет в виду

я не телепат, чтобы понять, что он имеет в виду

открой пример

у тебя всегда идеальные тз?

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

и ее таким образом гораздо проще тестировать

там есть вся спека, реализуй ее на rest

там есть вся спека, реализуй ее на rest

мне неинтересна спека оттуда. Мне интересна бизнес-задача, которую надо решить.

клиенты к тебе со спекой не приходят

мне неинтересна спека оттуда. Мне интересна бизнес-задача, которую надо решить.

так открой пример

clients{ name, orders{number, items{title, manufacturer{name}}}} - запрос списка клиентов с их заказами и товарами в них, с названием производителя у каждого товара

clients{ name, orders{number, items{title, manufacturer{address}}}} - то же, но уже вместо названия производителя его адрес

так открой пример

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

clients{ name, orders{number}} -  просто список клиентов с их заказами

@Enchantner а ты не в питере живешь?

@Enchantner а ты не в питере живешь?

нет

clients{ name, orders{number, items{title, manufacturer{name}}}} - запрос списка клиентов с их заказами и товарами в них, с названием производителя у каждого товара

зачем, если есть эндпойнты?

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

Жаль, приезжай на какой-нибудь митап, обьясню на листочке

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

один хэндлер с кучей логики по джойнам и полям? нет, спасибо, ешьте сами

нет там кучи логики

я бы сказал ,что там вообще логики нет

Жаль, приезжай на какой-нибудь митап, обьясню на листочке

не объяснишь :) для меня абсолютно очевидно, что это избыточная херня, которую сложно тестировать и невозможно нормально переносить

не объяснишь :) для меня абсолютно очевидно, что это избыточная херня, которую сложно тестировать и невозможно нормально переносить

нет, тестировать ее не сложно

я удивляюсь, что ты вообще споришь

я бы сказал, что не сложнее реста

нет, тестировать ее не сложно

нда? ну покажи мне либу для graphql на Python + SQLAlchemy, которая дает тебе 100% coverage автогенеренными тестами

и то это поблажка, ибо в общем случае не должно быть завязки на sqlalchemy

ты еще и тесты кавереджем измеряешь)))

я не питон программист и не могу знать

ты еще и тесты кавереджем измеряешь)))

я просто написал так, чтобы понятнее было

что это невозможно :)

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

В тэгах указываешь json:"-"

я не питон программист и не могу знать

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

окей, тогда вопросов нет))

если бы твое изречение сразу звучало, как "В Golang есть либа для GraphQL, которая хорошо оттестирована и маппит сущности удобно на встроенный database/sql и ORM с генерацией тестов по запросам" - я бы даже и не спорил

но это крайне узкий кейс и он ничего абсолютно не говорит о graphql, как о применимой и удобной технологии

так у тебя сущности в graphql могут не совпадать с сущностями в бд ?

вот кстати продукт, который юзает графкуэль https://demo.databaseflow.com

так у тебя сущности в graphql могут не совпадать с сущностями в бд ?

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

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

будет все

вот кстати продукт, который юзает графкуэль https://demo.databaseflow.com

вот, кстати, человек, который ест гомеопатию https://ru.wikipedia.org/wiki/%D0%95%D0%BB%D0%B8%D0%B7%D0%B0%D0%B2%D0%B5%D1%82%D0%B0_II

тьфу, не та королева

вот, кстати, человек, который ест гомеопатию https://ru.wikipedia.org/wiki/%D0%95%D0%BB%D0%B8%D0%B7%D0%B0%D0%B2%D0%B5%D1%82%D0%B0_II

мда, ты уже полный бред начал гнать

а вот еще использование graphql https://developer.github.com/v4/

кстати, с REST перешли)

мда, ты уже полный бред начал гнать

ты мне на примере "вот тут так делают" пытаешьсая доказать нужность технологии. Это невалидный аргумент

Не в тему, но во фреймворке iris Добавили возможность листена на unix сокете.

ERROR: S client not available

ты мне на примере "вот тут так делают" пытаешьсая доказать нужность технологии. Это невалидный аргумент

а как тебе доказать?

а вот еще использование graphql https://developer.github.com/v4/

в гитхабе есть четкий набор сущностей при минимуме бизнес-логики. Это как раз тот кейс, где оно может и взлететь

@Enchantner может ты еще думаешь, что земля плоская?

а как тебе доказать?

не знаю, пока плохо получается

люблю эти стикеры

кстати еще у курсеры graphql api

в гитхабе есть четкий набор сущностей при минимуме бизнес-логики. Это как раз тот кейс, где оно может и взлететь

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

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

я что-то сомневаюсь, что в гитхабе нет сущности "репозиторий" или "контрибьютор". Как минимум потому, что я с его API работаю.

Мне кажется уже бы обезьяна бы поняла для чего graphql, естественно за банан

я понимаю, зачем он придуман

разве? по-моему нет

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

смотри-ка чего гитхаб пишет

The ability to define precisely the data you want—and only the data you want—is a powerful advantage over the REST API v3 endpoints.

разве? по-моему нет

а по-моему ты пытаешься натянуть сову на глобус

где угодно, наравне с rest

GraphQL lets you replace multiple REST requests with a single call to fetch the data you specify.

Да блин, вы надоели спорить, дайте вопросы нормальные позадавать.

The ability to define precisely the data you want—and only the data you want—is a powerful advantage over the REST API v3 endpoints.

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

GraphQL lets you replace multiple REST requests with a single call to fetch the data you specify.

это прямое вранье

это прямое вранье

почему?

точнее как, не вранье, да, может заменить

но толку в этом нет никакого и это не является преимуществом

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

в случае сложного приложения со сложной бизнес логикой это тем более так

https://githubengineering.com/the-github-graphql-api/

они вот здесь подробнее описывают

в случае сложного приложения со сложной бизнес логикой это тем более так

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

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