Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Спасибо за иллюстрацию моих слов.

Всё-таки есть разница между "существующие решения всегда плохие" (то, что ты сказал) и "в терминах сроков, денег и качества существующие решения не обязательно дают (большую) выгоду" (то, что я пытаюсь донести).

Здравствуйте, Serginio1, Вы писали:

S>Так для информации
S>Linq to ODATA

S> Очень близко к Linq to EF.
S> Ну и ODATA поддерживает JSON

Именно эта попытка представить сервер как какую-то базу данных меня и смущает. Не все запросы, которые имеют смысл при доступе к СУБД могут иметь смысл при доступе к API. Хочется в API выставлять только те обязательства, которые я готов соблюдать. Вот не хочу я давать возможность сортировать по заданному полю, и всё (потому что глобализация -- это очень сложно и я не хочу усложнять сервис).

Здравствуйте, Иван Дубров, Вы писали:

ИД>... Вот не хочу я давать возможность сортировать по заданному полю, и всё (потому что глобализация -- это очень сложно и я не хочу усложнять сервис).
ЕМНИП, все это настраивается при реализации сервиса OData

Здравствуйте, Иван Дубров, Вы писали:

ИД>Здравствуйте, Serginio1, Вы писали:

S>>Так для информации
S>>Linq to ODATA

S>> Очень близко к Linq to EF.
S>> Ну и ODATA поддерживает JSON

ИД>Именно эта попытка представить сервер как какую-то базу данных меня и смущает. Не все запросы, которые имеют смысл при доступе к СУБД могут иметь смысл при доступе к API. Хочется в API выставлять только те обязательства, которые я готов соблюдать. Вот не хочу я давать возможность сортировать по заданному полю, и всё (потому что глобализация -- это очень сложно и я не хочу усложнять сервис).

Глобализация на сервере SQL.
ODATA это прежде всего Rest интерфейс к базе данных.
И автоматческая генерация прокси классов, по аналогии с EF.


Если у тебя свой движок, то игнорируй. В чем проблема?

Здравствуйте, Shmj, Вы писали:

S>Что скажете?

С разморозкой. У нас тут много интересного произошло за последние 10 лет!

Здравствуйте, Иван Дубров, Вы писали:

ИД>Всё-таки есть разница между "существующие решения всегда плохие" (то, что ты сказал) и "в терминах сроков, денег и качества существующие решения не обязательно дают (большую) выгоду" (то, что я пытаюсь донести).

Главное, что нет разницы в результате

Здравствуйте, Serginio1, Вы писали:

S>Если у тебя свой движок, то игнорируй. В чем проблема?

В том что у OData "в терминах сроков, денег и качества существующие решения не обязательно дают (большую) выгоду". Проще говоря, найден фатальный недостаток.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>В том что у OData "в терминах сроков, денег и качества существующие решения не обязательно дают (большую) выгоду". Проще говоря, найден фатальный недостаток.

А что ещё кроме денег, сроков и качества должно волновать коммерческую компанию?

Тем более, что Facebook-у-то уж точно выгоднее всех нагнуть под себя. Причём им даже на обучение тратиться особо не надо -- всё сами разнесут и в блогах напишут.

Здравствуйте, Иван Дубров, Вы писали:

ИД>Тем более, что Facebook-у-то уж точно выгоднее всех нагнуть под себя. Причём им даже на обучение тратиться особо не надо -- всё сами разнесут и в блогах напишут.

Да при чем здесь гнуть ? Фремворки крайне трдны в разработке, тестировании, майнтенансе. Единственный способ побороть эту проблему — привлечь людей, которые сами по своей инициативе будут помогать.

Тебя же никто с пистолетом не заставляет использовать фейсбучные технологии. Пиши на чем хошь. Но вот мулька в том, что эпоха самопальных фремворков закончилась. Практически каждый доморощенный фремворк это какая то содомия. Единицы заслуживают какого то внимания. Соответственно гнёт не фейсбук — гнёт рынок.

Здравствуйте, Иван Дубров, Вы писали:

ИД>Не понимаю сакральности "использования всего готового". Использование готового тоже не бесплатно в терминах денег/времени/качества, и разница вообще может оказаться на уровне погрешности (относительно стоимости всего проекта). И если так, то не всё ли равно, велосипед или тщательно подобранное "готовое" решение?

Теоретически ты прав. Но в эту модель надо вписать рынок труда и перспективы развития. А дела здесь обстоят крайне плачевно — ИТ индустрия интенсивно поглощает необученый контингент. Уже есть ПТУ где учат паре-тройке алгоритмов уровня сортировок, пхп, sql и, вуаля, новый девелопер пытается потрясти мир и оставить вмятину во вселенной.

Компании очень часто недооценивают срок жизни проектов проектов. На финальных стадиях обычное дело, когда проект сжирает бабла больше, чем за все периоды вместе взятые. Переписывание, например, это идеальный способ пройтись по уже решенным проблемам. Очень трудно создать архитектуру на годы вперед.
Так что не всё равно, велосипед или готовое.

Здравствуйте, Ikemefula, Вы писали:

I>Уже есть ПТУ где учат паре-тройке алгоритмов уровня сортировок, пхп, sql и, вуаля, новый девелопер пытается потрясти мир и оставить вмятину во вселенной.

из вузов приходят такие же.
а где взять лучше?

DoS'ить новые сайты на GraphQL как удобно теперь будет! Через малюсенькую дырочку, запросом вида "... в доме который построил джек ...", можно будет жёстко бак-энд в медитацию отправить, и никакой CloudFlare не спасёт Что характерно для нашего века — спасаться от проблемы "специалисты" предлагают таймаутами

Здравствуйте, hi_octane, Вы писали:

_>DoS'ить новые сайты на GraphQL как удобно теперь будет! Через малюсенькую дырочку, запросом вида "... в доме который построил джек ...", можно будет жёстко бак-энд в медитацию отправить, и никакой CloudFlare не спасёт Что характерно для нашего века — спасаться от проблемы "специалисты" предлагают таймаутами

Жёстко не получится, только мягко. Все запросы в GraphQL -- это то, что сервер тебе на выбор предлагает, à la carte.

То есть можно, конечно, делать что-нибудь вроде:

{
 p1: Policy(id = xxx)
 p2: Policy(id = xxx)
 ...
 p1000000: Policy(id = xxx)
}

Т.е запросить какое-то поле много-много раз.

Или так:

{
  Policy { Vehicles { Driver { Vehicle { Driver { Vehicle { Name }...}
}

Т.е по циклу в данных прогуляться.

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


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

ИД>Жёстко не получится, только мягко. Все запросы в GraphQL -- это то, что сервер тебе на выбор предлагает, à la carte.
Ага, и на первой же демке с фильмами и актёрами пишем: "Получить Все Фильмы / Получить всех актёров в них / Получить Все Фильмы В которых Снимался Актёр / Всех Актёров в этих фильмах / ... / Тыдыщ"

Здравствуйте, hi_octane, Вы писали:

_>Ага, и на первой же демке с фильмами и актёрами пишем: "Получить Все Фильмы / Получить всех актёров в них / Получить Все Фильмы В которых Снимался Актёр / Всех Актёров в этих фильмах / ... / Тыдыщ"

Да, ты прав. Так можно.

Это аргумент за то, чтобы не выставлять внутреннюю схему данных "как есть". Как вариант, тип "актёр-внутри-фильма" не должен иметь поле "фильмы в которых снимался актёр".

_>>Ага, и на первой же демке с фильмами и актёрами пишем: "Получить Все Фильмы / Получить всех актёров в них / Получить Все Фильмы В которых Снимался Актёр / Всех Актёров в этих фильмах / ... / Тыдыщ"
ИД>Да, ты прав. Так можно.
ИД>Это аргумент за то, чтобы не выставлять внутреннюю схему данных "как есть". Как вариант, тип "актёр-внутри-фильма" не должен иметь поле "фильмы в которых снимался актёр".

Для разумной реализации этой схемы фронт-ендщик должен работать на пару с бэк-ендщиком да ещё и оба иметь какие-то задатки хакера чтобы предвидеть где нужно создавать тип "актёр-внутри-фильма" а где нет. По итогу умственной (и заодно рукопашной) работы становится не меньше (чего хочется от любой новой технологии), а больше. И квалификация обоих нужна уровнем повыше чем ваять 100500-й типовой REST-метод размером в один linq запрос. В Facebook, не спорю, даже уборщица будет подходящего уровня, а для остальных компаний этот GraphQL пока выглядит как культ карго и кактус бесконечной высоты.
Вот если залепят какие-нить аттрибуты на все основные бэк-энды, типа "MaxQueryDepth=2", тогда можно будет говорить о зрелости технологии. Пока основные советы пропагандистов заставляют делать И это при том что самой технологии уже года 3.

Здравствуйте, hi_octane, Вы писали:

_>DoS'ить новые сайты на GraphQL как удобно теперь будет! Через малюсенькую дырочку, запросом вида "... в доме который построил джек ...", можно будет жёстко бак-энд в медитацию отправить, и никакой CloudFlare не спасёт Что характерно для нашего века — спасаться от проблемы "специалисты" предлагают таймаутами

Вы как-то преувеличиваете автоматичность graphql. Думаете оно вам сразу даст произвольные джойны делать? )
На самом grpahql — это простой вызов функции, только с возможностью возвращать не все поля результата, а только те что попросит клиент.
Т.е. оно позволяет только уменьшить набор полей который возвращается на клиента, по сравнению с тем что предусмотрел разработчик бэкенда.

Если же на бэкенде предусмотрен запрос котороый позвовляет заддосить сервер — то какая разница graphql он или json-rpc или soap?

КБ>Вы как-то преувеличиваете автоматичность graphql. Думаете оно вам сразу даст произвольные джойны делать? )

Таки думаю да — полсотни форков, под 800 звёзд, в общем взлетает У них там сейчас спец-олимпиада идёт, кто больше возможностей искаропки добавит. Основной лозунг самого Фэйсбука: "Fetching all the data for a view hierarchy.", и гуру с SO не отстают: "Purpose of using GraphQL is to provide a schema over your entire application data to allow fetching it in a single roundtrip". Да и фронт-ендщикам проще — хорошая база, GraphQL движок, и бак-энд для всяких CRUD становится как бы и не нужен.

Здравствуйте, neFormal, Вы писали:

I>>Уже есть ПТУ где учат паре-тройке алгоритмов уровня сортировок, пхп, sql и, вуаля, новый девелопер пытается потрясти мир и оставить вмятину во вселенной.

F>из вузов приходят такие же.
F>а где взять лучше?

Из профильных вузов выходят гораздо более квалифицированые кадры. По чистому программированию они наголову выше выходцев из ПТУ или непрофильных вузов. А еще у них в запасе куча важных вещей — сети, дискретка, архитектура компьютера, более-менее адекватное моделирование и куча других вещей.

Здравствуйте, Shmj, Вы писали:

S>Вот сейчас идет массированная пропоганда GraphQL. Как я понял, он позиционируется как замена REST и теперь API нужно писать на нем.

S>Что скажете?

Вот сравнение
REST API Industry Debate: OData vs GraphQL vs ORDS