Здравствуйте, turbocode, Вы писали:
ИД>>REST никак не помогает, когда есть пачка разных клиентов, которым нужны разные проекции данных. T>Выгрузить базу данных на клиента и там же её фильтровать через JavaScript — это супер идея.
Настоящий хипста-стайл. Веб, как обычно, рулится толпой ажитирующих мелкоплавающих товарищей, верящих в серебрянную пулю.
Здравствуйте, Kolesiki, Вы писали:
K>Во-первых, сразу в полный рост встаёт вопрос о защите. Все ли клиенты могут всё смотреть?? Во-вторых, нельзя просто так взять и простой перделкой заменить сложную систему. Для чего мы изобретали 3-звенную модель? Вот как раз для этого — чтобы на самом низком уровне — запросы данных, выше — бизнес логика и совсем наверху — клиент, от действий которого ничего не зависит — он в принципе не способен поломать защиту. А теперь вы вытаскиваете "уровень запросов к БД" поверх сервера приложений и... что? Шляпа навыворот, вот что.
В GraphQL нет запросов в их традиционном представлении. GraphQL -- это скорее про фильтрацию данных, чем про произвольные запросы. Ты объявляешь схему данных, которые ты готов выставить клиентам, а клиенты запрашивают, какие кусочки им интересны.
Вопрос защиты, конечно, стоит, но это ортогонально. Ты сам явно выставляешь то, что нужно и сам защищаешь отдельные части так, как тебе нужно.
Это не то же самое, что выставить наружу, например, SQL для запросов к твоей внутренней БД.
Почему-то многие, прочитав по верхам, начинают фантазировать в эту сторону. GraphQL -- это просто способ задать API так, что клиент автоматом получает контроль над тем, какие данные ему надо вернуть из результата.
K>Я не вижу ничего плохого в обилии функций. На то они и API, что это они решают, как и что ты будешь делать с сервером.
Да. И GraphQL позволяет тебе сразу задать спектр возможных API функций, см выше пример со страховым полисом.
Что-то подобное GraphQL может быть полезно для интеграций в энтерпрайзе. Там постоянно возникает задача выгрузки разных проекций данных и делать (и поддерживать) API на каждый случай трудно (особенно, если модель данных может произвольно расширятся во время имплементации).
Для backend for frontend сервисов тоже полезно. Когда тебе нужно поддерживать старые API на несколько лет назад, возникает желание делать более гибкие API, чтобы не приходилось каждый раз запиливать новые. Опять же, зачем старым клиентам отправлять данные, которые им не нужны? Это лишний траффик.
K>Да и не припомню каких-то таких страшных сценариев, где нужна вот такая вот навороченная "модель запросов".
Ещё раз, навороченной модели запросов в GraphQL нет.
K>А я даже над этими сервисами смеюсь — мой JSON-RPC ещё десяток лет проработает без колыханий.
Ой, ну нашёл чем гордиться. Наши убогие SOAP сервисы поди и через 30 лет ещё где-то будут работать
Здравствуйте, int64, Вы писали:
I>Как упал уровень разработчиков. Генерация строки для передачи команд на сервер и парсинг этой сроки на сервере называется: архитектурой, технологией. Скилом, достойным употребления в резюме.
Так надо учитывать, для кого это. Для современных пареньков, которые за час, не слезая с гироскутера, на Го навают то, что плюсовик будет писать три недели. Затем современный паренек укатит в барбершоп, а три десятка других современных пареньков еще полгода будут пытаться снизить число самоубийств пользователей, обреченных корпоративной политикой обмазываться продуктом жизнедеятельности современного паренька.
Ну, в перерывах между борьбой с нетранспилирующимся из-за апдейта минорной версии библиотеки на 17-м уровне вложенности ангуляром.
Индустрия не просто катится в говно, она уже грохнулась туда и медленно тонет.
Здравствуйте, Shmj, Вы писали:
S>Вроде писали в умных книжках, что хорошие инструменты экономят до 20% времени. Не в 10 раз, но 20% сэкономить можно.
Это глупые книжки.
Хорошие инструменты могут и в 100 раз быстрее результат получить. Причём есть хороший шанс что результат будет лучше.
Например, авторы вот этой штуки http://halide-lang.org/
За один день написали алгоритм, на оптимизацию которого программист из Adobe убил 3 месяца. Причем результат получился в 2 раза быстрее.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Shmj, Вы писали:
S>Вроде писали в умных книжках, что хорошие инструменты экономят до 20% времени. Не в 10 раз, но 20% сэкономить можно.
Похоже что реально хорошие инструменты этих книжек не читали и потому экономят гораздо больше.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>OData это просто протокол. А уж откуда и как наполнены источники данных, для которых он используется, это уже вопросы реализации. Но я понял, OData это недостаточно хипстерски.
адресация может быть к одному источнику и к нескольким.
одата умеет адресоваться к нескольким источникам? или она — слишком старпёрский унылый наколенный протокол для домашних страничек на пхп?
Здравствуйте, Ночной Смотрящий, Вы писали:
F>>или она — слишком старпёрский унылый наколенный протокол для домашних страничек на пхп? НС>Ну я и говорю, фатальный недостаток, недостаточно хипстерский.
ясно, понятно. ничего не знаешь, но имеешь мнение.
Здравствуйте, turbocode, Вы писали:
ИД>>Так я о чём и говорю -- поэтому и GraphQL (который делает фильтрацию на сервере)
T>На сервере можно сделать фильтрацию и без GraphQL.
И как ты сделаешь фильтрацию, если не знаешь что фильтровать?
GraphQL это как язык описания, что именно клиенту нужно, только и всего. Типа SQL.
Решаемая проблема в том, что если клиенту требуется какой-то запрос который не был предусмотрен сервером, сервер приходится менять.
С GraphQL сервер просто говорит какие данные у него в принципе есть (предоставляет схему данных) а клиент может запрашивать любую ее часть.
Также можно например легко добавлять новые данные в модель без страха поломать клиентов (особенно актуально если клиентов много и они разные)
Здравствуйте, neFormal, Вы писали:
НС>>Ну я и говорю, фатальный недостаток, недостаточно хипстерский. F>ясно, понятно. ничего не знаешь, но имеешь мнение.
Вот только это ты и велосипедеры из фейсбучека не знали про OData. Причем это, судя по всему, принципиальная позиция у хипста-стайл архитектов — существующие решения всегда плохие, и все надо делать с нуля.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Вот только это ты и велосипедеры из фейсбучека не знали про OData.
ну, я когда-то очень давно про него читал. мне он был не нужен.
сейчас есть несколько весьма схожих альтернатив. некоторые из них я юзал.
но ты не ответил на вопрос.
НС>P.S. Перешел на личности — слил.
аа, так ты посраться сюда пришёл. я-то думал, ты действительно что-то знаешь.
ну ладно, обмазывайтесь без меня.
bnk>И как ты сделаешь фильтрацию, если не знаешь что фильтровать?
На сервер передать параметры фильтра.
bnk>GraphQL это как язык описания, что именно клиенту нужно, только и всего. Типа SQL. bnk>Решаемая проблема в том, что если клиенту требуется какой-то запрос который не был предусмотрен сервером, сервер приходится менять.
Ну да выставить SQL наружу к базе и ничего менять на сервере не придется.
bnk>С GraphQL сервер просто говорит какие данные у него в принципе есть (предоставляет схему данных) а клиент может запрашивать любую ее часть.
Все это мне напоминает OLAP кубы, там тоже юзер получает многомерный куб данных и клиент может получать какой то срез данных из этого куба динамическими запросами.
bnk>Также можно например легко добавлять новые данные в модель без страха поломать клиентов (особенно актуально если клиентов много и они разные)
Новые данные в любом случае не должны ломать обратную совместимость.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Вот только это ты и велосипедеры из фейсбучека не знали про OData. F>>но ты не ответил на вопрос. НС>Какой?
Здравствуйте, turbocode, Вы писали:
ИД>>Так я о чём и говорю -- поэтому и GraphQL (который делает фильтрацию на сервере) T>На сервере можно сделать фильтрацию и без GraphQL.
