Я не обсуждаю конкретный закон, он немножко не в ту сторону пошёл, как и некоторые другие.
Я обсуждаю общую !цель! санкций. Которая, на мой взгляд это экономическое ослабление РФ. То, что многие средства достижения этой цели несколько неадекватны (или показавшие себя такими в силу специфики экономики Рф), нисколько не меняет цели. Европейские политики тоже люди, тоже ошибаются. Главное, чтобы они признали ошибки и вводили санкции более таргетированно (уж извините за такую позицию) против тех, кто действительно в это вовлечён.
На чём основано моё предположение о цели? На словах политиков и на фактах в виде снижения импорта в ЕС из России.
Помимо туристической визы, которую немного сложнее получить чем раньше, есть рабочая виза. Её и получают и делают без проблем (по крайней мере в Германии).
Просто люди гораздо меньше ездят (в ЕС) из-за нескольких факторов
Байки про то, что визу больше нельзя получить
Усложнился процесс
Это стало гораздо дороже, например в моём случае билеты выросли в цене в 3 раза
Более того, при таком подходе ты отсекаешь бесконечные траты на HR, и приступать к работе можешь на следующий день.
С такими после месяца - байбай
Был такой мемасик. Одна минута планирования экономит 10 минут исполнения. Но верно и обратное, 10 минут исполнения экономит минуту планирования!
Зачем тратить дни HR'ов, если можно тратить месяцы разработчиков.
Никакая метрика не покажет вам, хорошо ли написана программа. Только результат работы этой программы.
Категорично не согласен. Результат работы программы вообще не показывает, хорошо ли она написана. Хорошо ли программа/фича написана, покажет количество времени, которое придётся потратить на её поддержку (баги, рефакторинг и т.п.).
Разумеется я смотрю только с колокольни долгоживущего продукта. А не проекта, который написал, зарелизил и забыл. Максимум небольшая платная поддержка. В таком случае да, единственное что имеет значение, работает программа или нет. Но я бы не употреблял термин "хорошо написана". Если пациенту сделали операцию, и на следующий день его сбила машина, это не значит, что операция была сделана хорошо. Это значит, что её качество не имело значение.
Я считаю, что неправильно осуждать технологию за то, что её неправильно используют.
И по моему мнению, бекенд для графкл должны разрабатывать бекендеры, так у них будет больше мотивации и возможностей сделать адекватную реализацию. И лучше понимание бизнес доменов.
Иначе и приходим к ситуации, что бедные фронты, в погоне за экономией своих трудозатрат, пытаются интегрировать непростую технологию поверх неподготовленного фундамента.
Графкл это надстройка над АПИ. Если ваш АПИ это БД или плохой рест, то проблема не в надстройке.
Если люди идут по пути "сделать проще", то это их осознанный, и в каких то случаях правильный, выбор. Но они должны понимать, что это костыль, и у каждого костыля есть цена.
Я не говорю, что графкл идеален и его должны использовать все. Скорее, он подойдёт для меньшинства проектов. Я лишь за объективную оценку технологии.
В целом согласен с вашей точной зрения, что ещё один уровень абстракции снижает производительность.
Но не согласен с логикой про БД и N+1 (и очень большие проекты).
Графкл это абстракция над сервисами (а не над БД). Соответственно все оптимизации с БД ложатся на плечи соответствующих сервисов. Задача графкл это их склеить.
Если сервисы предоставляют убогий и не оптимальный АПИ, то это проблема не графкл, вам ни одна технология не решит эту проблему.
По факту, кто-то всегда должен склеивать данные для UI:
Либо это делает бэк в кастомных запросах и отдает толстые ДТО (увеличение времени разработки + дорогой maintenance)
Либо это делает фронт, дёргая десяток ендпоинтов (много работы на фронте + никаких возможностей для оптимизации)
Либо это делает дополнительная прослойка, например графкл (сложность поддержки этой прослойки + нет возможностей для оптимизации, только страховка от больших запросов)
Каждый выбирает сам. По мне, если мы говорим о команде из нескольких человек и долгоживущем продукте, первый и последний пункты несостоятельны. Инвестиция в графкл + оптимизацию АПИ сервисов на большом отрезке себя окупает. Потому что доменная модель меняется гораздо реже, чем UI.
Если вы разрабатываете в одиночку проект за полгода и забываете о нём, то разумеется такая инвестиция ничего не даёт.
Можете пжл пояснить на примере? В т.ч. "сильно связный граф"
Я не знаю как получить пару десятков мегабайт на фронте на паре уровней вложенности. И более того, не знаю как должен выглядеть UI для отображения всех этих данных. Разумеется если мы не рисуем таблицу на десятки тысяч строк и 100 столбцов.
Честно говоря не знаю, почему это невероятное усложнение коммуникаций. Graphql клиент не очень сложный, оверхед помимо реста, это только указать список необходимых полей.
Да, он даёт нехилый оверхед на бекенде, если речь идёт о нескольких десятках несвязанных запросов (типа один для заказов, другой для заказчиков, третий для продуктов).
Однако, если одни и те же данные нужны в десятке разных срезов, то оверхед на бойлерплейт и поддержку гораздо выше.
Не уверен насчёт вашей предметной области, но из того, что встречал на практике, кастомные ендпоинты нужны только для модификации данных (ака мутации в графкл), но эти эндпоинты могут возвращать одинаковые данные. По крайней мере из одной центральной модели. А не так, что у нас есть UseCase1OrderDto, UseCase2OrderDto, итд.
Ну и опять же, это вопрос масштаба. Если у вас требуется только один уровень вложенности, и то не всегда, то конечно, графкл не нужен. Но и категорично отвергать другие подходы не стоит, т.к. у всех разные случаи.
Graphql и Json-RPC это немного разные вещи. Graphql про снижение зависимости разработчиков клиента от разработчиков сервера (graphql - querylanguage). Json-RPC про оптимизацию коммуникации (remote procedure call protocol).
Для разных клиентов (например разные экраны в приложении) одни и те же данные нужны в разном виде. И если с обычными полями всё просто (можно сразу все отсылать), то со связанными сущностями сложнее, т.к. нельзя их загружать все, на всякий случай.
Поэтому либо бекенд на каждый чих клиента должен делать новый api (например, api: getOrderWithProducts, getOrderWithCustomers, getOrderWithProductsAndCustomers). Либо бекенд делает только "одноуровневый" API, но тогда клиент должен это всё склеивать у себя. И если у вас несколько разных клиентов (например, другие сервисы, интеграция с другой стороной и frontend), то значит и склейка будет реализована несколько раз.
У нас frontend очень радуется graphql, потому что это сильно упрощает им работу. Бекенд не рад, т.к. это много работы по созданию резолверов и не самая тривиальная реализация, для изначальной схемы. А то, что бекендеров не дёргают на каждый чих, они и не замечают.
Если брать определение коррупции (по крайней мере с вики), то да, коррупция в России это главная проблема. Если бы её не было, то никто бы и не отдавал преступные приказы, или бы их никто не слушал
Я не про это писал, извините. Я не полностью скопировал цитату из поста. Там утверждалось, что
В RabbitMQ обязательно нужно знать, сколько у вас получателей. Особенно это актуально в микросервисном мире, где количество реплик сервиса меняется динамически.
В случае Fanout Exchange количество получателей и тем более реплик, значения не имеет. Либо я неправильно понял, как это работает, по описанию
Разумеется, в kafka это тоже есть. Там по факту только это и есть.
Я бы не утверждал так однозначно. Kafka может потерять сообщения, а в RabbitMQ есть, как вы написали, есть Fanout Exchange, который должен работать с любым динамическим числом подов.
Я не работал в продакшене ни с той, ни с другой технологией, но когда выбирал платформу для event-driven, решил не в пользу кафки. Там слишком много минусов. У классических брокеров гораздо больше фишек, за что приходится платить масштабированием.
Меряться смертями это ещё более странная практика. Опять же это будут частные случаи, которые ничего не показывают.
Так статистика по смертности и поднялась, так как туда попали и те, у кого подтвержденного ковида не было, там он появлялся. Медики это не со зла, они - идейные борцы за денежные знаки, повышенные выплаты за ковидных пациентов.
Есть доказательства, статистика? И желательно не в России, где статистики не существует, а только нарисованные числа.
В примере, который я привел выше, кроме прививок никаких других факторов я не помню. Ограничения на этом временном отрезке ни добавляли ни снимали.
Это серьезный вопрос, и чтобы на него ответить, нужно перелопатить огромное количество информации
Например испытания вакцин, где указывается процент тяжёлых случаев и смертей для вакцинированных.
И, как по мне, это самый важный вопрос. Не ответив на него, нельзя строить никакие умозаключения
Делать выводы на основе частных случаев, это очень странная практика.
У вас есть объяснение тому, что через несколько месяцев после начала вакцинации в Германии (другие страны не смотрел), % смертей в несколько раз снизился? Да, болело столько же людей, но умирало гораздо меньше
Я не обсуждаю конкретный закон, он немножко не в ту сторону пошёл, как и некоторые другие.
Я обсуждаю общую !цель! санкций. Которая, на мой взгляд это экономическое ослабление РФ. То, что многие средства достижения этой цели несколько неадекватны (или показавшие себя такими в силу специфики экономики Рф), нисколько не меняет цели. Европейские политики тоже люди, тоже ошибаются. Главное, чтобы они признали ошибки и вводили санкции более таргетированно (уж извините за такую позицию) против тех, кто действительно в это вовлечён.
На чём основано моё предположение о цели? На словах политиков и на фактах в виде снижения импорта в ЕС из России.
Откуда такая информация про основную цель?
Совершенно с этим не спорю. Я спорю исключительно с популярным мифом, что ЕС закрыта для граждан РФ.
Желающие и тем кому нужно, попасть могут.
ПС я не изучал вопрос, но я так понимаю, что деньги наличкой везти в любую страну придётся?
Зачем их посылать? Просто не езжайте к ним, они этого не заслужили. Пусть страдают
Да, всё это можно до сих пор делать, и делают.
Помимо туристической визы, которую немного сложнее получить чем раньше, есть рабочая виза. Её и получают и делают без проблем (по крайней мере в Германии).
Просто люди гораздо меньше ездят (в ЕС) из-за нескольких факторов
Байки про то, что визу больше нельзя получить
Усложнился процесс
Это стало гораздо дороже, например в моём случае билеты выросли в цене в 3 раза
Вроде прямое, за их счёт банкет
Был такой мемасик. Одна минута планирования экономит 10 минут исполнения. Но верно и обратное, 10 минут исполнения экономит минуту планирования!
Зачем тратить дни HR'ов, если можно тратить месяцы разработчиков.
Категорично не согласен. Результат работы программы вообще не показывает, хорошо ли она написана. Хорошо ли программа/фича написана, покажет количество времени, которое придётся потратить на её поддержку (баги, рефакторинг и т.п.).
Разумеется я смотрю только с колокольни долгоживущего продукта. А не проекта, который написал, зарелизил и забыл. Максимум небольшая платная поддержка. В таком случае да, единственное что имеет значение, работает программа или нет. Но я бы не употреблял термин "хорошо написана". Если пациенту сделали операцию, и на следующий день его сбила машина, это не значит, что операция была сделана хорошо. Это значит, что её качество не имело значение.
Договорились, graphql это плохой инструмент в руках фронтенд разработчиков :)
Я считаю, что неправильно осуждать технологию за то, что её неправильно используют.
И по моему мнению, бекенд для графкл должны разрабатывать бекендеры, так у них будет больше мотивации и возможностей сделать адекватную реализацию. И лучше понимание бизнес доменов.
Иначе и приходим к ситуации, что бедные фронты, в погоне за экономией своих трудозатрат, пытаются интегрировать непростую технологию поверх неподготовленного фундамента.
Графкл это надстройка над АПИ. Если ваш АПИ это БД или плохой рест, то проблема не в надстройке.
Если люди идут по пути "сделать проще", то это их осознанный, и в каких то случаях правильный, выбор. Но они должны понимать, что это костыль, и у каждого костыля есть цена.
Я не говорю, что графкл идеален и его должны использовать все. Скорее, он подойдёт для меньшинства проектов. Я лишь за объективную оценку технологии.
В целом согласен с вашей точной зрения, что ещё один уровень абстракции снижает производительность.
Но не согласен с логикой про БД и N+1 (и очень большие проекты).
Графкл это абстракция над сервисами (а не над БД). Соответственно все оптимизации с БД ложатся на плечи соответствующих сервисов. Задача графкл это их склеить.
Если сервисы предоставляют убогий и не оптимальный АПИ, то это проблема не графкл, вам ни одна технология не решит эту проблему.
По факту, кто-то всегда должен склеивать данные для UI:
Либо это делает бэк в кастомных запросах и отдает толстые ДТО (увеличение времени разработки + дорогой maintenance)
Либо это делает фронт, дёргая десяток ендпоинтов (много работы на фронте + никаких возможностей для оптимизации)
Либо это делает дополнительная прослойка, например графкл (сложность поддержки этой прослойки + нет возможностей для оптимизации, только страховка от больших запросов)
Каждый выбирает сам. По мне, если мы говорим о команде из нескольких человек и долгоживущем продукте, первый и последний пункты несостоятельны. Инвестиция в графкл + оптимизацию АПИ сервисов на большом отрезке себя окупает. Потому что доменная модель меняется гораздо реже, чем UI.
Если вы разрабатываете в одиночку проект за полгода и забываете о нём, то разумеется такая инвестиция ничего не даёт.
Не совсем понятно, при чём тут graphql тогда, если данные так же раздуваются через REST или через большинство других протоколов.
И, как вам справедливо отметили, в представленном примере порядок увеличен за счёт body, а не дупликации.
Более того, в отличии от стандартных подходов, graphql вам позволяет снизить ущерб от дупликации, тем что вы гораздо меньше полей будете доставать
В реальном UI для списка из issues, у вас несколько полей всего.
Но в целом проблема дубликации существует, тут вы правы. Но то что у вас это всё раздувалось до десятков мегабайт мне кажется очень странным.
Можете пжл пояснить на примере? В т.ч. "сильно связный граф"
Я не знаю как получить пару десятков мегабайт на фронте на паре уровней вложенности. И более того, не знаю как должен выглядеть UI для отображения всех этих данных. Разумеется если мы не рисуем таблицу на десятки тысяч строк и 100 столбцов.
Честно говоря не знаю, почему это невероятное усложнение коммуникаций. Graphql клиент не очень сложный, оверхед помимо реста, это только указать список необходимых полей.
Да, он даёт нехилый оверхед на бекенде, если речь идёт о нескольких десятках несвязанных запросов (типа один для заказов, другой для заказчиков, третий для продуктов).
Однако, если одни и те же данные нужны в десятке разных срезов, то оверхед на бойлерплейт и поддержку гораздо выше.
Не уверен насчёт вашей предметной области, но из того, что встречал на практике, кастомные ендпоинты нужны только для модификации данных (ака мутации в графкл), но эти эндпоинты могут возвращать одинаковые данные. По крайней мере из одной центральной модели. А не так, что у нас есть UseCase1OrderDto, UseCase2OrderDto, итд.
Ну и опять же, это вопрос масштаба. Если у вас требуется только один уровень вложенности, и то не всегда, то конечно, графкл не нужен. Но и категорично отвергать другие подходы не стоит, т.к. у всех разные случаи.
Graphql и Json-RPC это немного разные вещи. Graphql про снижение зависимости разработчиков клиента от разработчиков сервера (graphql - query language). Json-RPC про оптимизацию коммуникации (remote procedure call protocol).
Для разных клиентов (например разные экраны в приложении) одни и те же данные нужны в разном виде. И если с обычными полями всё просто (можно сразу все отсылать), то со связанными сущностями сложнее, т.к. нельзя их загружать все, на всякий случай.
Поэтому либо бекенд на каждый чих клиента должен делать новый api (например, api: getOrderWithProducts, getOrderWithCustomers, getOrderWithProductsAndCustomers). Либо бекенд делает только "одноуровневый" API, но тогда клиент должен это всё склеивать у себя. И если у вас несколько разных клиентов (например, другие сервисы, интеграция с другой стороной и frontend), то значит и склейка будет реализована несколько раз.
У нас frontend очень радуется graphql, потому что это сильно упрощает им работу. Бекенд не рад, т.к. это много работы по созданию резолверов и не самая тривиальная реализация, для изначальной схемы. А то, что бекендеров не дёргают на каждый чих, они и не замечают.
Если брать определение коррупции (по крайней мере с вики), то да, коррупция в России это главная проблема. Если бы её не было, то никто бы и не отдавал преступные приказы, или бы их никто не слушал
https://developer20.com/when-you-can-nose-messages-in-kafka/
Я не про это писал, извините. Я не полностью скопировал цитату из поста. Там утверждалось, что
В случае Fanout Exchange количество получателей и тем более реплик, значения не имеет. Либо я неправильно понял, как это работает, по описанию
Разумеется, в kafka это тоже есть. Там по факту только это и есть.
Более того, в RabbitMQ оно есть из коробки.
А в Kafka его нужно как-то самому велосипедить.
Я бы не утверждал так однозначно. Kafka может потерять сообщения, а в RabbitMQ есть, как вы написали, есть Fanout Exchange, который должен работать с любым динамическим числом подов.
Я не работал в продакшене ни с той, ни с другой технологией, но когда выбирал платформу для event-driven, решил не в пользу кафки. Там слишком много минусов. У классических брокеров гораздо больше фишек, за что приходится платить масштабированием.
Меряться смертями это ещё более странная практика. Опять же это будут частные случаи, которые ничего не показывают.
Есть доказательства, статистика? И желательно не в России, где статистики не существует, а только нарисованные числа.
В примере, который я привел выше, кроме прививок никаких других факторов я не помню. Ограничения на этом временном отрезке ни добавляли ни снимали.
Например испытания вакцин, где указывается процент тяжёлых случаев и смертей для вакцинированных.
И, как по мне, это самый важный вопрос. Не ответив на него, нельзя строить никакие умозаключения
Делать выводы на основе частных случаев, это очень странная практика.
У вас есть объяснение тому, что через несколько месяцев после начала вакцинации в Германии (другие страны не смотрел), % смертей в несколько раз снизился? Да, болело столько же людей, но умирало гораздо меньше