достаточно пообщаться с несколькими людьми, живущими и занимающимися бизнесом в европе несколько лет.
квоты, кстати, не являются абсолютным злом. вполне рабочий инструмент, которым можно и нужно пользоваться. европа и прочие - пользуются, для своей выгоды, очевидно. понятно, что квота и свободная торговля как-то на уровне определений плохо сочетаются. но, имхо, лучше "золотая" середина в их разумном сочетании, чем крайности - полное планирование и абсолютная свобода торговли.
GraphQL хорош для взаимодействия фронта с беком. Человеческого фронта. В связи с чем на странице необходимы данные из 15-25 сущностей? Есть ощущение, что это избыточно.
Исходя из моего опыта, в абсолютном большинстве случаев достаточно до 5-6 сущностей на запрос. И вполне может быть несколько gql-запросов, каждый поставляет данные по своему жизненному циклу. Скажем профиль пользователя с его расширенными свойствами, типа подразделение, роли, должности, подтягиваются одним запросом. Табличные данные с пажинацией, другим запросом. Нотификации - третьим.
А проблема N+1 - у нее два аспекта. 1) если источник данных один для двух сущностей, которые нужно склеивать, то это значит разработчики поленились реализовать правильные фетчеры. graphql не причем, это просто транспорт. 2) источники данных разные для двух сущностей, которые нужно склеить. это нетривиальный случай. причем нетривиальный хоть для graphql, хоть для любой другой технологии. dataloader'ы из graphql позволяют закрыть определенные аспекты, но важно понимать, что задача склеивания данных из двух разных источников в общем случае само по себе нетривиальная.
Вот с чем нужно быть осторожным в graphql, это с мутациями. Использовать их очень точечно, там где логика тривиальна. Можно конечно RPC пытаться натягивать на мутации, но это чревато. Для RPC лучше использовать REST.
имхо, проблема в попытке соединить, то что должны быть раздельным.
вы правильно отметили, что есть несколько уровней абстракции, которые мало что про друг друга знают. и для управления эта малоинформированность слоев о друге друге мешает.
но с другой стороны, почему появились эти слои абстракции? как раз для того, чтобы каждый слой был максимально обособлен, и связь между ними была точно очерчена. тогда это дает возможность вносить изменения в каждый слой в отдельности, минимально влияя на соседние слои. т.е. наши абстракции умышленно создавались обособленными. в этом их главный плюс.
и да, этот плюс, с точки зрения управления является и минусом. ничего не достается бесплатно.
каков вывод: каждый новый слои абстракции может давать свои плюсы, расплачиваться за это приходится усложнением управления. хочется упростить управление? надо уменьшать количество абстракций.
Всегда с интересом читаю комментарии про некую свободу аджайла. Даже, наверно, некоторую анархию.
Так-то аджайл (говорим аджайл, подразумеваем скрам, верно?) довольно строгий ко всем участникам процесс. DoR, DoD, спринт скоуп, демо, дейли и прочее - не дают загулять. Это в ватерфоле можно сидеть, и тебе за это ничего не будет. "Почему сидим? От аналитиков спеки ждем. Или тестировщикам релиз на тесты отдали, ждем фидбек." А в аджайле - вся команда в связке, все либо молодцы, либо лузеры. Если кто-то простаивает, значит планирование подвело, на ретро надо думать что с этим делать.
И релизы катить раз в день, или раз в квартал. Это не про аджайл. А про процесс управления изменениями. Можно быть честным аджайл, и катиться раз в месяц. (коммерческие standalone продукты раз в день релизятся?) Можно ничего не знать про аджайл, и катиться в прод каждый час.
Всем рано или поздно приходится когда-нибудь снимать дампы с прода. Понятно, это происходит не каждый день. Но бывают кейсы, когда ошибка на тесте не воспроизводится. Даже при всем обилии инструментов трейсинга трафика и логирования.
Ничего не знаю про автора статьи и его навыки системного архитектора. Предпочитаю профессиональные навыки оценивать при личном общении.
А вот про утверждение что софт скиллы архитектору (не важно какому) не нужны. Я бы поспорил.
Архитектор находится на пересечении нескольких далеко не смежных областей. И соответственно ему приходится коммуницировать с самыми разными людьми. И не общаться с ними ему не получится. И внятно и корректно излагать свои мысли для людей из разных областей, часть его обыденной деятельности.
Тут наверно нужно выяснить, а что такое антипаттерн?
Это нечто, что нежелательно использовать, дабы не поиметь сложностей.
А что такое паттерн?
Как не странно, это не антипод для антипаттерна. Недостаточно просто "желательно использовать, чтобы наступило счастье". Там очень важное дополнение - у каждого паттерна есть набор плюсов и минусов. Соответственно, паттерн нужно использовать в случаях подходящих для это паттерна. Тогда когда плюсы проявляются во всей красе, а минусы наоборот есть, но не мешают жить.
Соответственно, в чем плюсы и минусы ServiceLocator?
Про минусы подробно рассказали выше. Плюс - простота связывания разных компонент между собой.
Когда плюсы проявляются сильнее минусов? Для относительно простых приложений. Когда полноценный DI избыточен, либо невозможен, а напрямую связывать несколько компонент между собой не хочется.
наличие разных образов для dev, test, prod не является чем-то предосудительным.
Не то чтобы, это ужас-ужас.
Но главный профит контейнеров как раз в том, что образ является способом обеспечения одинаковости доставленных артефактов в разных окружениях. Если образы в окружениях отличаются, то теряете главное преимущество контейнеров.
Такое бывает если есть легаси система, у которой только асинхронный интерфейс, а потребителю нужен синхронный, тогда и появляется такой адаптер - sync 2 async
Здесь я перечислил то, как я вижу правильное назначение для MongoDB:
Вообще, первый пункт, когда нужно выбирать монгу: данные непрерывно растут в объеме и необходимо дешевое горизонтальное масштабирование.
Конечно, это не мешает использовать монгу на одном инстансе. Но нужно помнить, что для реализации дешевого горизонтального масштабирования создателям монги пришлось пойти на ряд компромиссов. И когда вы не используете главную фичу монги, вы не получаете самую важную ценность монги, но при этом получаете в нагрузку все недостатки монги, которые и в одном инстансе никуда не делись.
а предлагаются конкурирующие и дорожащие своей репутацией сотни оракулов.
Вот допустим, вы занимаетесь разработкой сайтов.
Допустим, вы заключили договор с заказчиком на разработку сайта.
Допустим у вас возникли прения насчет результатов по разработке сайта, и оплаты.
С разрешением спора между вами и заказчиком, как вам поможет блокчейн и сотня доверенных оракулов? И чем способ разрешения спора принципиально лучше уже существующих способов?
Академический ответ: и git, и блокчейн - это дерево Меркла. Но в блокчейне еще есть алгоритм кворума. Поэтому, грубо, блокчейн это git + распределенный кворум.
ЗЫ, странно, что здесь никто не упомянул про дерево Меркла.
я же не юрист по европейскому законодательству.
достаточно пообщаться с несколькими людьми, живущими и занимающимися бизнесом в европе несколько лет.
квоты, кстати, не являются абсолютным злом. вполне рабочий инструмент, которым можно и нужно пользоваться. европа и прочие - пользуются, для своей выгоды, очевидно. понятно, что квота и свободная торговля как-то на уровне определений плохо сочетаются. но, имхо, лучше "золотая" середина в их разумном сочетании, чем крайности - полное планирование и абсолютная свобода торговли.
Зона свободной торговли в рамках квот
кеширование на стороне источника данных. там где канонически и должно быть. понятно, что у этого есть свои плюсы/минусы.
GraphQL хорош для взаимодействия фронта с беком. Человеческого фронта. В связи с чем на странице необходимы данные из 15-25 сущностей? Есть ощущение, что это избыточно.
Исходя из моего опыта, в абсолютном большинстве случаев достаточно до 5-6 сущностей на запрос. И вполне может быть несколько gql-запросов, каждый поставляет данные по своему жизненному циклу. Скажем профиль пользователя с его расширенными свойствами, типа подразделение, роли, должности, подтягиваются одним запросом. Табличные данные с пажинацией, другим запросом. Нотификации - третьим.
А проблема N+1 - у нее два аспекта. 1) если источник данных один для двух сущностей, которые нужно склеивать, то это значит разработчики поленились реализовать правильные фетчеры. graphql не причем, это просто транспорт. 2) источники данных разные для двух сущностей, которые нужно склеить. это нетривиальный случай. причем нетривиальный хоть для graphql, хоть для любой другой технологии. dataloader'ы из graphql позволяют закрыть определенные аспекты, но важно понимать, что задача склеивания данных из двух разных источников в общем случае само по себе нетривиальная.
Вот с чем нужно быть осторожным в graphql, это с мутациями. Использовать их очень точечно, там где логика тривиальна. Можно конечно RPC пытаться натягивать на мутации, но это чревато. Для RPC лучше использовать REST.
имхо, проблема в попытке соединить, то что должны быть раздельным.
вы правильно отметили, что есть несколько уровней абстракции, которые мало что про друг друга знают. и для управления эта малоинформированность слоев о друге друге мешает.
но с другой стороны, почему появились эти слои абстракции? как раз для того, чтобы каждый слой был максимально обособлен, и связь между ними была точно очерчена. тогда это дает возможность вносить изменения в каждый слой в отдельности, минимально влияя на соседние слои. т.е. наши абстракции умышленно создавались обособленными. в этом их главный плюс.
и да, этот плюс, с точки зрения управления является и минусом. ничего не достается бесплатно.
каков вывод: каждый новый слои абстракции может давать свои плюсы, расплачиваться за это приходится усложнением управления. хочется упростить управление? надо уменьшать количество абстракций.
ваш пессимизм понятен.
но и ожидать, что текущая ситуация будет всегда будет такой - очевидно будет меняться.
мир изменчив, приоритеты меняются. в лучшую или худшую - никто не знают. но точно изменится.
а как вы видите себе решение, которое абстрагирует в себя несколько слоев других абстракций?
Всегда с интересом читаю комментарии про некую свободу аджайла. Даже, наверно, некоторую анархию.
Так-то аджайл (говорим аджайл, подразумеваем скрам, верно?) довольно строгий ко всем участникам процесс. DoR, DoD, спринт скоуп, демо, дейли и прочее - не дают загулять. Это в ватерфоле можно сидеть, и тебе за это ничего не будет. "Почему сидим? От аналитиков спеки ждем. Или тестировщикам релиз на тесты отдали, ждем фидбек." А в аджайле - вся команда в связке, все либо молодцы, либо лузеры. Если кто-то простаивает, значит планирование подвело, на ретро надо думать что с этим делать.
И релизы катить раз в день, или раз в квартал. Это не про аджайл. А про процесс управления изменениями. Можно быть честным аджайл, и катиться раз в месяц. (коммерческие standalone продукты раз в день релизятся?) Можно ничего не знать про аджайл, и катиться в прод каждый час.
Не переживайте. У вас все еще впереди. ;)
Всем рано или поздно приходится когда-нибудь снимать дампы с прода. Понятно, это происходит не каждый день. Но бывают кейсы, когда ошибка на тесте не воспроизводится. Даже при всем обилии инструментов трейсинга трафика и логирования.
Ничего не знаю про автора статьи и его навыки системного архитектора. Предпочитаю профессиональные навыки оценивать при личном общении.
А вот про утверждение что софт скиллы архитектору (не важно какому) не нужны. Я бы поспорил.
Архитектор находится на пересечении нескольких далеко не смежных областей. И соответственно ему приходится коммуницировать с самыми разными людьми. И не общаться с ними ему не получится. И внятно и корректно излагать свои мысли для людей из разных областей, часть его обыденной деятельности.
Тут наверно нужно выяснить, а что такое антипаттерн?
Это нечто, что нежелательно использовать, дабы не поиметь сложностей.
А что такое паттерн?
Как не странно, это не антипод для антипаттерна. Недостаточно просто "желательно использовать, чтобы наступило счастье". Там очень важное дополнение - у каждого паттерна есть набор плюсов и минусов. Соответственно, паттерн нужно использовать в случаях подходящих для это паттерна. Тогда когда плюсы проявляются во всей красе, а минусы наоборот есть, но не мешают жить.
Соответственно, в чем плюсы и минусы ServiceLocator?
Про минусы подробно рассказали выше. Плюс - простота связывания разных компонент между собой.
Когда плюсы проявляются сильнее минусов? Для относительно простых приложений. Когда полноценный DI избыточен, либо невозможен, а напрямую связывать несколько компонент между собой не хочется.
Не то чтобы, это ужас-ужас.
Но главный профит контейнеров как раз в том, что образ является способом обеспечения одинаковости доставленных артефактов в разных окружениях. Если образы в окружениях отличаются, то теряете главное преимущество контейнеров.
Такое бывает если есть легаси система, у которой только асинхронный интерфейс, а потребителю нужен синхронный, тогда и появляется такой адаптер - sync 2 async
Вообще, первый пункт, когда нужно выбирать монгу: данные непрерывно растут в объеме и необходимо дешевое горизонтальное масштабирование.
Конечно, это не мешает использовать монгу на одном инстансе. Но нужно помнить, что для реализации дешевого горизонтального масштабирования создателям монги пришлось пойти на ряд компромиссов. И когда вы не используете главную фичу монги, вы не получаете самую важную ценность монги, но при этом получаете в нагрузку все недостатки монги, которые и в одном инстансе никуда не делись.
Аналогичная история с кафкой.
а покупка us treasury securities считается как fdi?
Занимательно будет взглянуть на этот график через год.
Вы видите прямую корреляцию между количеством тестировщиков и качеством конечного продукта?
Вот допустим, вы занимаетесь разработкой сайтов.
Допустим, вы заключили договор с заказчиком на разработку сайта.
Допустим у вас возникли прения насчет результатов по разработке сайта, и оплаты.
С разрешением спора между вами и заказчиком, как вам поможет блокчейн и сотня доверенных оракулов? И чем способ разрешения спора принципиально лучше уже существующих способов?
Уже ответили что, нет.
Академический ответ: и git, и блокчейн - это дерево Меркла. Но в блокчейне еще есть алгоритм кворума. Поэтому, грубо, блокчейн это git + распределенный кворум.
ЗЫ, странно, что здесь никто не упомянул про дерево Меркла.
Так вот и вопрос. Какую из текущих проблем блокчейн решает лучше, чем существующие решения? для простых людей.
Переводы? нет
Платежи? нет
Реестр сделок? нет
А что тогда да?