А по этому закону, все поисковые результаты должны быть скрыты. Хотя я поддерживаю эту политику в отношении корпораций. А то получается, у маленьких людей куча проблем из-за одной картинки, просто потому, что денег на адвоката нет. А «поисковые» корпорации воруют петабайтами и ничего. Вот если б законодательно закрепить коммерческое/некоммерческое использование для любых материалов, а еще лучше для поддержки малого бизнеса оценивать полученную выгоду и тоже разрешить, но кто ж такое пролоббирует…
Ваша «капитализация» учитывает более 50% потерянных биткоинов, которые нагенерировал Сатоши Накамото, а также первые майнеры. Другая часть биткоинов — хранится на холодных кошельках, и не торгуется нигде на биржах.
Я не называл конкретных цифр, только порядки. График с одной биржи — не аргумент. Приведите объемы торгов всех бирж за выбранный период.
Посмотрите капитализацию биткоина, прежде, чем говорить о 20$ млн, которые что-то могут надуть.
В целом, история с Tether еще не закончилась, но какие-то сомнительные телодвижения и правда имеют место быть, судя по новостям.
Было бы намного практичнее, если бы вы привели пример API, реализованного на GraphQL и документации к нему.
Я привел пример https://developer.github.com/v4/, ну и https://developer.github.com/v3/
Гитхаб шли по абсолютно тому же пути, придумывали способы описать запрашиваемые поля, а когда вышла спека GraphQL просто заюзали его.
По поводу дыр в безопасности — насколько я понимаю на GraphQL довольно сложно реализовать систему ролей пользователей, т.к. существует почти бесконечное множество возможных запросов.
Нет, это не так, теоретически запросов бесконечное множество, но только благодаря «бесконечной» вложенности. Но из-за строгой типизации любые мета-вопросы, будь то документация, или права доступа, решаются на уровне конкретного типа, а не запроса. GraphQL одновременно и достаточно кастомизируемые запросы и ограниченные типами. И вы правы, не было хотя бы одной составляющей, был бы другой разговор
posts { comments { posts } } }
Где, posts Array Of Post, а на Post свои права доступа, а на вложенный Post те же самые права доступа и та же самая документация.
Но опять же, GraphQL абсолютно не заставляет вас быть настолько гибкими, пожалуйста. реализуйте свои явные точки входа, тогда в виде бонуса будет удобный синтаксис и уменьшенный размер пакета из-за выбора полей.
Если так, то это не сильно отличается от какого-то простого HTTP/WEB API, и отличие только в том, что в ответ приходит ограниченный набор данных.
Так GraphQL и есть язык, т.е. синтаксис, не знаю откуда столько мнений, что это какое-то серверное решение. Видимо, желание иметь серебряную пулю затмевает глаза.
Зависит от вашей СУБД, в общем случае, смотря, что выгоднее, так же, как и всегда.
2. делать «оптимизацию», то получим 1 большой запрос и в маппинге просто результаты будем разгребать.
но в этом случае будет сложный запрос как в случае с комментами, так и без них. Это тоже плохо.
Если это для вас плохо, а предыдущий вариант, например, медленный, просто не закладывайте в схему GraphQL таких возможностей. Опять же, GraphQL тут не причем, разделение нагрузки между клиентом и сервером задача каждого проекта.
3. делать «по-умному»,
Опять же, зависит от схемы, в данном случае схема может плясать от бэкенда, пойти по пути Rails и сделать автоматическую схему из моделей, со всеми методами (createModel1, updateModel1, deleteModel1), универсальными фильтрами (примерно, как в Mongo posts (filter:{ nameLike: «name» }) ), но с иерархической вложенностью. Такая схема не потребует для поддержки ни строчки кода. Только кастомные запросы, типа авторизации, остальное все автоматически, знай, модели добавляй. Тут пока готовых качественных решений нет, однако биндинги ко многим ORM уже существуют.
Боже, причем тут HTTP? Как он поможет вам выбрать поля?
GraphQL приводит к переизобретению REST, позволяя откладывать проектирование ограничений эндпоинтов «на потом».
«На потом» — это в вашей голове.
Для тех, кто не осилил REST/HTTP
Боже…
всё эти коды ошибок, непонятные заголовки, понятия идемпотентности и прочая ересь
Ну прям очень сложно, бедные facebook-архитекторы… А идемпотетность вообще только в мечтах и демагогических высказываниях, когда по сути сказать нечего.
«Мне нужно просто выполнить действие на сервере! Зачем мне отдельный ресурс?»
Ну да, давайте спор функциональщина/ООП головного мозга ввернем, чо уж там. И да, не хочу я все называть существительными, назовите это «ниасилил» или порогом вхождения, обычно, это называют здравым смыслом. Это в REST пытаются делать все ресурсами, просто подогнать под удобный, элементарный формат, никакого отношения к реальному миру и языку это не имеет, просто 90% случаев выгоднее, чем 10%.
Вашу точку зрения я понял, вместо аргументов по теме, оскорбления в адрес собеседника, удачи.
Откуда берется идея, что фронтенд что-то диктует? GraphQL абсолютно не об этом, это всего лишь формат передачи данных, все остальное, и вложенность, и сложность, и известность всех таблиц — решается индивидуально! Не выдумывайте проблемы там, где их нет.
Еще раз, нет никаких проблем в анализе запроса, смотрим, требуется ли клиенту поле «дерево комментариев» и если да, джойним что надо (в вашем случае, запрашиваем второй endpoint, вместо первого). Рассматривайте GraphQL, как возможность не плодя сущности в языке запроса делать то же самое. Т.е. вместо множества endpoint'ов posts и postsWithComments и postsWithAuthors есть
posts и posts { comments } и posts{ authors }.
И маппинг нужен только в случае, если у вас уже есть написанный сервер с готовыми обработчиками запросов для REST. Если пишете сервер для GraphQL с нуля — все эти вопросы уже заложены в архитектуру, вплоть до выбора БД. Уже есть и готовые облачные решения, правда не от крупных вендоров, ждем и их. Parse с поддержкой GraphQL — было бы вообще идеально.
GraphQL — ради одной точки входа создаём себе кучу проблем вроде непредсказуемого API c потенциальными дырами в безопасности
Никто не мешает в GraphQL реализовать ресурсы в точность так же для CRUD. Откуда берется непредсказуемость и дыры — не ясно, посмотрите примеры, github, например.
Можете даже root-объекты назвать по привычке GET DELETE PUT POST
Все верно, GraphQL — логичное развитие не только REST, но и многих других (и OData и RPC). Здесь есть один нюанс, что промежуточного состояния как бы нет, но за счет графовой структуры мы можем состояние как бы «засунуть» на вершину, а потом по ребрам передать. А сейчас то же самое с последовательными запросами (batch) в рамках одного.
Главное отличие — велосипед написан, он вполне адекватен, выполняет все, что декларирует, зафиксирован, есть поддержка крупного вендора. Ну и удобный синтаксис, наверное, главное.
На самом деле, нет. Фильтрация, группировка и сортировка обычно происходит на верхнем уровне запроса, остальные джойны — по уже выбранным айди. А здесь уже проблем не так много, во-первых, даже дополнительные запросы будут очень легковесны, во-вторых, чаще всего бэкенд, это не просто выборка из реляционной БД и многие вещи лежат в кэше. Это из простых вариантов. А вообще, есть и поинтереснее решение, хотя оно применяются и в любой другой парадигме — это динамический бэкенд, это статистика запросов, на основе которой, определенные джойны выполняются заранее для определенных моделей.
Да и тема слишком узка, для малых проектов, все это не важно, для крупных, там все равно кэширующие решения будут сложнее, чем джойны.
Дальше, никто не мешает, в конце концов, обрабатывать на сервере запрос, как единый и знать, какие джойны понадобятся, текущие популярные реализации в виде иерархических подзапросов — всего лишь один из вариантов. Можно маппить весь запрос на SQL, можно хотя бы вычислять джойны, что угодно.
Потому, что GraphQL не про сервер, а про декларативное представление куска данных, но с описанными типами.
GraphQL себя так не позиционирует, откройте документацию http://graphql.org/:
Ask for what you need, get exactly that
Точность получаемых данных, т.е. выбор только нужных полей, с точностью до одного.
Get many resources in a single request
Представление сложной выборки с помощью одного запроса, с добавлением batch можно получить реально ВСЕ, что нужно одним запросом.
Describe what’s possible with a type system
Строгая типизация запроса, фишка именно в том, что типы включены в спецификацию!
Все сказки про backend — лишь сказки, GraphQL не решает проблем на сервере, но и не создает их, попробуйте и увидите, что ничего не меняется в этом плане. А вот клиент-серверное взаимодействие становится на порядок удобнее. Ну, пока инструменты еще не все готовы, но даже уже с тем, что есть. А уж возможностей понаписать удобств из-за типизации и глубокой интроспекции — сколько угодно, вопрос времени.
Если кто не понял, основная задача сейчас — закрыть провайдеров, они же не смогут выполнять эти законы. А когда останется 4 «государственных» — все будет проще.
У человека нет роли быть универсальным, а вот для дизайна глобальных проектов это большая проблема, в итоге все сводится к минимализму, там где для каждой конкретной группы могло бы быть чудом. Причем корпорации опять совершают эту же ошибку наделяя единым именем помощников — Сири не может быть прекрасной для всех, сухая, черствая, бездушная тварь, вот идеальный дизайн для миллиардов.
Речь о том, что в GraphQL нет ничего громоздкого, скорее наборот, это один из самых минималистичных способов записи запроса данных (или представления данных). Мультидревовидная структура с поддержкой функций и директив покрывает большинство сценариев, как показали дальнейшие исследования, не хватает только последовательных запросов (batching), что легко решается. https://dev-blog.apollodata.com/new-features-in-graphql-batch-defer-stream-live-and-subscribe-7585d0c28b07
Я не называл конкретных цифр, только порядки. График с одной биржи — не аргумент. Приведите объемы торгов всех бирж за выбранный период.
В целом, история с Tether еще не закончилась, но какие-то сомнительные телодвижения и правда имеют место быть, судя по новостям.
502 Bad Gateway
Can't connect to Nemesida Scanner API (https://nemesida-security.com/ns/keys/auth_api)
Я привел пример https://developer.github.com/v4/, ну и https://developer.github.com/v3/
Гитхаб шли по абсолютно тому же пути, придумывали способы описать запрашиваемые поля, а когда вышла спека GraphQL просто заюзали его.
Нет, это не так, теоретически запросов бесконечное множество, но только благодаря «бесконечной» вложенности. Но из-за строгой типизации любые мета-вопросы, будь то документация, или права доступа, решаются на уровне конкретного типа, а не запроса. GraphQL одновременно и достаточно кастомизируемые запросы и ограниченные типами. И вы правы, не было хотя бы одной составляющей, был бы другой разговор
posts { comments { posts } } }
Где, posts Array Of Post, а на Post свои права доступа, а на вложенный Post те же самые права доступа и та же самая документация.
Но опять же, GraphQL абсолютно не заставляет вас быть настолько гибкими, пожалуйста. реализуйте свои явные точки входа, тогда в виде бонуса будет удобный синтаксис и уменьшенный размер пакета из-за выбора полей.
Так GraphQL и есть язык, т.е. синтаксис, не знаю откуда столько мнений, что это какое-то серверное решение. Видимо, желание иметь серебряную пулю затмевает глаза.
Если это для вас плохо, а предыдущий вариант, например, медленный, просто не закладывайте в схему GraphQL таких возможностей. Опять же, GraphQL тут не причем, разделение нагрузки между клиентом и сервером задача каждого проекта.
Опять же, зависит от схемы, в данном случае схема может плясать от бэкенда, пойти по пути Rails и сделать автоматическую схему из моделей, со всеми методами (createModel1, updateModel1, deleteModel1), универсальными фильтрами (примерно, как в Mongo posts (filter:{ nameLike: «name» }) ), но с иерархической вложенностью. Такая схема не потребует для поддержки ни строчки кода. Только кастомные запросы, типа авторизации, остальное все автоматически, знай, модели добавляй. Тут пока готовых качественных решений нет, однако биндинги ко многим ORM уже существуют.
«На потом» — это в вашей голове.
Боже…
Ну прям очень сложно, бедные facebook-архитекторы… А идемпотетность вообще только в мечтах и демагогических высказываниях, когда по сути сказать нечего.
Ну да, давайте спор функциональщина/ООП головного мозга ввернем, чо уж там. И да, не хочу я все называть существительными, назовите это «ниасилил» или порогом вхождения, обычно, это называют здравым смыслом. Это в REST пытаются делать все ресурсами, просто подогнать под удобный, элементарный формат, никакого отношения к реальному миру и языку это не имеет, просто 90% случаев выгоднее, чем 10%.
Вашу точку зрения я понял, вместо аргументов по теме, оскорбления в адрес собеседника, удачи.
Еще раз, нет никаких проблем в анализе запроса, смотрим, требуется ли клиенту поле «дерево комментариев» и если да, джойним что надо (в вашем случае, запрашиваем второй endpoint, вместо первого). Рассматривайте GraphQL, как возможность не плодя сущности в языке запроса делать то же самое. Т.е. вместо множества endpoint'ов posts и postsWithComments и postsWithAuthors есть
posts и posts { comments } и posts{ authors }.
И маппинг нужен только в случае, если у вас уже есть написанный сервер с готовыми обработчиками запросов для REST. Если пишете сервер для GraphQL с нуля — все эти вопросы уже заложены в архитектуру, вплоть до выбора БД. Уже есть и готовые облачные решения, правда не от крупных вендоров, ждем и их. Parse с поддержкой GraphQL — было бы вообще идеально.
Никто не мешает в GraphQL реализовать ресурсы в точность так же для CRUD. Откуда берется непредсказуемость и дыры — не ясно, посмотрите примеры, github, например.
Можете даже root-объекты назвать по привычке GET DELETE PUT POST
Главное отличие — велосипед написан, он вполне адекватен, выполняет все, что декларирует, зафиксирован, есть поддержка крупного вендора. Ну и удобный синтаксис, наверное, главное.
Да и тема слишком узка, для малых проектов, все это не важно, для крупных, там все равно кэширующие решения будут сложнее, чем джойны.
Дальше, никто не мешает, в конце концов, обрабатывать на сервере запрос, как единый и знать, какие джойны понадобятся, текущие популярные реализации в виде иерархических подзапросов — всего лишь один из вариантов. Можно маппить весь запрос на SQL, можно хотя бы вычислять джойны, что угодно.
Потому, что GraphQL не про сервер, а про декларативное представление куска данных, но с описанными типами.
Точность получаемых данных, т.е. выбор только нужных полей, с точностью до одного.
Представление сложной выборки с помощью одного запроса, с добавлением batch можно получить реально ВСЕ, что нужно одним запросом.
Строгая типизация запроса, фишка именно в том, что типы включены в спецификацию!
Все сказки про backend — лишь сказки, GraphQL не решает проблем на сервере, но и не создает их, попробуйте и увидите, что ничего не меняется в этом плане. А вот клиент-серверное взаимодействие становится на порядок удобнее. Ну, пока инструменты еще не все готовы, но даже уже с тем, что есть. А уж возможностей понаписать удобств из-за типизации и глубокой интроспекции — сколько угодно, вопрос времени.
https://dev-blog.apollodata.com/new-features-in-graphql-batch-defer-stream-live-and-subscribe-7585d0c28b07