Это да, но также и добавляет сложности в поддержке. Т.к. у нас команды действительно независимые и приложения, которые они пишут, достаточно независимы, для нас актуален выбор нужного фреймворка для задачи, решаемой приложением.
Нет, к сожалению, сейчас она не доступна в общем доступе и к распространению внутри открытого сообщества пока не планируется. С другой стороны, самое важное, что в ней есть — идея, которую я тут и раскрыл.
Еще замечание по поводу яндекса. Так и есть, они строят страницу из кусочков, поставляемых разными микросервисами. Вот только они пошли чуть дальше — у них есть серверный рендеринг и сборка страницы происходит риал тайм. Подобный подход есть и у других компаний. Есть даже опенсорс решение на посмотреть Project Mosaic
Я привел пример такой задачки с корзиной покупок. Как только мы разделили магазин и личный кабинет на два независимых микросервиса, появилась проблема с переиспользованием действительно независимого куска — корзины. Вполне себе реальный жизненный случай.
Я не сказал, что взаимодействие полностью исключается. Мы исходим из того, что прямое взаимодействие скорее говорит о неверном делении.
Думаю, что вся проблема в понимании термина «монолит». Монолит — это не когда у тебя только один сервер с только одним аппликейшеном на нем. Монолит также может быть построен на сервисной архитектуре. Микросервисная архитектура — является частным примером сервисной. Так вот речь о том, что именно микросервисная архитектура не подходит для маленьких команд. Бенефитов меньше.
Эта архитектура предполагает достаточно мелкое деление, которое не разумно для маленьких команд в связи с увеличивающейся стоимостью поддержки инфраструктуры.
При этом сервисную (макросервисную) архитектуру никто использовать не запрещает по необходимости. Тут всегда вопрос компромисса между стоимостью поддеркжи, производительностью и масштабируемостью.
Да, НО… Это не решает поставленные задачи. В браузерах, не реализующих полноценную поддержку Web Components, все равно не возможно добиться изоляции. А значит и их использование не оправданно. Надо сказать, что в некоторых случаях, если фрагмент пишется на Angular, Angular Elements используются для создания фрагмента.
Никаких попыток прямого взаимодействия с другими фрагментами быть не должно.
Также для общения фрагментов между собой есть шина, построенная на Observable и rxjs.
У фрагмента нет публичного API. Фрагмент != компонент. Это не читсая вью — это прямо самостоятельный кусок UI, который самодостаточен и ему не нужно ничего из вне. Поэтому таким фрагментам очень редко нужно взаимодействие с внешним миром. Если оно нужно — делаем через EventBus.
Или как решается к примеру проблема, когда сообщение публикуется, но не все подписчики еще инициализировались.
Эта задача легко решается с помощью Observable. Используется специальный тип, который хранит состояние и подписчиков на его изменение.
Спасибо большое за коммент!
Делаем, потому, что размеры решения очень большие и количество команд разработки растет как на дрожжах. Так что скорее показалось.
По производительности — импакт, безусловно есть. Но мы применяем много разных техник оптимизации, чтобы свести их к допустимому минимуму. В некоторых случаях получается даже быстрее чем если бы каждый из компонентов (разработанных разными командами) ходил за одними и теми же данными самостоятельно (сервис локализации, авторизации, интернационализации, конфигурации, дизайн токенов и пр.)
Нет, не совсем. Web Components — это способ изоляции частей UI и это крутой подход, чтобы не заморачиваться не конфликты стилей, конфликты библиотек и прочее. Как только мы сможем его использовать в полную силу — обязательно наши фрагменты будут строиться на них. Пока же это все только планы и разрозненные имплементации в разных браузерах.
Ну да и нет :) Мы вполне позволяем менять настройки и пр. администратору портала со стороны заказчика. Т.е. мы делаем первоначальное внедрение (страницы, конфигурация портлетов, контент и пр.), а потом это все может модифицировать заказчик. И вот тут начинается веселье. Мы делаем какие-то новые фичи, требующие изменение настроек и админы делают изменения в конфиге — как мержить?
Про поддержку веб-серверов — да, почти так — может работать на любом сервере — но есть небольшие нюансы.
Самая печальная новость. Это что же, теперь все, кто не на томкате, должны энтерпрайз лицензию покупать?
и тут не со всем понял что имеется в виду под «масштабируется слабо»
Кластеризация предполагает постоянную синхронизацию по данным. А это сразу же бутылочное горлышко — горизонтально не отмасштабируешься.
У нас целый отдел занимающий инфраструктурой, поэтому про внутрянку серверов не могу сказать. На бекенде две ноды аппликейшена, Две ноды БД. На фронтенде 2 ноды аппликейшена с локальной мелкой базой. Также балансеры, файрволы и прочая утварь.
Давай начнем с масштабируемости. Сам лайфрей вообще говоря масштабируется слабо. Есть несколько схем, но все упирается в то, что пользователей он хранит в БД, которую надо либо синхронизировать между нодами, либо шарить и кластеризовать в целях HA. Также сам лайфрей умеет кластеризоваться — масштабироваться вертикально.
Мы применяем стандартно другой подход — код разрабатывается общий и раскатывается по нужному количеству серверов без синхронизации. Пользователи хранятся в отдельной idm и там же менеджатся. Таким образом каждая нода независима и горизонтально можно масштабировать до бесконечности.
Кеширование — опять же, сам по себе лайфрей кеширует много чего, но это никак не касается нашей бизнес логики. Мы, конечно же, тоже кешируем. Лайфрей сразу же идет с поддержкой Ehсache, который и использует. Также его используем и мы.
Не очень понял про разные сервера приложений. Сам лайфрей не зависит от реализации контейнера и легко работает как на Webloic так и на JBoss и на Tomcat. От базы данных тоже не зависит — используется стандартный hibernate. Сама по себе раскладка у нас осуществляется специальной внутренней тулой, используемой для раскладки по тестовым, CI, стейджинг и продакшен окружениям.
Производительность… Могу так ответить, в 95% случаев проблемы производительности не на стороне самого портала, а на стороне BE, где крутится вся логика. Со стороны портала занимаемся производительностью оптимизируя размеры страниц, асинхронно подгружая долгие данные, объединяя скрипты, кешируя все и все и пр. стандартные средства. Из цифр могу сказать — 800 req./sec держим лекго.
Надо понимать, что в этой статье я описываю подход к функциональной разработке. Понятно, что разрабатываем мы разные порталы с разными требованиями как к функционалу так и производительности и везде свои решения. Лайфрей нам тут помогает поддерживая из коробки ряд совсем стандартных подходов.
Вы немного лукавите, на мой взгляд. Наверняка же заглядывали в «реляционные» таблички лайфрея? И видели огромные XML лежащие в ячейках. Вот это все — примерно 50% полезной информации. И оно в абсолютно не реляционном виде.
Вручную переносить конфигурацию на прод — это же смерти подобно. У нас короткие окна обновлений прода. Если КАЖДЫЙ раз я буду на прод заливать конфигурацию вручную, все пропало. Ну и вопрос мержа конфигурации все равно остается актуальным даже в этом случае. Один проставил одну пропертю в одно значение и записал это в инструкцию, а другой проставил другое значение и тоже записал в инструкцию. Кто, как и когда мержит.
В определенных количествах — да, абсолютно. Есть портлеты-баннеры, текстовики, оформительские, абсолютно самостоятельные. Их и двигают и даже тестируют как больше нравится конечным пользователям. Чем более «динамическая» страница, тем меньше подобных возможностей.
Но мы над стандартными возможностями конфигурации Liferay надстроили свои функции, которые дают еще больше возможностей. Таких как изменение шаблонов портлетов на лету, использование дополнительных параметров объектов, задаваемых через CMS и много другого.
И да, по сути Liferay был выбран изначально за то, что дает неплохой старт не заставляя разрабатывать все это с нуля.
Ну что вам сказать. Я описал эту же боль в статье немного лаконичнее. Сам портлетный подход хорош в теории, но на практике его плюсы никто не использует. Но при этом все выставленные им ограничения приходится обходить постоянно.
Для взаимодействия между портлетами мы используем либо шину событий на клиенте, либо общие синглтоны и сервисный слой. В зависимости от задачи. В 98% случаев хватает. В остальных 2% случаев нужно остановиться и подумать — а все ли я делаю так, не усложняю ли?
Лицензия — вы правы — очень дорогая. Но есть и бесплатная версия полностью функциональная, которую можно допилить напильником под себя и жить до следующего релиза :)
Шаблоны, о которых вы говорите, не совсем то, что нам нужно. Основной плюс, который мы получили от GCT — это один шаблон для отрисовки на клиенте и сервере. Это реально работает и очень часто помогает.
Я не сказал, что взаимодействие полностью исключается. Мы исходим из того, что прямое взаимодействие скорее говорит о неверном делении.
Эта архитектура предполагает достаточно мелкое деление, которое не разумно для маленьких команд в связи с увеличивающейся стоимостью поддержки инфраструктуры.
При этом сервисную (макросервисную) архитектуру никто использовать не запрещает по необходимости. Тут всегда вопрос компромисса между стоимостью поддеркжи, производительностью и масштабируемостью.
У фрагмента нет публичного API. Фрагмент != компонент. Это не читсая вью — это прямо самостоятельный кусок UI, который самодостаточен и ему не нужно ничего из вне. Поэтому таким фрагментам очень редко нужно взаимодействие с внешним миром. Если оно нужно — делаем через
EventBus.Эта задача легко решается с помощью
Observable. Используется специальный тип, который хранит состояние и подписчиков на его изменение.Делаем, потому, что размеры решения очень большие и количество команд разработки растет как на дрожжах. Так что скорее показалось.
По производительности — импакт, безусловно есть. Но мы применяем много разных техник оптимизации, чтобы свести их к допустимому минимуму. В некоторых случаях получается даже быстрее чем если бы каждый из компонентов (разработанных разными командами) ходил за одними и теми же данными самостоятельно (сервис локализации, авторизации, интернационализации, конфигурации, дизайн токенов и пр.)
Ну да и нет :) Мы вполне позволяем менять настройки и пр. администратору портала со стороны заказчика. Т.е. мы делаем первоначальное внедрение (страницы, конфигурация портлетов, контент и пр.), а потом это все может модифицировать заказчик. И вот тут начинается веселье. Мы делаем какие-то новые фичи, требующие изменение настроек и админы делают изменения в конфиге — как мержить?
Самая печальная новость. Это что же, теперь все, кто не на томкате, должны энтерпрайз лицензию покупать?
Кластеризация предполагает постоянную синхронизацию по данным. А это сразу же бутылочное горлышко — горизонтально не отмасштабируешься.
Давай начнем с масштабируемости. Сам лайфрей вообще говоря масштабируется слабо. Есть несколько схем, но все упирается в то, что пользователей он хранит в БД, которую надо либо синхронизировать между нодами, либо шарить и кластеризовать в целях HA. Также сам лайфрей умеет кластеризоваться — масштабироваться вертикально.
Мы применяем стандартно другой подход — код разрабатывается общий и раскатывается по нужному количеству серверов без синхронизации. Пользователи хранятся в отдельной idm и там же менеджатся. Таким образом каждая нода независима и горизонтально можно масштабировать до бесконечности.
Кеширование — опять же, сам по себе лайфрей кеширует много чего, но это никак не касается нашей бизнес логики. Мы, конечно же, тоже кешируем. Лайфрей сразу же идет с поддержкой Ehсache, который и использует. Также его используем и мы.
Не очень понял про разные сервера приложений. Сам лайфрей не зависит от реализации контейнера и легко работает как на Webloic так и на JBoss и на Tomcat. От базы данных тоже не зависит — используется стандартный hibernate. Сама по себе раскладка у нас осуществляется специальной внутренней тулой, используемой для раскладки по тестовым, CI, стейджинг и продакшен окружениям.
Производительность… Могу так ответить, в 95% случаев проблемы производительности не на стороне самого портала, а на стороне BE, где крутится вся логика. Со стороны портала занимаемся производительностью оптимизируя размеры страниц, асинхронно подгружая долгие данные, объединяя скрипты, кешируя все и все и пр. стандартные средства. Из цифр могу сказать — 800 req./sec держим лекго.
Надо понимать, что в этой статье я описываю подход к функциональной разработке. Понятно, что разрабатываем мы разные порталы с разными требованиями как к функционалу так и производительности и везде свои решения. Лайфрей нам тут помогает поддерживая из коробки ряд совсем стандартных подходов.
Вручную переносить конфигурацию на прод — это же смерти подобно. У нас короткие окна обновлений прода. Если КАЖДЫЙ раз я буду на прод заливать конфигурацию вручную, все пропало. Ну и вопрос мержа конфигурации все равно остается актуальным даже в этом случае. Один проставил одну пропертю в одно значение и записал это в инструкцию, а другой проставил другое значение и тоже записал в инструкцию. Кто, как и когда мержит.
Но мы над стандартными возможностями конфигурации Liferay надстроили свои функции, которые дают еще больше возможностей. Таких как изменение шаблонов портлетов на лету, использование дополнительных параметров объектов, задаваемых через CMS и много другого.
И да, по сути Liferay был выбран изначально за то, что дает неплохой старт не заставляя разрабатывать все это с нуля.
Про банки и телекомы не понял. Где тут загвоздка? Мы крупный телеком software провайдер.
Для взаимодействия между портлетами мы используем либо шину событий на клиенте, либо общие синглтоны и сервисный слой. В зависимости от задачи. В 98% случаев хватает. В остальных 2% случаев нужно остановиться и подумать — а все ли я делаю так, не усложняю ли?
Лицензия — вы правы — очень дорогая. Но есть и бесплатная версия полностью функциональная, которую можно допилить напильником под себя и жить до следующего релиза :)