А не подскажите примеры правильного развертывание spring boot в кубере? Через 2.5 недели хакатон, я девопс стажер друг бекендер на джаве, хотим заранее инфраструктуру готовить под хакатон) И поэтому хочется посмотреть примеры в гитхабе с понятным readme
Достаточно запустить spring boot в docker-контейнере. Далее его развертывание в kubernetes мало чем отличается от других фреймворков. Почитать про особенности можно здесь docs.spring.io/spring-boot/how-to/deployment/cloud.html А в целом читайте туториалы как деплоить микросервисы в kubernetes. Их очееь много.
@@semzin vaadin это java-ориентированная фронтенд разработка, да. По сути это всё для бэкендеров сделано. Если есть фронты, то нужно делать на классическом фронтендовом стеке.
Такой вопрос - позволяет ли spring cloud как то показать граф зависимостей между микросервисами? Напермер что сервис1 обращаеться (посылает запросы) к сервису 2 , сервис 2 - к сервису 3 а сервис 3 - к сервису 1 и все они обращаються к сервису 4 ?
Нет. Для этого нужно идти в observability инструменты. Если говорить про последнии версии проектов в spring'е, то был сделае переход на open telemetry. Далее вы можете взять Jaeger для анализа трейсов OTel и будут вам карты микросервисов как здесь описано www.aspecto.io/blog/jaeger-tracing-the-ultimate-guide/
Рустам, очень интересно про buildpacks с настройкой его для спринга, что там можно настроить, и можно ли настроить так, чтобы командой ./gradlew bootBuildImage запускало сборку в контейнере (независимо от окружения), и какие возможности настройки этого хозяйства есть. Искал в интернете, не особо чего нашел, в доке самого билдпакса, только как создавать свои билдеры, но как конфигурировать дефолтные и т.п. не видел...
Есть в доках Spring Boot раздел про maven и gradle плагины spring'а: docs.spring.io/spring-boot/gradle-plugin/packaging-oci-image.html и docs.spring.io/spring-boot/maven-plugin/build-image.html Там можно почитать про работу с buildpacks. Про packeto buildpacks для Java проектов можно почтить тут paketo.io/docs/howto/java/ В итоге есть очень много параметров для настройки.
Спасибо друг, очень во время! Надо было собрать jmix приложение в докер образ, но хост корпоративного докер-дева старый (18 убунта) и новый nodeJs для сборки туда просто не встает, но с билдером, да еще и со слоями, чутка модифицировал Dockerfile, чтобы JAVA_OPTS пробрасывать в ентрипоинт и всё получилось! Лайк и подписка🤗🤗
Спасибо за видео! Из доклада не очень понял, а какие в итоге преимущества по сравнению с использованием чистого Ваадина? На сайте jmix в качестве преимуществ тоже в основном перечисляют фичи Ваадина, и с бутом+секьюрити Ваадин уже дружит.
Скорость разработки. Jmix не равен Vaadin + Spring Boot. Потому что jmix очень многое реализует за разработчика. На jmix можно за одну минуту нашелкать таблицу в дизайнере моделей и уже сразу автоматический к ней можно сгенертровать UI со списком и всеми формами. И это меньше что можно делать. На оф сайте в доках и примерах можно почитать.
Команда Jmix подготовила специальный раздел документации docs.jmix.ru/jmix/concepts/index.html с разъяснениями концепции фреймворка, принципов и ключевых фичей. Посмотрите раздел - там ответы
Ну че то пример на реакте написан как будто намеренно плохо что бы показать какой он якобы не читаемый . особенно блок try/catch внутри flatmap, есть же адекватные инструменты у данного апи для этих манипуляций которые читаемы и лаконичны
просто для банквоского внутреннего приложения не нужна красота потому что это скорее рабочий инструмент. Да даже 1с предприятие к примеру его задача быть надежным инструментом а не быть красивым
@@qrthack читать книги и писать код. Курсы и прочее не советую. По java и go много хороших книг. Остальное - практика. Сейчас из-за перегретого рынка любой человек, который мало мальски что-то знает, будет замтен на интервью.
21:15, год-полтора спустя, JDK21 выкатил Loom, имеет вложенный паттерн-матчинг, рекорды используются во все концы, а Котлин отстаёт по фичам. Что и требовалось доказать. И да, для null-safety давно существуют бибилиотечные функциональные интерфейсы вроде Vavr.
Cахар это хорошо, но по сути, действительно, концептуально это ничего не решает. Корутины и в java есть, реактивные потоки, лямбды и тд. В чем плюсы котлина, я так и не понял, кроме того что компиляция происходит медленнее, и еще мне кажется что бОльшая свобода синтаксиса будет наталкивать на решения с "кривой" архитектурой , проще говоря будет больше говнокода, такое я видел в JS. А мне показалось, что котлин это вариант JS для JVM. И еще я заметил, что Антону было тяжко читать вопрос, где он сказал, что слишком много букв, это побочка от перехода на котлин с его сахаром?)
