Если убрать все навешанные навороты с телевизора, то возможность просмотра телепередач и интернета восстановится в прежнем объёме, пусть и в худшем, по сравнению с upgrade'ом, качестве.
В микросервисной архитектуре нет и не можеть быть в принципе ни одного компонента, который бы обладал функциональностью всего комплекса, пусть и в худшем качестве.
Я понимаю, что в некоторых случаях легаси-монолит можно постепенно трансформировать в микросервисы, но с телевизором и его периферией действительно не слишком удачный пример получился.
Что-то как-то не то. Создаётся впечатление, что монолит (телевизор) можно превратить в микросервисы (телевизор с гаджетами) путём добавления частей к базе. Но телевизор с гаджетами это совершенно не то же самое, что изначально спроектированное частями целое, типа советских музыкальных центров, где ты можешь совмещать усилитель, колонки, радио, магнитофон, проигрыватель пластинок и т.п. в разных комбинациях.
В микросервисах не наращивается (улучшается) базовая архитектура, но общая функциональность разбивается на части и создаётся отдельно, с возможностью пересборки этих отдельных частей в других проектах со схожей функциональностью (подключить микрофон к усилителю и колонкам и использовать в караоке).
Так что если ваш бизнес (или телевизор) начинает барахлить, возможно, пришло время подумать о микросервисах — по чуть-чуть, шаг за шагом, вы сделаете его современным и гибким, не ломая всю систему сразу.
Дело не в новизне, дело в популярности. Колесо ведь тоже изобрели не в одном месте. Но одни катали его сами, а другие поделились с теми, у кого его не было.
Тогда получается, что "микросервисы" это не техническая архитектура, а социальная (административная, организационная). Её появление вызывано не тем, что есть "бутылочные горлышки" в производительности, а тем, что нужно применять в разработке "криворуких индусов" (не все разработчики понимают ... и искренне не видят) Т.е., при достаточной квалификации можно и в одну БД работать ;)
В Magento именно так и происходит, только на уровне плагинов. И в WordPress так же, насколько я в курсе. Думаю, что и во всех популярных CMS'ках с плагинами точно так же дела обстоят: добавляешь плагин - появляются новые таблицы в БД.
Когда начинается взрослая работа с сотнями активных сессий и тысячами TPS , начинается ожидаемое "спасите помогите , мы уперлись в СУБД".
Так бывает. И не только в микросервисах. Для этого кэши и придумали. Как будто гонять данные между базами микросервисов для их синхронизации (репликации) много лучше?
Почему? Что на концептуальном уровне мешает микросервисам использовать общую СУБД? Какая разница, хранить свои данные в собственной БД или в своих таблицах в общей БД? Я имею в виду, что отдельному микросервису не нужно знать всю схему БД - достаточно только той части, что относится именно к его данным. А общая БД собирается из фрагментов. Появился новый микросервис - появились новые таблицы в общей БД.
На мой взгляд требование отдельных БД сравнимо с требованием отдельного ЦОДа для каждого микросервиса. Чтобы не было единой точки отказа. Можно, но не обязательно.
Полный код этого проекта, как и другой эксклюзивный контент, который я не публикую на Хабре, вы найдете в моем телеграмм канале «Легкий путь в Python».
и на всякий случай перепроверил заголовок статьи:
Связываем форму сайта с Telegram-ботом на чистом JavaScript за 15 минут: Полная разработка и деплой
Словил когнитивный диссонанс. Но потому досмотрел статью до конца - нет, всё в порядке. Python тоже будет нужен.
Статью заплюсовал за подробное техническое описание. Было любопытно почитать альтернативную моей точку зрения на веб-разработку.
Насколько я понял, теперь можно будет более эффективно генерировать триаду JS/HTML/CSS из ESM/CJS/UMD/TS/JSX/TSX/HTMX/Markdown/$mol.tree... Наверное, это добро (если не принимать во внимание, как потом этот зоопарк дебажить).
Да-а... Алан Карр... бросил за один день после прочтения его книги. До этого пробовал разными способами - не получалось. А потом прочитал книгу на работе с экрана компьютера - и бросил. Даже "последнюю сирагету" не докурил. А книга совсем простая - раз пятсот в разных вариациях повторяют простую фразу: "хочешь бросить курить - не кури".
А по логике для каждой конкретной задачи есть только одно лучшее решение.
Не согласен. Сложные задачи имеют более одного правильного решения, оптимальность которых зависит от применяемых критериев оценки (по скорости, по размеру, по потреблению памяти, ...).
Это в у нас воскресенье- последний день в неделе. А у англичан, например - первый. Так что у них Воскресенье Его уже было :( Впереди только уикенд - пятничное разгуляево и субботнее похмелье. Я в Англии клубнику собирал как-то, проводил практические опыты с тамошними. И эта моя философская теория вполне себе имеет обоснование. Текилу не пили - всё больше сидр и пиво.
Прелесть в том, что когда вы сами будете сами следить за этим всем, то это и будет Web 3.0. Пока за вами следят - это двоечка, а как только вы "сами-сами-сами" - это уже следующая ступень.
Вам для вас никто не сделает Web 3.0, Только сами.
Web 3.0 как раз и решает проблемы с данными во власти корпораций. Если для пользователя важна конфиденциальность данных, то он применяет набор технологий (шифрование, распределённые хранилища, peer-to-peer взаимодействия), который в совокупности ограничивает доступ корпораций (и вообще кого угодно) к его данным. Вот этот набор технологий и есть Web 3.0 (включая семантическую сеть).
Но дело в том, что корпорации не просто так берут ваши персональные данные, а предлагают вам за них какие-то плюшки. Происходит взаимодействие win-win (как правило). Те же каналы, их монетизация и раздел прибыли. Наш "ламповый" Web 2.0. Поэтому пользователь вполне сознательно может отдавать в эксплуатацию часть своих персональных данных в обмен на эти плюшки.
Каждый из нас может одновременно сидеть во всех трёх вебах: статическом персональном (какая-нибудь "Библиотека Мошкова"), корпоративном централизованном (Facebook) и распределённом приватном (типа такого). Все три типа сосуществуют одновременно, как в Мультивселенной.
Кстати, браузер для Web 3.0 так же хорошо может работать и для остальных типов веба. Ну, там, загрузить по голосовой команде книжку из Библиотеки Мошкова и прочитать её на ночь перед сном :)
Ну так и я его создал, в своей голове. Если коротко, то вы обнаруживаете шаблон решения типовой задачи на основании множества примеров - "придумываете формулу". Каждой типовой задаче соответствует свой шаблон. И у человеков, и у ИИ так это работает. Что тут ещё копаться-то?
Может нейросети и должны ржать над людьми, но у меня в голове именно так и сложилось понимание внутрянки работы Пролога. В какой-то момент я просто понял (щёлкнуло) и за 10 минут написал код, над которым сидел почти всю пару. После этого мог писать на Прологе вообще всё институтское без напряга. У писателя Хайнлайна есть такая фраза - "грокнуть во всей полноте". Она как раз про "щёлк".
Если убрать все навешанные навороты с телевизора, то возможность просмотра телепередач и интернета восстановится в прежнем объёме, пусть и в худшем, по сравнению с upgrade'ом, качестве.
В микросервисной архитектуре нет и не можеть быть в принципе ни одного компонента, который бы обладал функциональностью всего комплекса, пусть и в худшем качестве.
Я понимаю, что в некоторых случаях легаси-монолит можно постепенно трансформировать в микросервисы, но с телевизором и его периферией действительно не слишком удачный пример получился.
Что-то как-то не то. Создаётся впечатление, что монолит (телевизор) можно превратить в микросервисы (телевизор с гаджетами) путём добавления частей к базе. Но телевизор с гаджетами это совершенно не то же самое, что изначально спроектированное частями целое, типа советских музыкальных центров, где ты можешь совмещать усилитель, колонки, радио, магнитофон, проигрыватель пластинок и т.п. в разных комбинациях.
В микросервисах не наращивается (улучшается) базовая архитектура, но общая функциональность разбивается на части и создаётся отдельно, с возможностью пересборки этих отдельных частей в других проектах со схожей функциональностью (подключить микрофон к усилителю и колонкам и использовать в караоке).
Ну и вывод, соответственно, также неверен.
Дело не в новизне, дело в популярности. Колесо ведь тоже изобрели не в одном месте. Но одни катали его сами, а другие поделились с теми, у кого его не было.
Тогда получается, что "микросервисы" это не техническая архитектура, а социальная (административная, организационная). Её появление вызывано не тем, что есть "бутылочные горлышки" в производительности, а тем, что нужно применять в разработке "криворуких индусов" (не все разработчики понимают ... и искренне не видят) Т.е., при достаточной квалификации можно и в одну БД работать ;)
Согласен. Но DBA и не архитектор.
В Magento именно так и происходит, только на уровне плагинов. И в WordPress так же, насколько я в курсе. Думаю, что и во всех популярных CMS'ках с плагинами точно так же дела обстоят: добавляешь плагин - появляются новые таблицы в БД.
Так бывает. И не только в микросервисах. Для этого кэши и придумали. Как будто гонять данные между базами микросервисов для их синхронизации (репликации) много лучше?
Почему? Что на концептуальном уровне мешает микросервисам использовать общую СУБД? Какая разница, хранить свои данные в собственной БД или в своих таблицах в общей БД? Я имею в виду, что отдельному микросервису не нужно знать всю схему БД - достаточно только той части, что относится именно к его данным. А общая БД собирается из фрагментов. Появился новый микросервис - появились новые таблицы в общей БД.
На мой взгляд требование отдельных БД сравнимо с требованием отдельного ЦОДа для каждого микросервиса. Чтобы не было единой точки отказа. Можно, но не обязательно.
С таким предложением лучше напрямую к ним. Я к AST вообще никаким боком.
Дошёл вот до этой строки:
и на всякий случай перепроверил заголовок статьи:
Словил когнитивный диссонанс. Но потому досмотрел статью до конца - нет, всё в порядке. Python тоже будет нужен.
Статью заплюсовал за подробное техническое описание. Было любопытно почитать альтернативную моей точку зрения на веб-разработку.
Насколько я понял, теперь можно будет более эффективно генерировать триаду JS/HTML/CSS из ESM/CJS/UMD/TS/JSX/TSX/HTMX/Markdown/$mol.tree... Наверное, это добро (если не принимать во внимание, как потом этот зоопарк дебажить).
Да-а... Алан Карр... бросил за один день после прочтения его книги. До этого пробовал разными способами - не получалось. А потом прочитал книгу на работе с экрана компьютера - и бросил. Даже "последнюю сирагету" не докурил. А книга совсем простая - раз пятсот в разных вариациях повторяют простую фразу: "хочешь бросить курить - не кури".
Не согласен. Сложные задачи имеют более одного правильного решения, оптимальность которых зависит от применяемых критериев оценки (по скорости, по размеру, по потреблению памяти, ...).
Люди, которые с уверенностью предвещают будущее, ничем не рискуют. Если бы они рисковали хоть чем-нибудь, они бы не были так уверенны.
Зачем быть более терпимым к людям, с которыми ты не собираешься иметь ничего общего? И это тоже ключ... только к другой двери...
Это в у нас воскресенье- последний день в неделе. А у англичан, например - первый. Так что у них Воскресенье Его уже было :( Впереди только уикенд - пятничное разгуляево и субботнее похмелье. Я в Англии клубнику собирал как-то, проводил практические опыты с тамошними. И эта моя философская теория вполне себе имеет обоснование. Текилу не пили - всё больше сидр и пиво.
У нас разное "дробление" веба по версиям. Вы основываетесь на том, кто на чём зарабатывает, но я не нашёл такого критерия в общепринятом разбиении:
Web 1.0
Web 2.0
Web 3.0
Так что я, пожалуй, останусь при своём мнении и не буду спорить.
Прелесть в том, что когда вы сами будете сами следить за этим всем, то это и будет Web 3.0. Пока за вами следят - это двоечка, а как только вы "сами-сами-сами" - это уже следующая ступень.
Вам для вас никто не сделает Web 3.0, Только сами.
Мне кажется, вы пытаетесь донести до меня какую-то мысль. Но у меня не "щёлкает" - не могу грокнуть. Попробуйте расширить набор примеров.
"Не согласен!" (с)
Web 3.0 как раз и решает проблемы с данными во власти корпораций. Если для пользователя важна конфиденциальность данных, то он применяет набор технологий (шифрование, распределённые хранилища, peer-to-peer взаимодействия), который в совокупности ограничивает доступ корпораций (и вообще кого угодно) к его данным. Вот этот набор технологий и есть Web 3.0 (включая семантическую сеть).
Но дело в том, что корпорации не просто так берут ваши персональные данные, а предлагают вам за них какие-то плюшки. Происходит взаимодействие win-win (как правило). Те же каналы, их монетизация и раздел прибыли. Наш "ламповый" Web 2.0. Поэтому пользователь вполне сознательно может отдавать в эксплуатацию часть своих персональных данных в обмен на эти плюшки.
Каждый из нас может одновременно сидеть во всех трёх вебах: статическом персональном (какая-нибудь "Библиотека Мошкова"), корпоративном централизованном (Facebook) и распределённом приватном (типа такого). Все три типа сосуществуют одновременно, как в Мультивселенной.
Кстати, браузер для Web 3.0 так же хорошо может работать и для остальных типов веба. Ну, там, загрузить по голосовой команде книжку из Библиотеки Мошкова и прочитать её на ночь перед сном :)
Ну так и я его создал, в своей голове. Если коротко, то вы обнаруживаете шаблон решения типовой задачи на основании множества примеров - "придумываете формулу". Каждой типовой задаче соответствует свой шаблон. И у человеков, и у ИИ так это работает. Что тут ещё копаться-то?
Может нейросети и должны ржать над людьми, но у меня в голове именно так и сложилось понимание внутрянки работы Пролога. В какой-то момент я просто понял (щёлкнуло) и за 10 минут написал код, над которым сидел почти всю пару. После этого мог писать на Прологе вообще всё институтское без напряга. У писателя Хайнлайна есть такая фраза - "грокнуть во всей полноте". Она как раз про "щёлк".