Ну можно json-rpc сделать. Только принципиальная разница то какая? :)

тогда зачем graphql ?)

тогда зачем graphql ?)

чтобы можно было красивое слово в презентацию вставить

не стоит оно того

не стоит оно того

"но у нас же работает!!"

А какие сложные абстракции то? Если тебе по бизнес логике надо будет смешать данные с разных сервисов, то ты это будешь делать в любом случае, и graphql тут не при чем

А какие сложные абстракции то? Если тебе по бизнес логике надо будет смешать данные с разных сервисов, то ты это будешь делать в любом случае, и graphql тут не при чем

разумеется, и мы про то же

но в graphql это будет сделать значительно проще

просто graphql в этой ситуации еще и накладывает на тебя ненужные ограничения

но в graphql это будет сделать значительно проще

наоборот, сложнее

чем?

и какие ограничения накладывает graphql?

чем?

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

так можно же не делать поддержку вложенных сущностей:) кто заставляет то

можно так же сделать минимально

так можно же не делать поддержку вложенных сущностей:) кто заставляет то

тогда и graphql не нужен

уже есть REST

REST - прошлое

json-rpc v2.0 хотя бы уж

REST - прошлое

офигеть аргумент

REST хорошо ложится на CRUD операции, спору нет, но бизнес-логика обычно гораздо сложнее

JSON-прошлое, давайте везде юзать TOML!

HTTP/1 - прошлое, даешь везде HTTP/2!

HTTP/1 - прошлое, даешь везде HTTP/2!

???

давайте сразу передавать бинарники

давайте сразу передавать бинарники

давайте просто фуры с хардами возить

а то придумали какие-то браузеры, тоже мне

Голуби.

ну да, раньше было лучше )

ну, вы по существу чего-то ничего сказать не можете, к сожалению, так не интересно:)

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

UDP

ну, вы по существу чего-то ничего сказать не можете, к сожалению, так не интересно:)

в смысле? это ты по существу сказать не можешь ничего кроме "ну, у нас оно работает как-то" :)

UDP

еще варианты?

ну, вы по существу чего-то ничего сказать не можете, к сожалению, так не интересно:)

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

mysql socket?

mysql socket?

мыслите шире

в смысле? это ты по существу сказать не можешь ничего кроме "ну, у нас оно работает как-то" :)

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

если нужно что-то мелкое - тут даже REST лишний

Тут про канал, а не протокол

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

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

Тут про канал, а не протокол

+

мыслите шире

и какой же?

это еще что нашел Возможно, самая большая проблема при использовании GraphQL – так называемые N+1 SQL-запросы. В GraphQL поля запроса реализованы как обычные функции, отправляющие запросы к базе данных. Чтобы заполнить все поля данными, может потребоваться новый SQL-запрос на каждое поле. Facebook одним из первых предложил решение этой проблемы – DataLoader. это еще +1 оверхед

и какой же?

член. Передача генетической информации размером около 1600 Гб за 2.5-3 секунды

это еще что нашел Возможно, самая большая проблема при использовании GraphQL – так называемые N+1 SQL-запросы. В GraphQL поля запроса реализованы как обычные функции, отправляющие запросы к базе данных. Чтобы заполнить все поля данными, может потребоваться новый SQL-запрос на каждое поле. Facebook одним из первых предложил решение этой проблемы – DataLoader. это еще +1 оверхед

нужно решать проблемы с излишними слоями абстракции другими слоями абстракции!

забавно, что язык запросов противопоставляется архитектурному паттерну...

Откуда 1600гб? Вы не переоценили свои возможности?

facepalm, я думал щас что то новенкое по ит узнаю

странно, что тут не звучат лозунги "Go лучше чем Mysql!"

facepalm, я думал щас что то новенкое по ит узнаю

http://lifecity.com.ua/blog/view/1568/

@Enchantner Давай на примерах, у тебя есть Client и я хочу посмотреть его Orders как бы ты это сделал)

странно, что тут не звучат лозунги "Go лучше чем Mysql!"

и слава богу, бо чуть не началось nosql vs sql

Передача информации, обработка и т.п. не про ит

Откуда 1600гб? Вы не переоценили свои возможности?

там на деле больше даже

@Enchantner Давай на примерах, у тебя есть Client и я хочу посмотреть его Orders как бы ты это сделал)

описывай задачу в ТЗ, присылай на визирование, счет можно через ИП оплатить

описывай задачу в ТЗ, присылай на визирование, счет можно через ИП оплатить

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

там на деле больше даже

А моск включить? То, что канал ненадёжен и информацию приходится много раз дублировать, ещё не значит, что информации становится больше. 37,5 Мб — все, на что ты способен. Да и то все пакеты могут потеряйся.

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

это не конкретный пример :) в каждом конкретном случае логику надо точно согласовывать и тестировать

это не конкретный пример :) в каждом конкретном случае логику надо точно согласовывать и тестировать

это вполне себе конкретный пример, есть Client,Order и нужно получить список заказов у клиента

А моск включить? То, что канал ненадёжен и информацию приходится много раз дублировать, ещё не значит, что информации становится больше. 37,5 Мб — все, на что ты способен. Да и то все пакеты могут потеряйся.

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

это вполне себе конкретный пример, есть Client,Order и нужно получить список заказов у клиента

а какие сущности при этом на фронте?

а какие сущности при этом на фронте?

Order{id,name,client_id}, Client{Id,Name,order_ids}

И как они связаны?

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

Да, некоторые пакеты «битые» — и что? Тебе же надо передать не какую-то там информация да побольше. А конкретную — свою ДНК. Битые пакеты не увеличивают количество сиво переданной информации, а являются проблемой и могут приводить к потере передаваемой информации

Order{id,name,client_id}, Client{Id,Name,order_ids}

отлично мапятся на эндпойнты реста, в чем проблема?

отлично мапятся на эндпойнты реста, в чем проблема?

ну давай, описывай)

Да, некоторые пакеты «битые» — и что? Тебе же надо передать не какую-то там информация да побольше. А конкретную — свою ДНК. Битые пакеты не увеличивают количество сиво переданной информации, а являются проблемой и могут приводить к потере передаваемой информации

мне конкретно надо передать половину своего днк, которая может формироваться разными способами. И что является "битыми пакетами" в случае сперматозоидов?

ERROR: S client not available

ну давай, описывай)

GET /clients/123/orders

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

но изначальную этот запрос полностью решает

мне конкретно надо передать половину своего днк, которая может формироваться разными способами. И что является "битыми пакетами" в случае сперматозоидов?

Очевидно — ДНК не совпадающая с твоей

естественно

Очевидно — ДНК не совпадающая с твоей

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

но информация не является битой в этом случае, если она успешно передается и обрабатывается

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

отлично, добавляем еще одно условие, нужно вывести доп инфу о производителе Manufacturer {id, name} и добавляем в Order manufacturer_id

но информация не является битой в этом случае, если она успешно передается и обрабатывается

Не хотел бы я с тобой в команде работать))

Не хотел бы я с тобой в команде работать))

так мы про IT или про биологию? :)

с точки зрения IT это плохо, да, с точки зрения биологии - оно так и работает

отлично, добавляем еще одно условие, нужно вывести доп инфу о производителе Manufacturer {id, name} и добавляем в Order manufacturer_id

вывести где? в UI должна быть инфа о производителях в списке заказов?

отлично, добавляем еще одно условие, нужно вывести доп инфу о производителе Manufacturer {id, name} и добавляем в Order manufacturer_id

Некорректная задача. Производитель у номенклатуры

есть вариантов пять разных

вывести где? в UI должна быть инфа о производителях в списке заказов?

ага

есть вариантов пять разных

давай на твой взгляд лучший

давай на твой взгляд лучший

там нет "лучшего", есть логика, которой надо следовать

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

твою задачу это решит

приходит еще один клиент,который хочет видеть другую морду и другие данные Manufacturer'а

что делаем? дальше денормолизируем?

приходит еще один клиент,который хочет видеть другую морду и другие данные Manufacturer'а

какие "другие"?

и в чем отличие морды?

ну к примеру полный адрес его с фиасами

ну к примеру полный адрес его с фиасами

это уже другая модель получается совсем

это уже другая модель получается совсем

естественно

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

естественно

и в чем проблема? опять куча вариантов, например, делаешь хэндлер потипу /clients/123/order_manufacturer_full, где возвращаешь более подробную сущность. Либо разрешаешь делать /clients/123/orders/?manufacturer_fields=address

А в чем проблема-то? Если использовать nosql, то выборки простые

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

и в чем проблема? опять куча вариантов, например, делаешь хэндлер потипу /clients/123/order_manufacturer_full, где возвращаешь более подробную сущность. Либо разрешаешь делать /clients/123/orders/?manufacturer_fields=address

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

А в чем проблема-то? Если использовать nosql, то выборки простые

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