#манагерское
Собирайте грибы, а не требования
Если лень читать:
1. Требований не существует
2. Задача аналитика - не собрать требования
В холиварах на тему “нужен ли аналитик?” часто слышу аргумент: “Задача по сбору требований остается, просто без аналитика ее вешают на другую роль”.
В этом высказывании есть ряд неявных допущений:
1. Существуют некоторые объективные “требования”
2. Существуют люди, которым “требования” известны - стейкхолдеры
3. С помощью особых техник можно собрать все “требования” у стейкхолдеров
4. Если реализовать “требования”, то мы получим результат, который нужен бизнесу
Все хорошо, но есть нюанс: эти допущения выполняются разве что в заказной разработке:
1. Требования - хотелки заказчика
2. Стейкхолдеры - сотрудники заказчика
3. Аналитики записывают хотелки заказчика, мы прикладываем их к договору
4. Реализуем хотелки, получаем деньги - профит
И то при особо злостном следовании “требованиям” заказчик может отказаться принимать работу или отправить нас в блеклист после сдачи проекта.
Когда мы пилим продукт, в роли “требований” могут выступать разве что ограничения регулятора и законы физики. Никаких “правильных требований”, которые можно "собрать", здесь нет. Как и нет людей, которые точно знают, что делать - мы оперируем гипотезами, исследованиями, данными разной степени достоверности.
Аналитик может быть полезен в такой среде: выявить корнеры, почеленджить логику, найти противоречия. При этом критично, чтобы в процесс проектирования решения были вовлечены и аналитик, и бизнес-эксперты с продактом, и техническая команда. С таким подходом в анализ и проектирование вовлечена вся команда. Однажды мы можем обнаружить, что она вполне справляется без аналитика.
А если без аналитика никак, то почему? Хотим работать по принципу: “Что нам сказали, то и делаем”?
Собирайте грибы, а не требования
Если лень читать:
2. Задача аналитика - не собрать требования
В холиварах на тему “нужен ли аналитик?” часто слышу аргумент: “Задача по сбору требований остается, просто без аналитика ее вешают на другую роль”.
В этом высказывании есть ряд неявных допущений:
1. Существуют некоторые объективные “требования”
2. Существуют люди, которым “требования” известны - стейкхолдеры
3. С помощью особых техник можно собрать все “требования” у стейкхолдеров
4. Если реализовать “требования”, то мы получим результат, который нужен бизнесу
Все хорошо, но есть нюанс: эти допущения выполняются разве что в заказной разработке:
1. Требования - хотелки заказчика
2. Стейкхолдеры - сотрудники заказчика
3. Аналитики записывают хотелки заказчика, мы прикладываем их к договору
4. Реализуем хотелки, получаем деньги - профит
И то при особо злостном следовании “требованиям” заказчик может отказаться принимать работу или отправить нас в блеклист после сдачи проекта.
Когда мы пилим продукт, в роли “требований” могут выступать разве что ограничения регулятора и законы физики. Никаких “правильных требований”, которые можно "собрать", здесь нет. Как и нет людей, которые точно знают, что делать - мы оперируем гипотезами, исследованиями, данными разной степени достоверности.
Аналитик может быть полезен в такой среде: выявить корнеры, почеленджить логику, найти противоречия. При этом критично, чтобы в процесс проектирования решения были вовлечены и аналитик, и бизнес-эксперты с продактом, и техническая команда. С таким подходом в анализ и проектирование вовлечена вся команда. Однажды мы можем обнаружить, что она вполне справляется без аналитика.
А если без аналитика никак, то почему? Хотим работать по принципу: “Что нам сказали, то и делаем”?
👍21❤8👎8🤔6🔥3
#интеграция
Вот такая шикарная инфографика от Юрия Куприянова. Не со всем согласен, мои комменты тут.
Полезая штука, но как всегда буду душнить: пожалуйста, никогда (прописью: никогда) не принимайте боевые решения на основе таких таблиц / критериев / алогритмов - они никогда не будут отражать всех нюансов. А какие нюансы важны в вашем контексте, знаете только вы.
Тогда в чем польза? Систематизировать знания, сверить картину мира, если что-то кажется странным - погуглить и узнать что-то новое.
Вот такая шикарная инфографика от Юрия Куприянова. Не со всем согласен, мои комменты тут.
Полезая штука, но как всегда буду душнить: пожалуйста, никогда (прописью: никогда) не принимайте боевые решения на основе таких таблиц / критериев / алогритмов - они никогда не будут отражать всех нюансов. А какие нюансы важны в вашем контексте, знаете только вы.
Тогда в чем польза? Систематизировать знания, сверить картину мира, если что-то кажется странным - погуглить и узнать что-то новое.
Telegram
Системный сдвиг
В канун Нового года держите подарочек от меня: всё, что вы хотели знать про разные способы интеграций, в одной (большой) картинке.
Тут в основном только перечисления названий протоколов и технологий, но зато даёт общую картину. Это ещё круче, чем в предыдущем…
Тут в основном только перечисления названий протоколов и технологий, но зато даёт общую картину. Это ещё круче, чем в предыдущем…
🔥22😱7👍5❤2
#книжное #оффтоп
Биология добра и зла Роберта Сапольски стала для меня открытием 2024 года. Безумно интересно и доступно о том, как устроен человек, что определяет его поведение.
Тема раскрывается постепенно, от низкоуровневых механизмов вроде цепей нейронов до сложных социальных факторов. Специфичных знаний не нужно, все необходимые концепции подаются по ходу, для особо важных тем есть специальные дополнения. Пишет весело и задорно.
Например, внутри можно найти:
* Как же круто и математично устроены сети нейронов
* Почему тестостерон - это не про агрессию, а окситоцин - не про любовь
* На сколько часто наше поведение определяется гормонами и строением мозга, а не нашем выбором
Важно, что автор - это профессор нейробиологии, а не журналист от научпопа. Инфа и утверждения сопровождаются ссылками на оригинальные исследования, пару раз даже доходил до них.
И практически полезного: чаще задумываешься, чем обусловлено свое или чужое поведение.
Из побочных эффектов: сложнее воспринимать всерьез часть идей психоанализа и медитаций.
За каникулы прочитать вряд ли получится, но оно того стоит. Если совсем лень, то у Сапольски много лекций и интервью в сети - там тоже много интересного.
А еще очень качественно и приятно печатное издание сделали, с двумя закладочками.
Биология добра и зла Роберта Сапольски стала для меня открытием 2024 года. Безумно интересно и доступно о том, как устроен человек, что определяет его поведение.
Тема раскрывается постепенно, от низкоуровневых механизмов вроде цепей нейронов до сложных социальных факторов. Специфичных знаний не нужно, все необходимые концепции подаются по ходу, для особо важных тем есть специальные дополнения. Пишет весело и задорно.
Например, внутри можно найти:
* Как же круто и математично устроены сети нейронов
* Почему тестостерон - это не про агрессию, а окситоцин - не про любовь
* На сколько часто наше поведение определяется гормонами и строением мозга, а не нашем выбором
Важно, что автор - это профессор нейробиологии, а не журналист от научпопа. Инфа и утверждения сопровождаются ссылками на оригинальные исследования, пару раз даже доходил до них.
И практически полезного: чаще задумываешься, чем обусловлено свое или чужое поведение.
Из побочных эффектов: сложнее воспринимать всерьез часть идей психоанализа и медитаций.
За каникулы прочитать вряд ли получится, но оно того стоит. Если совсем лень, то у Сапольски много лекций и интервью в сети - там тоже много интересного.
А еще очень качественно и приятно печатное издание сделали, с двумя закладочками.
👍38💯3
#книжное #оффтоп
А в 2023 открытием года стала Гарри Поттер и методы рационального мышления от Элиезера Юдковского. Точнее приоткрытием, т.к. некоторые главы читал раньше, но сначала не зацепило.
Автор предлагает альтернативную историю Гарри Поттера, в которой онне был дебилом с самого детства овладел логикой и рациональным мышлением. Фактически, это сборник логических ошибок, когнитивных искажений, парадоксов, и прочих несовершенств работы нашего мозга. И завернуто это все в реально интересный сюжет. Мне было куда интереснее, чем смотреть оригинальный фильм.
Вот по этой версии нужно снимать фильмы, проходить и разбирать в школе с детьми. Правда, многим учителям, родителям и социальным институтам это будет не слишком выгодно. Но это уже другая история.
Книга свободно доступна в онлайне, но есть и печатные издания, если больше нравится.
А в 2023 открытием года стала Гарри Поттер и методы рационального мышления от Элиезера Юдковского. Точнее приоткрытием, т.к. некоторые главы читал раньше, но сначала не зацепило.
Автор предлагает альтернативную историю Гарри Поттера, в которой он
Вот по этой версии нужно снимать фильмы, проходить и разбирать в школе с детьми. Правда, многим учителям, родителям и социальным институтам это будет не слишком выгодно. Но это уже другая история.
Книга свободно доступна в онлайне, но есть и печатные издания, если больше нравится.
❤16🔥8👍5🤮2😱1
Forwarded from NextWay - анализ и проектирование в IT
Ну что, пора вылезать из салатов?
В прошлом году мы запустили Клуб Проектирования NextWay, чтобы вместе качать архитектурные скиллы 🎓💪
Никита Ерилин, эксперт клуба, поделился полезным-архитектурным, чтобы почитать под мандаринки.
System Design Primer
Хорошая краткая выжимка по многим моментам и понятиям, используемым в системном дизайне. Сфокусировано на собеседованиях, но в качестве знакомства с основами или справочника подходит неплохо. Единственное - не заучивайте примеры, а постарайтесь докопаться до мотивации того, почему они предлагают сделать именно так.
Design It! From Programmer to Software Architect
Все еще лучшая книга для погружения в архитектурные практики от Майкла Килинга. Она больше заточена под разработчиков, поэтому там довольно много разжевываний вещей, которые могут показаться банальными, вроде: "Не придумывай требование, спроси ртом у заказчика" - но там есть много разных методик по работе со стейкхолдерами. В рамках собеса такое вред ли пригодится, но в работе поможет.
Книга с кабанчиком
Бессмертная классика от Мартина Клепмана. Может показаться сложной из-за обилия технических подробностей, но ее структура позволяет провернуть один лайфхак: как только вы чувствуете, что глава становится слишком сложной, и вы не понимаете технических деталей – переходите к следующей, они все идут по принципу "от простого к сложному”. Даже если вы по верхам пробежите все главы, получите много пищи для дальнейших размышлений.
Microservices.io
Большая подборка микросервисных паттернов Криса Ричардсона. Самый полезный раздел, на мой взгляд: "Transactional messaging".
@nextway_news
В прошлом году мы запустили Клуб Проектирования NextWay, чтобы вместе качать архитектурные скиллы 🎓💪
Никита Ерилин, эксперт клуба, поделился полезным-архитектурным, чтобы почитать под мандаринки.
System Design Primer
Хорошая краткая выжимка по многим моментам и понятиям, используемым в системном дизайне. Сфокусировано на собеседованиях, но в качестве знакомства с основами или справочника подходит неплохо. Единственное - не заучивайте примеры, а постарайтесь докопаться до мотивации того, почему они предлагают сделать именно так.
Design It! From Programmer to Software Architect
Все еще лучшая книга для погружения в архитектурные практики от Майкла Килинга. Она больше заточена под разработчиков, поэтому там довольно много разжевываний вещей, которые могут показаться банальными, вроде: "Не придумывай требование, спроси ртом у заказчика" - но там есть много разных методик по работе со стейкхолдерами. В рамках собеса такое вред ли пригодится, но в работе поможет.
Книга с кабанчиком
Бессмертная классика от Мартина Клепмана. Может показаться сложной из-за обилия технических подробностей, но ее структура позволяет провернуть один лайфхак: как только вы чувствуете, что глава становится слишком сложной, и вы не понимаете технических деталей – переходите к следующей, они все идут по принципу "от простого к сложному”. Даже если вы по верхам пробежите все главы, получите много пищи для дальнейших размышлений.
Microservices.io
Большая подборка микросервисных паттернов Криса Ричардсона. Самый полезный раздел, на мой взгляд: "Transactional messaging".
@nextway_news
👍12❤5🥴3👎1
#оффтоп #манагерское
Внезапно осознал, что в около-образовании уже 6 лет. Началось все с обучения для аналитиков внутри компании, потом вел и делал курс по интеграциям в com-practice, теперь занимаюсь своей школой. А появилась она довольно забавно.
В тот момент я около полугода работал в компании, где у нас совсем не задались рабочие отношения с руководителем. Когда атмосфера стала откровенно взрывоопасной, понял что лучше уже не будет - решил уйти в закат и отдохнуть 2-3 месяца. С руководителем договорились быстро, ибо желание было обоюдным.
Но не все так просто: я был лидом команды, большую часть которой сам и собрал. Нагнетать и сеять смуту особо не хотелось, поэтому на прощальных 1-1 коллегам озвучил версию, что ухожу в свободное плавание делать свою школу.Дада, тут можно кидать в меня камнями. Дальше все пошло не по плану, я получил от команды такое количество поддержки… что в голове раздался голос:
- Не нуачо? Раз народ сказал, надо идти делать
Так появился ArchWays. Потом решили объединиться с Аней, и он трансформировался в NextWay. Мораль я не придумал, но если вы узнали себя в это истории - спасибо за веру и чудесную возможность))
Внезапно осознал, что в около-образовании уже 6 лет. Началось все с обучения для аналитиков внутри компании, потом вел и делал курс по интеграциям в com-practice, теперь занимаюсь своей школой. А появилась она довольно забавно.
В тот момент я около полугода работал в компании, где у нас совсем не задались рабочие отношения с руководителем. Когда атмосфера стала откровенно взрывоопасной, понял что лучше уже не будет - решил уйти в закат и отдохнуть 2-3 месяца. С руководителем договорились быстро, ибо желание было обоюдным.
Но не все так просто: я был лидом команды, большую часть которой сам и собрал. Нагнетать и сеять смуту особо не хотелось, поэтому на прощальных 1-1 коллегам озвучил версию, что ухожу в свободное плавание делать свою школу.
- Не нуачо? Раз народ сказал, надо идти делать
Так появился ArchWays. Потом решили объединиться с Аней, и он трансформировался в NextWay. Мораль я не придумал, но если вы узнали себя в это истории - спасибо за веру и чудесную возможность))
🔥28👍11❤8🥴2
Please open Telegram to view this post
VIEW IN TELEGRAM
☃14❤11🔥3👻3🤝3👍1👌1
#интеграция #архитектура
Все, хватит салатов, просыпаемся.
Детальный разбор реализации Transactional Outbox, когда у тебя постгря с кафкой. Варианты реализации, проблемы, инструменты - просто и понятно. Отдельно можно скачать презу.
Здесь можно подробнее почитать, зачем нужны все эти аутбоксы, и что это такое.
Все, хватит салатов, просыпаемся.
Детальный разбор реализации Transactional Outbox, когда у тебя постгря с кафкой. Варианты реализации, проблемы, инструменты - просто и понятно. Отдельно можно скачать презу.
Здесь можно подробнее почитать, зачем нужны все эти аутбоксы, и что это такое.
✍11👍4🔥1
#интеграция
Ничего мы вам не гарантировали
Меня умиляют истории, как кто-то в очередной раз сделал надежную exactly once доставку с помощью XXX и YYY. Обычно это либо оголтелый маркетинг, либо техническая наивность.
Существует ровно двагендера гарантии доставки:
• at most once
• at least once
Все, третьего не дано.
Вы не реализуете exactly once доставку, потому что это фундаментальное ограничение мира, такое же как вечный двигатель или перемещение материи свыше скорости света. За доказательством рекомендую обратиться к задаче двух генералов - она во многих задачах IT проявляется, пусть и неявно.
Тогда что такое exactly once?
Это гарантия обработки. Если говорить просто, то это at least once доставка, где каждое взаимодействие обвешано ретраями и идемпотентностью. Единственный способ обработать сообщение строго один раз - это любой ценой донести его до получателя, а потом уже отсеять дубликаты.
Потому нам нужны transactional in/out-boxы - чтобы корректно донести сообщение до брокера, и строго один раз обработать его на консьюмере. И все это поверх at least once гарантии доставки.
Про аутбоксы можно почитать тут.
А здесь хардкорно про устройство брокеров, и как устроена запись-чтение сообщений.
Ничего мы вам не гарантировали
Меня умиляют истории, как кто-то в очередной раз сделал надежную exactly once доставку с помощью XXX и YYY. Обычно это либо оголтелый маркетинг, либо техническая наивность.
Существует ровно два
• at most once
• at least once
Все, третьего не дано.
Вы не реализуете exactly once доставку, потому что это фундаментальное ограничение мира, такое же как вечный двигатель или перемещение материи свыше скорости света. За доказательством рекомендую обратиться к задаче двух генералов - она во многих задачах IT проявляется, пусть и неявно.
Тогда что такое exactly once?
Это гарантия обработки. Если говорить просто, то это at least once доставка, где каждое взаимодействие обвешано ретраями и идемпотентностью. Единственный способ обработать сообщение строго один раз - это любой ценой донести его до получателя, а потом уже отсеять дубликаты.
Потому нам нужны transactional in/out-boxы - чтобы корректно донести сообщение до брокера, и строго один раз обработать его на консьюмере. И все это поверх at least once гарантии доставки.
Про аутбоксы можно почитать тут.
А здесь хардкорно про устройство брокеров, и как устроена запись-чтение сообщений.
👍23❤11🤔1
Don’t try to quit REST
Завтра вещаю на вебинаре, чтобы в очередной (третий) раз окончательно закрыть тему REST API. Наверное, это персональное проклятье. Вспомним, как появилась концепция, под какие задачи, и почему ее актуальность в 2025 стремится к нулю.
Приходите похоливарить, рега тут
Завтра вещаю на вебинаре, чтобы в очередной (третий) раз окончательно закрыть тему REST API. Наверное, это персональное проклятье. Вспомним, как появилась концепция, под какие задачи, и почему ее актуальность в 2025 стремится к нулю.
Приходите похоливарить, рега тут
nextway.timepad.ru
REST, что с тобой не так? / События на TimePad.ru
Проблемы и применимость концепции в современных системах.
👍11🤔4💩2
#интеграция #брокеры
Пока ты разбираешься с топиками и партициями в Кафке, они уже пилят кафка-очереди. Идея прикольная, кстати:
Пока ты разбираешься с топиками и партициями в Кафке, они уже пилят кафка-очереди. Идея прикольная, кстати:
The way that consumer groups assign partitions to members of the group gives a powerful combination of ordering and scalability, but it does introduce coupling between the number of consumers in a consumer group and the number of partitions. Users of Kafka often have to “over-partition” simply to ensure they can have sufficient parallel consumption to cope with peak loads.
...
This KIP introduces the concept of a share group as a way of enabling cooperative consumption using Kafka topics. It does not add the concept of a “queue” to Kafka per se, but rather that introduces cooperative consumption to accommodate these queuing use-cases using regular Kafka topics. Share groups make this possible. You can think of a share group as roughly equivalent to a “durable shared subnoscription” in existing systems.
This is indeed Queues for Kafka - queues done in a Kafka way, with no maximum queue depth and the ability to reset to a specific time for point-in-time recovery.
🔥10
#архитектура
В прошлом году мы запустили кейс-клуб, где регулярно собираемся и предаемся System Design’у здорового человека.
Что делаем:
• Разбираем реальные задачи из жизни, а не Key-Value Storage, URL Shortener и прочую дичь, которую вы никогда не будете пилить в реальной жизни
• Учимся использовать архитектурные паттерны и технологии там, где они действительно уместны
• Увеличиваем техническую насмотренность за счет кейсов из разных индустрий: финтех, ecomm, телеком и другие
Примеры кейсов:
- выпуск и доставка банковской карты
- история покупок и быстрый заказ на маркетплейсе
- программа лояльности в экосистеме
Ближайшая встреча в воскресенье, будет кейс три в одном: A/B-тесты, feature toggling, таргетированная реклама - все в одной архитектуре.
Ждем всех, кто хочет начать осознанно проектировать, а не судорожно вспоминать главы Хью на каждом проекте и собесе, заходите.
В прошлом году мы запустили кейс-клуб, где регулярно собираемся и предаемся System Design’у здорового человека.
Что делаем:
• Разбираем реальные задачи из жизни, а не Key-Value Storage, URL Shortener и прочую дичь, которую вы никогда не будете пилить в реальной жизни
• Учимся использовать архитектурные паттерны и технологии там, где они действительно уместны
• Увеличиваем техническую насмотренность за счет кейсов из разных индустрий: финтех, ecomm, телеком и другие
Примеры кейсов:
- выпуск и доставка банковской карты
- история покупок и быстрый заказ на маркетплейсе
- программа лояльности в экосистеме
Ближайшая встреча в воскресенье, будет кейс три в одном: A/B-тесты, feature toggling, таргетированная реклама - все в одной архитектуре.
Ждем всех, кто хочет начать осознанно проектировать, а не судорожно вспоминать главы Хью на каждом проекте и собесе, заходите.
nextway.pro
Клуб проектирования NextWay
Регулярные воркшопы для развития навыков проектирования архитектуры.
👍9❤6👌1
Прекрасное рядом. До истории с /getClientInfo не дотягивает, но тоже хорошо.
Интересно, а с кэшированием у них нет проблем?
Интересно, а с кэшированием у них нет проблем?
😁13🥴4
Модели потребления сообщений
- Чем топики отличаются от очередей?
- Если кратко - это разные модели потребления
Что такое модели потребления?
Здесь сложнее, т.к. это понятие не слишком популярно в индустрии. В данном контексте модель потребления - это логика работы брокера при передаче сообщения потребителю.
Мой вариант классификации, который подробно разбираю на вебинаре:
• Queue
• Pub-Sub
• Log
Модели определяет два признака:
• Сколько потребителей может прочитать одно сообщение
• Что происходит с сообщением после прочтения
Часто выделяют две модели вместо трех: queue-based, log-based - т.е. объединяют модели Queue и Pub-Sub. Мне эта версия кажется менее наглядной, но тоже хорошо подходит для осмысления вопроса. Можно познакомиться в статье или послушать подкаст о брокерах.
А топиками могут называть что угодно: как модель очереди в реббите, так и реализацию лога в кафке.
#брокеры #интеграция
- Чем топики отличаются от очередей?
- Если кратко - это разные модели потребления
Что такое модели потребления?
Здесь сложнее, т.к. это понятие не слишком популярно в индустрии. В данном контексте модель потребления - это логика работы брокера при передаче сообщения потребителю.
Мой вариант классификации, который подробно разбираю на вебинаре:
• Queue
• Pub-Sub
• Log
Модели определяет два признака:
• Сколько потребителей может прочитать одно сообщение
• Что происходит с сообщением после прочтения
Часто выделяют две модели вместо трех: queue-based, log-based - т.е. объединяют модели Queue и Pub-Sub. Мне эта версия кажется менее наглядной, но тоже хорошо подходит для осмысления вопроса. Можно познакомиться в статье или послушать подкаст о брокерах.
А топиками могут называть что угодно: как модель очереди в реббите, так и реализацию лога в кафке.
#брокеры #интеграция
YouTube
Брокеры сообщений. Модели потребления
Введение в работу брокеров сообщений для начинающих. Рассматриваем концепцию моделей передачи/потребления сообщений:
- Queue (очередь)
- Pub-Sub (подписка)
- Log (лог или журнал)
Курс по интеграции систем и архитектуре: https://clck.ru/3FqCbT
Курс по использованию…
- Queue (очередь)
- Pub-Sub (подписка)
- Log (лог или журнал)
Курс по интеграции систем и архитектуре: https://clck.ru/3FqCbT
Курс по использованию…
❤20👍3
В душе я немного китаец, поэтому оставлю авторитетный прогноз на год грядущий.
Ближайшие 2-3 года особым успехом будут пользоваться астрологи, тарологи, биоэнергетики - в серьезные кризисы люди обращаются к эзотерике.
Немного перепадет карьерным консультантам, коучам, психотерапевтам - за счет итшечки и около.
Не упусти свой шанс
Ближайшие 2-3 года особым успехом будут пользоваться астрологи, тарологи, биоэнергетики - в серьезные кризисы люди обращаются к эзотерике.
Немного перепадет карьерным консультантам, коучам, психотерапевтам - за счет итшечки и около.
Не упусти свой шанс
😁35❤5🔥5😱1
#ненависть #оффтоп
Глядя на околообразование, все больше прихожу к мысли, что лицензировать нужно не школы и программы, а преподавателей и авторов. Чтобы как с адвокатом или хирургом - нет лицензии, не подходи к людям. И какую-нибудь Клятву Аристотеля придумать.
Глядя на околообразование, все больше прихожу к мысли, что лицензировать нужно не школы и программы, а преподавателей и авторов. Чтобы как с адвокатом или хирургом - нет лицензии, не подходи к людям. И какую-нибудь Клятву Аристотеля придумать.
👍35😁22💯7🔥1🤔1
Кто ждал запись - вот она
Telegram
NextWay - анализ и проектирование в IT
Выложили запись вебинара REST, что с тобой не так?
📝 Основные тезисы:
— Концепция REST API создавалась под задачи простого Web'а конца 90х - начала 00х
— Взаимодействия в сервисной и микросервисной архитектуре, сложные пользовательские сценарии, работа…
📝 Основные тезисы:
— Концепция REST API создавалась под задачи простого Web'а конца 90х - начала 00х
— Взаимодействия в сервисной и микросервисной архитектуре, сложные пользовательские сценарии, работа…
🎉18
#API
В разговоре отличное сравнение возникло: уровни зрелости REST API это как нормальные формы БД - описывают подходы к проектированию, но никак не отвечают на вопрос эффективности. Зрелый и нормальный - не значит эффективный для текущей задачи.
Никому в голову не приходит начинать проектирование БД с шестой формы, но при этом люди всерьез бьются за правильный рест. Надо бы к понятию денормализации базы добавить дезрелость реста.
Хотя само слово “зрелость” выбрано максимально неудачно - Ричардсон, иди думай еще.
В разговоре отличное сравнение возникло: уровни зрелости REST API это как нормальные формы БД - описывают подходы к проектированию, но никак не отвечают на вопрос эффективности. Зрелый и нормальный - не значит эффективный для текущей задачи.
Никому в голову не приходит начинать проектирование БД с шестой формы, но при этом люди всерьез бьются за правильный рест. Надо бы к понятию денормализации базы добавить дезрелость реста.
Хотя само слово “зрелость” выбрано максимально неудачно - Ричардсон, иди думай еще.
👍18🔥14😁6💯1
#API #интеграция
GraphQL. Не язык ты мне
Что меня раздражает в итшечке - бесконечная любовь к словотворчеству. Разработал новую технологию или концепцию? Изобретай термин, который укажет, что это нечто совершенно новое и не подлежит сравнению с существующими.
Причины понятные:
◽️ Если автор человек - тщеславие и личный бренд
◽️ Опенсорсное решение - продвижение в массы в целях компании
◽️ Проприетарное решение - нужно больше золота
Обыкновенные маркетинг, если кратко.
Та же история “языком запросов к API”. Что говорят авторы:
“GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data”.
С их слов GraphQL это:
◽️ язык запросов к API, что бы это не значило
◽️ некий рантайм, в котором эти запросы обрабатываются
Начнем с языка, что видим:
1️⃣ Все запросы имеют определенную структуру, близкую к JSON
2️⃣ Ответы представлены в виде JSON, который имеет структуру из запроса с заполненными значениями
3️⃣ Не привязан к конкретному транспорту
4️⃣ Доступные действия и данные описывают с помощью своего Schema Definition Language - SDL
Ничего не напоминает?
Если брать п.1-3, то практически полной аналогией можно назвать JSON-RPC.
Если брать п.1-4, то все это SOAP.
Фактически, преред нами сетевой протокол уровня 7+ по модели OSI.
Ок, что там с рантаймом?
Для обработки запросов нужен некоторый компонент, который будет их парсить, валидировать, собирать/обновлять инфу из источников, публиковать SDL. Больше всех на слуху Apollo Server, но есть куча других опенсорсных и проприетарных решений.
Что, опять дежавю? Все так, тезисы полностью распространяются на тот же SOAP. Или gRCP, если сделать скидку на его бинарность.
В итоге получаем, что GraphQL это:
1️⃣ Протокол передачи данных
2️⃣ Технология с различными реализациями
3️⃣ Отчасти архитектурный подход к взаимодействию с фронтами
Вот и все, никакой мистики.
Здесь можно задать резонный вопрос: “Что ты придираешься, нормально звучит же: язык запросов”
◽️ Во-первых, реально встречаю недопонимание у людей в этом вопросе.
◽️ Во-вторых, если термин не несет новых смыслов, то зачем вообще его вводить?
А так, честный HATEOAS тоже можно языком запросов назвать, это даже корректнее будет.
Кто хочет копнуть глубже, посмотрите наш стрим с Денисом Лукьяновым, там еще куча материалов в описании.
GraphQL. Не язык ты мне
Что меня раздражает в итшечке - бесконечная любовь к словотворчеству. Разработал новую технологию или концепцию? Изобретай термин, который укажет, что это нечто совершенно новое и не подлежит сравнению с существующими.
Причины понятные:
Обыкновенные маркетинг, если кратко.
Та же история “языком запросов к API”. Что говорят авторы:
“GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data”.
С их слов GraphQL это:
Начнем с языка, что видим:
Ничего не напоминает?
Если брать п.1-3, то практически полной аналогией можно назвать JSON-RPC.
Если брать п.1-4, то все это SOAP.
Фактически, преред нами сетевой протокол уровня 7+ по модели OSI.
Ок, что там с рантаймом?
Для обработки запросов нужен некоторый компонент, который будет их парсить, валидировать, собирать/обновлять инфу из источников, публиковать SDL. Больше всех на слуху Apollo Server, но есть куча других опенсорсных и проприетарных решений.
Что, опять дежавю? Все так, тезисы полностью распространяются на тот же SOAP. Или gRCP, если сделать скидку на его бинарность.
В итоге получаем, что GraphQL это:
Вот и все, никакой мистики.
Здесь можно задать резонный вопрос: “Что ты придираешься, нормально звучит же: язык запросов”
А так, честный HATEOAS тоже можно языком запросов назвать, это даже корректнее будет.
Кто хочет копнуть глубже, посмотрите наш стрим с Денисом Лукьяновым, там еще куча материалов в описании.
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Особенности использования GraphQL. Интервью с Денисом Лукьяновым
Стрим с Денисом Лукьяновым, руководителем отдела backend разработки Samokat.tech, о неочевидных задачах и вызовах при использовании GraphQL:
- Протокол, фреймворк или архитектура?
- Преимущества технологии, и влияние на архитектуру
- Проблемы кэширования…
- Протокол, фреймворк или архитектура?
- Преимущества технологии, и влияние на архитектуру
- Проблемы кэширования…
👍28❤1
#архитектура
Первое правило аритектурного клуба - никому не рассказывать о клубе.
Участница последней встречи нарушила его и дала развернутый непредвзятый фидбек в двух частях: раз и два. За что мы ей бесконечно благодарны.
◽️ Кто еще сомневается, можете почитать и решить, нужно ли это вам.
◽️ Кто не в теме - мы регулярно встречаемся в сисдизайн клубе, где проектируем архитектуру под реальные задачи, а не избитые выдуманные кейсы из книг и ютуба. В прошлый раз была система A/B-тестов, в следующий раз будет риалтайм борда, которые активно растут на волне импортозамещения в РФ. Следующий раз - это 16го февраля.
П - прозрачность.
Кейс-клуб - сисдизайн здорового человека.
P.S. Тайминги лечим, верим в победу.
Первое правило аритектурного клуба - никому не рассказывать о клубе.
Участница последней встречи нарушила его и дала развернутый непредвзятый фидбек в двух частях: раз и два. За что мы ей бесконечно благодарны.
П - прозрачность.
Кейс-клуб - сисдизайн здорового человека.
P.S. Тайминги лечим, верим в победу.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11🔥1