Следующая задача, кстати, архитектурная и глобальная. — 30 июня 2026 г. в 21:09:40.789
Следующая задача, кстати, архитектурная и глобальная. Для того, чтобы немного приподнять занавес, мне придётся объяснить, каким именно образом пишут приложения. Может быть душновато. Откройте окно, подышите, и приступим. В первую очередь приложения делятся на несколько групп: 🟡 Монолитные - это база. Например, без явных указаний любой ИИ напишет вам монолитное приложение. Суть монолита в том, что все вызовы совершаются в одной среде, а содержимое разворачивается как единое целое. Куда запрос пришёл - там он и останется. На веб-сервере (PHP), в облаке (Y Functions), в рантайме (NodeJS). 🟡 Следующий уровень декомпозиции приложения - модульный. Когда мы разбиваем один монолит на связанные и склеееные намертво модули. Они по прежнему выполняются в одной среде, но имеют чёткие границы, что позволяет тестировать и дебажить их отдельно друг от друга. Но, положа руку на сердце, это просто хорошо организованный монолит. 🟡 Если мы разделим их друг от друга ещё сильнее - то получим микросервисы. Это уже взрослый такой уровень больших распределённых систем. Банки, маркетплейсы, бортовые компьютеры космических шаттлов... Последнее, кстати, не точно. Все они построены на микросервисах. По сути если мы отделим модули друг от друга, сделаем полностью самостоятельными, прикрутим к ним точку входа, контракт запроса/ответа, сделаем самостоятельный деплой - мы получим микросервис. Особенность такой архитектуры в том, что микросервисы не просто отделены друг от друга - они являются независимыми сущностями. Один микросервис можно запустить на одном сервере, другой на другом, а работать они будут как единое приложение. 🟡 А ещё есть плохие микросервисы. Это когда сервисы разные, но связаны так плотно, что страдаешь с ними как с монолитом. Но в канале могут быть дети, поэтому я не буду останавливаться на этом типе ещё больше. Часть 1/2.