Пока документацию только пишем, но про ресурсы можно сказать примерно так: "как в обычном Spring Boot, если будете использовать JS клиента". В случае, если вы будете активно использовать Backoffice UI, то там придётся раскошелиться на память на сервере, потому что каждая пользовательская сессия может занимать до нескольких мегабайт памяти из-за особенностей рендеринга UI
Справедливо. Спасибо за конструктив. А QuickStart видео все-таки гляньте ;-) Там всего минут 15 посмотреть, как приложение делается, думаю, сильно понятнее будет.
Дельное замечание. Наверное, в каждой статье нужно будет делать абзац-введение, что это за фреймворк.
Вопрос: а что лично вас бы заинтересовало?
Просто вот идем на [micronaut](https://micronaut.io/) и читаем: «A modern, JVM-based, full-stack framework for building modular, easily testable microservice and serverless applications.». Это интересно или нет?
[Spring](https://spring.io): «Spring makes Java productive. What Spring can do: Microservices, Reactive, Cloud, Web apps».
[Jmix](https://jmix.io): «An Open Source Rapid Application Development Platform for Modern Web Applications»
Что нам нужно сделать для Jmix, чтобы заинтересовать, как вы думаете?
Фреймворк предлагает ускорение разработки за счет того, что делается приложение с «типовой» архитектурой, в рамках которой во фреймворке уже есть готовые сервисы из коробки. И это будет Spring/Spring Boot приложение, т.е. ничего нового учить не надо.
Возможности Jmix можно представить по ролику Quick Start для предыдущей версии. Можно начинать с 2:33.
А если не хочется использовать сервисы, которые идут вместе с фреймворком, то скорость разработки падает до скорости разработки на «голом» Spring/Spring Boot.
Вы покурите spring-data-commons, там классные API есть, типа PartTree, которые делают магию разбора имени метода в дерево с валидацией правильности названий свойств и т.д.
И да, это был тестовый проект, просто проверить, насколько проблемно будет прикрутить безопасность. Дальше можно делать токены и кэшировать на клиенте. Просто это не production приложение, не хотелось сильно усложнять все.
В теории, будет выигрыш по времени старта и по потреблению памяти. Можно посмотреть на quarkus.io, у них там есть методика того, как они тестируют приложения. На практике, ответ один: нужно тестировать именно ваше приложение и ваши кейсы. Может, вы при старте ходите в 100500 супермедленных веб-сервисов, так что вам 500мс выигрыша ничего не дадут.
Да, справедливо. Если буду делать читать этот доклад ещё раз, то так и переформулирую. И попутно вкручу соображения про CWA. Excelsior — это здорово, но теперь же не загрузишь же дистрибутив с официального сайта. Если только по знакомым и третьесторонним файлопомойкамхранилищам искать :-)
Привет, спасибо за комментарий, я смотрел вот это видео. Мне точно надо как-то все-таки правильнее и яснее выражаться. AOT компиляция и reflection не противоречат друг другу, но в случае их совместного использования все становится немного сложнее. Можно нормально скомпилировать приложение, которое использует reflection. Какие-то классы, которые используются через reflection, можно вывести автоматически, какие-то — явно вписать в конфигурационные файлы и скормить эти файлы компилятору (если мы говорим о GraalVM компиляторе), где-то — угадать, какая будет логика загрузки классов в рантайме после старта программы. Мое мнение — на сложных приложениях такой подход будет давать сбои, учитывая, сколько сторонних библиотек мы с собой обычно тащим явно и неявно, в которых может быть вообще что угодно. Простой пример: аккуратно собранный Spring Context, ничего лишнего, компилятор все отлично собирает. Но вот в случае запуска через
java -jar
все прекрасно работает, а в случае запуска native image работает не все. И это обозримый код. Конечно, это больше говорит о недостатках GraalVM, но, тем не менее, в связи с переездом Excelsior под крыло Huawei, этот компилятор остается чуть не единственным вариантом для тех, кто хочет работать с AOT в java.
Есть разные подходы. Кто-то предпочитает «анемичные» сущности и бизнес-логику вынести в сервисы, кто-то старается добавить в сущности сложную логику и поведение.
Я не очень понял, почему вы решили, что бизнес-логика растекается по системе. Мы ограничиваем доступ к атрибутам, исходя из того, что именно нужно для реализации того или иного бизнес-кейса, который как раз реализован в классе-сервисе. А кейс может обрабатываться как в UI, так и в классе, которому выдана только необходимая ему проекция сущности. Этот подход хорошо работает, если у вас в сущностях большое количество атрибутов.
Естественно :-) Назвается CUBA View. Писали про это на хабре. Поэтому, кстати, и EclipseLink используем вместо Hibernate, он хорошо умеет partial entities. Конечно, в CUBA Views есть свой аналог LazyInit, но мы думаем, как и это неудобство изничтожить. И ещё — можно почитать про то, как можно сделать слой работы с данными а-ля Spring Repositories, чтобы работать с данными было ещё немного проще. Вот тут статья. CUBA — довольно гибкий фреймворк, потому что там Spring внутри. Так что можно довольно просто компоненты CUBA заменить на свои или расширить, если нужно.
Мы работаем не поверх сервисов Spring, у нас свой слой работы с данными поверх EclipseLink, про наш API можно почитать тут. API очень тонкий, так что производительность ровно такая же, как у EclipseLink. Мы не делаем proxy поверх объектов-сущностей, а EclipseLink делает очень приличный weaving над сущностями, чтобы избежать рефлексии, когда вытаскиваешь значение атрибута сущности по имени-строке. Если нужна тонкая настройка, то можно выполнять JPQL или, если совсем тяжело, можно использовать SQL. А ещё у нас, конечно же, есть query и data кэши.
Версия CUBA жестко не привязана к версии Vaadin, для этого и сделали свой API поверх него. Мы можем переехать на Vaadin 1x в CUBA 7.1, например, и вы это заметите только потому, что в компонентах появятся новые свойства. А код, написанный на CUBA, менять не надо будет. Мы при разработке огромное количество усилий прикладываем для обеспечения обратной совместимости и гладкости миграции на новые версии как раз из тех соображений, что вы привели. Потому что корпоративные системы живут и разрабатываются долго. И да, Vaadin UI можно вообще не использовать, это отдельный модуль, который можно удалить из проекта. У нас есть проекты, где CUBA используется только как back-end.
Наверное, ещё раз надо будет статью сделать типа "Введение в CUBA: Petclinic". Или домашнюю бухгалтерию на 7-й платформе переделать.
Отвечая на ваш вопрос: CUBA — это фреймворк для быстрой разработки приложений. Spring + некоторые дополнительные сервисы (типа встроенного Soft Delete или Row-based access) + инструменты для генерации кода (CLI и IntelliJ плагин). В качестве примерных аналогов можно вспомнить Grails и JHipster, но там есть отличия в функциональности и инструментарии. Попробуйте сделать quickstart — это где-то 30 минут займет, но даст примерное представление, что CUBA умеет.
Спасибо! Мы стараемся :-) Предыдущий выход в опенсорс никак не повредил, а очень даже помог. И есть ощущение, что дальнейшая бесплатность только улучшит наше положение. Так что мы за оптимизм.
Не совсем кастомизируем. Мы его своим API оборачиваем, чтобы проще было с ним работать. И чтобы всем было проще мигрировать приложения на новые версии платформы. Если посмотрите на примеры — там не совсем Vaadin в контроллерах. А чего от Vaadin не отнять — так это компонентов, с которыми очень быстро можно делать GUI.
Пока документацию только пишем, но про ресурсы можно сказать примерно так: "как в обычном Spring Boot, если будете использовать JS клиента". В случае, если вы будете активно использовать Backoffice UI, то там придётся раскошелиться на память на сервере, потому что каждая пользовательская сессия может занимать до нескольких мегабайт памяти из-за особенностей рендеринга UI
Вопрос: а что лично вас бы заинтересовало?
Просто вот идем на [micronaut](https://micronaut.io/) и читаем: «A modern, JVM-based, full-stack framework for building modular, easily testable microservice and serverless applications.». Это интересно или нет?
[Spring](https://spring.io): «Spring makes Java productive. What Spring can do: Microservices, Reactive, Cloud, Web apps».
[Jmix](https://jmix.io): «An Open Source Rapid Application Development Platform for Modern Web Applications»
Что нам нужно сделать для Jmix, чтобы заинтересовать, как вы думаете?
Возможности Jmix можно представить по ролику Quick Start для предыдущей версии. Можно начинать с 2:33.
А если не хочется использовать сервисы, которые идут вместе с фреймворком, то скорость разработки падает до скорости разработки на «голом» Spring/Spring Boot.
Вы покурите spring-data-commons, там классные API есть, типа PartTree, которые делают магию разбора имени метода в дерево с валидацией правильности названий свойств и т.д.
В теории, будет выигрыш по времени старта и по потреблению памяти. Можно посмотреть на quarkus.io, у них там есть методика того, как они тестируют приложения. На практике, ответ один: нужно тестировать именно ваше приложение и ваши кейсы. Может, вы при старте ходите в 100500 супермедленных веб-сервисов, так что вам 500мс выигрыша ничего не дадут.
помойкамхранилищам искать :-)Я не очень понял, почему вы решили, что бизнес-логика растекается по системе. Мы ограничиваем доступ к атрибутам, исходя из того, что именно нужно для реализации того или иного бизнес-кейса, который как раз реализован в классе-сервисе. А кейс может обрабатываться как в UI, так и в классе, которому выдана только необходимая ему проекция сущности. Этот подход хорошо работает, если у вас в сущностях большое количество атрибутов.
Естественно :-) Назвается CUBA View. Писали про это на хабре. Поэтому, кстати, и EclipseLink используем вместо Hibernate, он хорошо умеет partial entities. Конечно, в CUBA Views есть свой аналог LazyInit, но мы думаем, как и это неудобство изничтожить. И ещё — можно почитать про то, как можно сделать слой работы с данными а-ля Spring Repositories, чтобы работать с данными было ещё немного проще. Вот тут статья. CUBA — довольно гибкий фреймворк, потому что там Spring внутри. Так что можно довольно просто компоненты CUBA заменить на свои или расширить, если нужно.
Мы работаем не поверх сервисов Spring, у нас свой слой работы с данными поверх EclipseLink, про наш API можно почитать тут. API очень тонкий, так что производительность ровно такая же, как у EclipseLink. Мы не делаем proxy поверх объектов-сущностей, а EclipseLink делает очень приличный weaving над сущностями, чтобы избежать рефлексии, когда вытаскиваешь значение атрибута сущности по имени-строке. Если нужна тонкая настройка, то можно выполнять JPQL или, если совсем тяжело, можно использовать SQL. А ещё у нас, конечно же, есть query и data кэши.
Наверное, ещё раз надо будет статью сделать типа "Введение в CUBA: Petclinic". Или домашнюю бухгалтерию на 7-й платформе переделать.
Отвечая на ваш вопрос: CUBA — это фреймворк для быстрой разработки приложений. Spring + некоторые дополнительные сервисы (типа встроенного Soft Delete или Row-based access) + инструменты для генерации кода (CLI и IntelliJ плагин). В качестве примерных аналогов можно вспомнить Grails и JHipster, но там есть отличия в функциональности и инструментарии. Попробуйте сделать quickstart — это где-то 30 минут займет, но даст примерное представление, что CUBA умеет.