Зато через два года в РФ разрыв зарплат между IT и не-IT существенно уменьшится. Со временем будет каждый разработчик получать столько же сколько сантехник - прямо как в Германии.
> А на вход он может принять коллекцию вместо одного объекта?
Я делал реализацию с таким подходом (когда на входе коллекция), но у нее есть свои грабли — иногда у вас тип может быть в какой-нибудь generic обертке и у вас будет список оберток, а не конечных сущностей (В GraphQL типичный пример — Pagination and Edges).
В таком случае список надо резолвить на уровне этой обертки. И тогда она должна знать обо всех возможных своих детях и знать контекст запроса.
Это очень неудобно поддерживать. Понятно, что это можно обойти, но и у этого подхода есть цена. В моем случае она была более чем достаточной, чтобы отказаться от этого подхода.
> Потому что если вы посмотрите хорошо на мой вопрос — конкретно на то, что я цитировал — то выходит, что GraphQL на вложенных запросах как раз задыхается.
Как напишите. Напишите с асинхронной буферизацией (а-ля даталоадер) — будет работать хорошо и быстро.
> Во-вторых, если не пользоваться хаками EventLoop'а, как это делают в DataLoader
Я бы не сказал, что это хаки. Просто для оптимального результата нужно контролировать последовательность буферизации и загрузки следующего чанка (грубо говоря задавать стратегию по которой промисы резолвятся). Стандартный node не дает этого делать.
В принципе если работаешь не в node-окружении и можешь контролировать порядок исполнения промисов и добавления новых в очередь — нет там никаких хаков. Очереди и стратегии по их проходу.
> читать предлагается строго по одному элементу, чего я ну никак не ожидаю от действительно зрелой технологии, заточенной на оптимизацию доступа к данным.
Это немного некорректное понимание GraphQL. GraphQL — этой уйма компромисов самых разных областей. Связь фронтенда и бэкенда, доступ к данным, возможность использования с разными типами хранилищ, организация работы разных команд в компании и т.д. Сейчас даже микросервисы через него объединяют, чтоб с ума не сойти.
Если нужна только оптимизация доступа к данным — используйте SQL, Lucene, map/reduce и т.п. %)
Ваш пример не совсем понял. С DataLoader'ом конечно там будет один запрос для всех nutrition.
В вашем примере будет следующее:
1. Резолвер очередного nutrition добавит id родительского flavor в буффер даталоадера и вернет промис
2. GraphQL таким образом пройдет по всем flavor и получит у себя массив промисов для nutrition.
3. Когда не останется данных для синхронного обхода — будет ждать резолва промисов.
4. Тут в буфере DataLoader будут все flavor_id, и он выполнит один запрос для получения всех nutrition (в SQL что-то вроде `SELECT * FROM nutrition WHERE flavor_id IN (?);`)
5. По окончании — DataLoader зарезолвит все промисы для nutrition (вот здесь надо контролировать стратегию — либо GraphQL будет продолжать свой Loop после каждого зарезолвленного промиса, либо подождет, когда зарезолвятся все и будет уже проходить по всем новым данным. Все «хаки» DataLoader'а — чтобы обеспечить второй вариант)
Да нет там никаких танцев с бубнами. В GraphQL резолвер может вернуть Promise. То как именно вы группируете запросы и в какой момент резолвите — для GraphQL не важно.
> Причем эта особенность рубит на корню использование GraphQL где-либо кроме сайтика на 10 человек
Сильное утверждение. Но, конечно, ложное. Тот же бэкенд фейсбука вполне себе живет на GraphQL + Dataloader.
> Не говоря уже о том, что ORMки для реляционных баз как минимум все 1 к 1 склеят в один единственный запрос, а тут их всё равно будет много.
В реальности GraphQL + Dataloader (который в статье упоминается) также объединят в один запрос. А в некоторых случаях — еще и эффективнее (например, когда одинаковые сущности на разных уровнях запрашиваются).
Ну и надо помнить, что Dataloader'ом легко оборачивать и соединять разные источники данных (кэш, search engine, база, web-service), в отличие от ORM.
В общем на практике все это вполне себе хорошо работает. Проблема N+1 там решается неплохо.
Удивительно, никто не упомянул то, что изначально было selling point для GraphQL (во всех первых презентациях об этом было) — фрагменты.
Собственно, GraphQL — это удобный контракт между бэкендом и фронтендаом, а для SPA с компонентным подходом — фрагменты, лежащие рядом с UI-компонентами сильно упрощают поддержку приложения.
Как бы весь дизайн GraphQL идет от нужд фронтенда в первую очередь, поэтому чистые бэкендеры все его плюсы и не видят.
По факту, GraphQL — не всем подойдет, и может оказаться совсем не тем инструментом, который вам нужен.
Дайте технологию про которую нельзя такое сказать. И даже на вашем примере эта мысль не вполне раскрыта. В вашем случае (сложные CRUD'ы) и т.п. — какой же инструмент подошел бы вам лучше в итоге?
1. В GraphQL у вас клиент может запросить поле «author», а может и не запросить. Вы будете на сервере всегда делать джоин? А если подобных полей 10?
Чтоб это хоть как-то работало — придется смотреть, какие поля пользователь запрашивал, а какие — нет и в зависимости от этого строить разные запросы. Что существенно увеличит сложность системы.
2. В реальных проектах, которые чуть сложнее, чем дважды-два бывают уровни кэшей, бывают поисковые индексы, графовые индексы и т.д. и т.п. И та же проблема N+1 для них тоже актуальна.
Собственно, тот же Фейсбук не случайно использует именно подход, описанный в статье (см их проект dataloader).
Поэтому join'ы смогут эффективно решить лишь очень небольшое подмножество задач. Если этого хватает — отлично, но в общем случае на одних join'ах далеко не уедешь.
Вы спрашиваете о деталях, которые в данный момент, естественно, не известны никому. Мы лишь заглядываем в те принципиальные обсуждения, которые ведут эксперты от власти (через утечки в СМИ) и видим, что они обсуждают, сопоставляя с тем, что они могут сделать в принципе.
Детали там пока не прорабатывают (а если и прорабатывают, то нам этого не видно).
Что касается сертификатов — скорее всего вам самому придется добавлять их в доверенные, если хотите, чтобы приложения дальше хоть как-то работали. Хотя не исключаю, что со временем поставщиков OS, браузеров и другого софта законодательно обяжут добавлять его в доверенные при продаже.
Certificate pinning действительно несовместим с таким MITM и вопрос исключительно в том, что выберут владельцы сайтов и приложений — форсировать Certificate pinning, зная, что тогда они 100% прекращают работать в РФ или перестать его использовать.
Думаю, где-то там нас и ждет самый большой конфликт во всей этой истории.
А что за проблема с трафиком телеграмма, если у полиции в результате окажется сам приватный ключ клиента?
Зависит от протокола шифрования мессенджера. Если там есть какой-нибудь механизм для производных ключей, которые периодически обновляются и не хранятся, то расшифровка старого трафика будет затруднена (или вообще невозможна).
Поэтому надо изучать этот самый протокол. Но думаю, что большинство протоколов шифрования не учитывают такой случай, поэтому даже любопытно — есть ли кто-то, кто учитывает.
Так это и не будет скрываться. Вас просто поставят перед фактом: либо добавляете фальшивый корневой гос.сертификат в доверяемые, либо у вас просто не работает HTTPS.
Думаете кто-то вылезет из-за этого на улицу? Для большинства незаморачивающихся пользователей всё будет работать как и раньше, как только добавят фальшивый сертификат в доверенные (правда это конечно очень смешно выглядит при декларируемой цели борьбы с терактами и кибер-преступностью, но кого это волнует).
Есть конечно, некоторая надежда на Publiс Key Pinning, но вот не факт, что корпорации добровольно согласятся его вводить, зная, что так потеряют рынок.
Поэтому картина будущего:
— MITM для https
— VPN и мессенджеры по добровольной регистрации (white-листы)
Остальное запрещено и уголовка за использование — поймают первых 2-3х юзеров Tor'а или I2P, остальные сами быстро стухнут.
Это вполне реалистичная картина нашего будущего интернета. По крайней мере направление точно такое, а детали — посмотрим.
Прочитать может, расшифровать — нет. В остальном не понимаю, что ваш комментарий добавляет к моему.
Понятно, что хранить шифрованный трафик нет смысла и я об этом написал. Поняли это и они, только почему-то уже после принятия закона. То есть хранить смысла нет, но по закону хранить все же придется.
А если вы почитаете статью на Коммерсанте, то они обсуждают возможность модификации СОРМ, чтобы он работал как прокси (а не просто как параллельная читалка трафика, как сейчас) с возможностью MITM атак и подменой SSL сертификатов.
Что теоретически это возможно, если всех принудить принять некий государственный корневой сертификат как безусловно доверяемый (а если не примете — так и не будет у вас HTTPS работать).
Другое дело, что end-to-end шифрование мессенджеров и VPN расшифровать не смогут. Это да, но хранить мусорный трафик придется всё равно — это уже закон.
Послушайте, у нас и без закона Яровой был и есть ФСБшный СОРМ у каждого провайдера — практически полный аналог PRISM'а.
При желании ФСБ и сейчас может прочитать любой трафик. Закон Яровой — это совсем новый уровень трэша, когда провайдеров обязуют трафик хранить месяцами, а то и годами. Такого пока нет нигде. Ссылки вы даете вообще на аналог закона «О праве на забвение» — это совсем другой закон.
Но там ведь есть еще и продолжение истории. Уже после принятия закона неожиданно выяснилось, что большая часть трафика зашифрована и складировать и хранить придется цифровой мусор.
Но я думаю на этом не нужно останавливаться — нужно хранить вообще весь мусор страны 2 года. Ведь в нем тоже можно найти ценную информацию и следы террористов. Разве нет? Действительно не понятно, почему нужно делать исключение для физического мусора, если все равно можно заставить частников за свой счет построить отдельные мусорохранилища. Тем более, что сотрудники органов там будут смотреться, простите за тавтологию, довольно органично.
Мы переходим на kubernetes в данный момент. Если собираетесь работать с docker'ом в продакшне, то рано или поздно — все эти 100500 проблем вы поимеете всё равно.
Собственно, изначально протестировали всё на Google Container Engine — это и есть kubernetes.
Ну вот логи ваши, например. В kubernetes основная единица не контейнер, а pod — это набор сгруппированных контейнеров, которые имеют доступ к одним и тем же ресурсам. Скажем, вы можете создать отдельный контейнер с syslog, который будет доступен в рамках pod по заданному порту на localhost.
Потом этот контейнер с syslog можете просто подключать к своим сервисным pod'ам. Деплоймент, обнаружение сервисов, балансировка нагрузки на сервисы, поддержка заданного количества инстансов — все делает сам. Сетевая модель — на выбор тот же WeaveNet, Flannel, Calico.
Докер отдельно для серьезных проектов всё равно нуждается в системе оркестрации. Без Swarm, Mesos или Kubernetes от него мало прока в продакшне. Можно, конечно, многое допиливать и додумывать (что и пришлось вам делать), а можно взять полноценную систему оркестрации и сильно упростить себе жизнь.
Собственно Docker сейчас делает собственную оркестрацию — Swarm mode (в 1.12 появился впервые), который только пытается делать часть из того, что уже умеет Kubernetes для продакшна.
Ну и не стоит забывать, что Kubernetes — это опыт Гугла в управлении своими сервисами (те же инженеры пишут, что рулят их production-серверами)
Зато через два года в РФ разрыв зарплат между IT и не-IT существенно уменьшится. Со временем будет каждый разработчик получать столько же сколько сантехник - прямо как в Германии.
Также, смотрели rushjs? Если да, почему выбрали lerna? Мы думаем сбежать с lerna в rush.
Я делал реализацию с таким подходом (когда на входе коллекция), но у нее есть свои грабли — иногда у вас тип может быть в какой-нибудь generic обертке и у вас будет список оберток, а не конечных сущностей (В GraphQL типичный пример — Pagination and Edges).
В таком случае список надо резолвить на уровне этой обертки. И тогда она должна знать обо всех возможных своих детях и знать контекст запроса.
Это очень неудобно поддерживать. Понятно, что это можно обойти, но и у этого подхода есть цена. В моем случае она была более чем достаточной, чтобы отказаться от этого подхода.
> Потому что если вы посмотрите хорошо на мой вопрос — конкретно на то, что я цитировал — то выходит, что GraphQL на вложенных запросах как раз задыхается.
Как напишите. Напишите с асинхронной буферизацией (а-ля даталоадер) — будет работать хорошо и быстро.
> Во-вторых, если не пользоваться хаками EventLoop'а, как это делают в DataLoader
Я бы не сказал, что это хаки. Просто для оптимального результата нужно контролировать последовательность буферизации и загрузки следующего чанка (грубо говоря задавать стратегию по которой промисы резолвятся). Стандартный node не дает этого делать.
В принципе если работаешь не в node-окружении и можешь контролировать порядок исполнения промисов и добавления новых в очередь — нет там никаких хаков. Очереди и стратегии по их проходу.
> читать предлагается строго по одному элементу, чего я ну никак не ожидаю от действительно зрелой технологии, заточенной на оптимизацию доступа к данным.
Это немного некорректное понимание GraphQL. GraphQL — этой уйма компромисов самых разных областей. Связь фронтенда и бэкенда, доступ к данным, возможность использования с разными типами хранилищ, организация работы разных команд в компании и т.д. Сейчас даже микросервисы через него объединяют, чтоб с ума не сойти.
Если нужна только оптимизация доступа к данным — используйте SQL, Lucene, map/reduce и т.п. %)
Ваш пример не совсем понял. С DataLoader'ом конечно там будет один запрос для всех nutrition.
В вашем примере будет следующее:
1. Резолвер очередного nutrition добавит id родительского flavor в буффер даталоадера и вернет промис
2. GraphQL таким образом пройдет по всем flavor и получит у себя массив промисов для nutrition.
3. Когда не останется данных для синхронного обхода — будет ждать резолва промисов.
4. Тут в буфере DataLoader будут все flavor_id, и он выполнит один запрос для получения всех nutrition (в SQL что-то вроде `SELECT * FROM nutrition WHERE flavor_id IN (?);`)
5. По окончании — DataLoader зарезолвит все промисы для nutrition (вот здесь надо контролировать стратегию — либо GraphQL будет продолжать свой Loop после каждого зарезолвленного промиса, либо подождет, когда зарезолвятся все и будет уже проходить по всем новым данным. Все «хаки» DataLoader'а — чтобы обеспечить второй вариант)
> Причем эта особенность рубит на корню использование GraphQL где-либо кроме сайтика на 10 человек
Сильное утверждение. Но, конечно, ложное. Тот же бэкенд фейсбука вполне себе живет на GraphQL + Dataloader.
> Не говоря уже о том, что ORMки для реляционных баз как минимум все 1 к 1 склеят в один единственный запрос, а тут их всё равно будет много.
В реальности GraphQL + Dataloader (который в статье упоминается) также объединят в один запрос. А в некоторых случаях — еще и эффективнее (например, когда одинаковые сущности на разных уровнях запрашиваются).
Ну и надо помнить, что Dataloader'ом легко оборачивать и соединять разные источники данных (кэш, search engine, база, web-service), в отличие от ORM.
В общем на практике все это вполне себе хорошо работает. Проблема N+1 там решается неплохо.
Собственно, GraphQL — это удобный контракт между бэкендом и фронтендаом, а для SPA с компонентным подходом — фрагменты, лежащие рядом с UI-компонентами сильно упрощают поддержку приложения.
Как бы весь дизайн GraphQL идет от нужд фронтенда в первую очередь, поэтому чистые бэкендеры все его плюсы и не видят.
Дайте технологию про которую нельзя такое сказать. И даже на вашем примере эта мысль не вполне раскрыта. В вашем случае (сложные CRUD'ы) и т.п. — какой же инструмент подошел бы вам лучше в итоге?
Да ладно, вы читали за что Ампелонский под домашним арестом?
Чтоб это хоть как-то работало — придется смотреть, какие поля пользователь запрашивал, а какие — нет и в зависимости от этого строить разные запросы. Что существенно увеличит сложность системы.
2. В реальных проектах, которые чуть сложнее, чем дважды-два бывают уровни кэшей, бывают поисковые индексы, графовые индексы и т.д. и т.п. И та же проблема N+1 для них тоже актуальна.
Собственно, тот же Фейсбук не случайно использует именно подход, описанный в статье (см их проект dataloader).
Поэтому join'ы смогут эффективно решить лишь очень небольшое подмножество задач. Если этого хватает — отлично, но в общем случае на одних join'ах далеко не уедешь.
Детали там пока не прорабатывают (а если и прорабатывают, то нам этого не видно).
Что касается сертификатов — скорее всего вам самому придется добавлять их в доверенные, если хотите, чтобы приложения дальше хоть как-то работали. Хотя не исключаю, что со временем поставщиков OS, браузеров и другого софта законодательно обяжут добавлять его в доверенные при продаже.
Certificate pinning действительно несовместим с таким MITM и вопрос исключительно в том, что выберут владельцы сайтов и приложений — форсировать Certificate pinning, зная, что тогда они 100% прекращают работать в РФ или перестать его использовать.
Думаю, где-то там нас и ждет самый большой конфликт во всей этой истории.
Зависит от протокола шифрования мессенджера. Если там есть какой-нибудь механизм для производных ключей, которые периодически обновляются и не хранятся, то расшифровка старого трафика будет затруднена (или вообще невозможна).
Поэтому надо изучать этот самый протокол. Но думаю, что большинство протоколов шифрования не учитывают такой случай, поэтому даже любопытно — есть ли кто-то, кто учитывает.
Думаете кто-то вылезет из-за этого на улицу? Для большинства незаморачивающихся пользователей всё будет работать как и раньше, как только добавят фальшивый сертификат в доверенные (правда это конечно очень смешно выглядит при декларируемой цели борьбы с терактами и кибер-преступностью, но кого это волнует).
Есть конечно, некоторая надежда на Publiс Key Pinning, но вот не факт, что корпорации добровольно согласятся его вводить, зная, что так потеряют рынок.
Поэтому картина будущего:
— MITM для https
— VPN и мессенджеры по добровольной регистрации (white-листы)
Остальное запрещено и уголовка за использование — поймают первых 2-3х юзеров Tor'а или I2P, остальные сами быстро стухнут.
Это вполне реалистичная картина нашего будущего интернета. По крайней мере направление точно такое, а детали — посмотрим.
Понятно, что хранить шифрованный трафик нет смысла и я об этом написал. Поняли это и они, только почему-то уже после принятия закона. То есть хранить смысла нет, но по закону хранить все же придется.
А если вы почитаете статью на Коммерсанте, то они обсуждают возможность модификации СОРМ, чтобы он работал как прокси (а не просто как параллельная читалка трафика, как сейчас) с возможностью MITM атак и подменой SSL сертификатов.
Что теоретически это возможно, если всех принудить принять некий государственный корневой сертификат как безусловно доверяемый (а если не примете — так и не будет у вас HTTPS работать).
Другое дело, что end-to-end шифрование мессенджеров и VPN расшифровать не смогут. Это да, но хранить мусорный трафик придется всё равно — это уже закон.
При желании ФСБ и сейчас может прочитать любой трафик. Закон Яровой — это совсем новый уровень трэша, когда провайдеров обязуют трафик хранить месяцами, а то и годами. Такого пока нет нигде. Ссылки вы даете вообще на аналог закона «О праве на забвение» — это совсем другой закон.
Но там ведь есть еще и продолжение истории. Уже после принятия закона неожиданно выяснилось, что большая часть трафика зашифрована и складировать и хранить придется цифровой мусор.
Поэтому начали обсуждать поправки, как обойти шифрование в этих интернетах и хранить уже весь трафик в расшифрованном виде. Ну а если способ не найдут — значит будут хранить цифровой мусор (за наш с вами счет).
Но я думаю на этом не нужно останавливаться — нужно хранить вообще весь мусор страны 2 года. Ведь в нем тоже можно найти ценную информацию и следы террористов. Разве нет? Действительно не понятно, почему нужно делать исключение для физического мусора, если все равно можно заставить частников за свой счет построить отдельные мусорохранилища. Тем более, что сотрудники органов там будут смотреться, простите за тавтологию, довольно органично.
Спасибо. В любом случае интересно было почитать топик и комментарии. Понимаю, что с вашим масштабом лучше быть консервативнее %)
Просто любопытно. Вы по сути делаете свой orchestration на докере. Интересно было узнать чем не устраивают существующие решения.
Мы переходим на kubernetes в данный момент. Если собираетесь работать с docker'ом в продакшне, то рано или поздно — все эти 100500 проблем вы поимеете всё равно.
Собственно, изначально протестировали всё на Google Container Engine — это и есть kubernetes.
Ну вот логи ваши, например. В kubernetes основная единица не контейнер, а pod — это набор сгруппированных контейнеров, которые имеют доступ к одним и тем же ресурсам. Скажем, вы можете создать отдельный контейнер с syslog, который будет доступен в рамках pod по заданному порту на localhost.
Потом этот контейнер с syslog можете просто подключать к своим сервисным pod'ам. Деплоймент, обнаружение сервисов, балансировка нагрузки на сервисы, поддержка заданного количества инстансов — все делает сам. Сетевая модель — на выбор тот же WeaveNet, Flannel, Calico.
Докер отдельно для серьезных проектов всё равно нуждается в системе оркестрации. Без Swarm, Mesos или Kubernetes от него мало прока в продакшне. Можно, конечно, многое допиливать и додумывать (что и пришлось вам делать), а можно взять полноценную систему оркестрации и сильно упростить себе жизнь.
Собственно Docker сейчас делает собственную оркестрацию — Swarm mode (в 1.12 появился впервые), который только пытается делать часть из того, что уже умеет Kubernetes для продакшна.
Ну и не стоит забывать, что Kubernetes — это опыт Гугла в управлении своими сервисами (те же инженеры пишут, что рулят их production-серверами)
Смотрели Kubernetes?