▍ Правило наименьших полномочий

Привет, Хабр! Меня зовут Александр Григоренко, я фронтенд-разработчик. В основном, занимаюсь разработкой приложений на React, но также постоянно экспериментирую с различными технологиями.

В своей работе я часто создаю собственные или использую уже готовые UI-компоненты. Проблема с такими компонентами заключается в том, что они часто ограничены определённым фреймворком, и их реализация требует написания сложной нестандартизированной логики. В течение долгого времени для базовых UI-компонентов, таких как диалоговые окна, использовались самописные решения, а в тяжёлых случаях и встроенные в JavaScript методы alert(), prompt() и confirm().

Отличная новость в том, что такой компонент можно реализовать с использованием нативного HTML-элемента <dialog>, который встроен в стандарт HTML5 и работает одинаково во всех современных браузерах.

Давайте познакомимся с возможностями <dialog> поближе.

Всем привет! В предыдущей статье я описал процесс аутентификации в Micronaut. Но аутентификация без авторизации мертва! Ну или крайне мало применима. Поэтому предлагаю заглянуть под кат и оценить различные механизмы авторизации в данном фреймворке, а заодно узнать, как это всё тестировать.

До недавнего времени мой опыт работы с бекенд-приложениями ограничивался созданием приложения на базе Spring Boot различных версий с использованием реляционных баз данных, ликвибейза, брокеров сообщений и т.д. Приложения в большинстве своем были легковесными, быстро запускались и не требовали большого количества ресурсов. Пока на работе мы с командой не столкнулись с проектом, который мало того, что запускался мучительно долго, так ещё и работал с большим количеством сервисов, постоянно то отдавая, то обрабатывая различные данные. Всё это, конечно же, приводило к медленной работе в продакшене, частым зависанием или вообще поломкой сервиса.

Это стало одной из причин интереса к GraalVm - виртуальной машине, написанной на Java, помогающая делать программы быстрее с помощью JIT компилятора. GraalVm помогает скомпилировать java код в так называемый native image. Это исполняемый файл приложения, который мгновенно запускается без старта JVM.

Эта статья - туториал, как подружить между собой Spring Boot, GraalVm, Liquibase и Docker, какие могут возникнуть подводные камни и как их можно обойти.

Привет! Меня зовут Михаил, я Java Backend Developer в Simbirsoft. В этой статье хочу поделиться своим опытом создания миграций файлов с большим списком данных при помощи Liquibase. Cтолкнувшись с такой задачей на проекте, я был сильно удивлен тому, как мало материалов написано по этой теме, даже на английском. Поэтому описал то, что удалось собрать и проверить на собственном опыте.

Привет! Меня зовут Васильев Виктор, я DBA в компании UIS и CoMagic. В этой статье на реальных примерах расскажу, как можно сэкономить время разработчика, администратора баз данных и ресурсы сервера(ов), используя утилиту pg_rebuild_table. Сопровождая большие, высоконагруженные системы, с бо’льшей вероятностью каждый сталкивался с кейсами, о которых будет рассказано дальше. Некоторые технические подробности пройду без детализации, чтобы сильно не усложнять и не делать статью очень громоздкой. Лучше отвечу на вопросы в комментариях.

Привет! Когда-то обновление версии сервиса было сложной задачей. Нужно было последовательно выполнить ряд действий, перезапустить инстансы, и не забыть предварительно забэкапить наши данные. Пользователям сервиса показывалось предупреждение, что сервис временно недоступен, и куча усилий тратилась на то, чтобы максимально снизить время этой недоступности.

Сейчас же у нас есть супер-мощные инструменты для управления сервисами. Они позволяют иметь несколько разных версий сервиса одновременно. Бизнес-пользователи могут управлять тем, какую версию видит та или иная группа пользователей. Обновление и откат версии сервиса могут происходить без прерывания работы пользователей. И когда появился такой мощный и красивый молоток, все начали хотеть забивать гвозди только им. Даже те, кому это, на самом-то деле, вообще не нужно. И тут есть проблема - наличие инструмента не означает автоматической готовности сервисов для того, чтобы этот инструмент с ними можно было использовать. И если обновлять сервисы старым способом было сложно, то новым это делать еще сложнее. Давайте посмотрим, почему это так, и как вообще получить этот ваш Zero Downtime.

Хорошо бы понимать различия между HTTP/1.1 и HTTP/2, поскольку gRPC использует HTTP/2 по умолчанию.

Характеристики HTTP/1.1:

- Текстовый формат
- Заголовки в текстовом формате
- TCP-соединение требует «трехстороннего рукопожатия» (three-way handshake) — один запрос и ответ с одним единственным TCP-соединением.

Характеристики HTTP/2:

- Бинарный формат
- Сжатие заголовков
- Управление потоком
- Мультиплексирование (одно и то же TCP-соединение может быть повторно использовано для мультиплексирования. Потоковая передача с сервера — потоковая передача от клиента — возможна двунаправленная потоковая передача)

Одной из наиболее важных проблем при создании распределенных приложений является вопрос представления данных. Мы должны убедиться, что данные, отправленные компонентом «удаленному» компоненту (т. е. компоненту, который является частью другого процесса), будут получены правильно с теми же значениями. 

Это может показаться простым, но помните, что взаимодействующие компоненты могут быть написаны на совершенно разных языках. Ситуация усложняется еще больше, если учесть, что разные аппаратные/системные архитектуры, скорее всего, имеют различные способы представления «одинаковых» значений. Простого копирования байтов из одного компонента в другой недостаточно. Даже в Java, где мы можем считать себя «защищенными» от такого рода ситуаций, нет требования, чтобы две разные реализации JVM или разные версии от одного производителя использовали одно и то же внутреннее представление для объектов.

Наиболее распространенным решением этой проблемы является определение «канонического» представления данных, которое будет понятно между процессами — даже между языками программирования — и перевод данных в этот формат перед отправкой, а затем обратно в собственный формат получателя после получения. 

Существует несколько таких «форматов передачи», начиная от текстовых стандартов, таких как YAML, JSON или XML, до бинарных вариантов, таких как Protobuf, которые включают метаданные или являются полностью неструктурированными.

В компании Chronicle Software разработан ряд библиотек для поддержки создания приложений, оптимизированных для обмена сообщениями с низкой задержкой, в основном в сфере финансовых услуг. 

Apache Kafka де-факто превратился в стандарт потоковой передачи событий для обработки данных на лету. По мере его широкого распространения в отрасли появляются вопросы: «А когда НЕ нужно использовать Apache Kafka? Какие ограничения у этой платформы? В каких ситуациях он не предлагает необходимые возможности? Как понять, что Kafka — неподходящий инструмент для какой-то задачи?»

В статье, перевод которой мы подготовили, автор Kai Waehner постарается ответить на эти вопросы. В отдельных главах приводится объяснение, когда стоит использовать Kafka, когда — нет, а когда — возможно.

CRaC (Coordinated Restore at Checkpoint) — это проект OpenJDK, разработанный Azul для решения проблемы «медленного» запуска виртуальной машины Java в микросервисной среде.

Когда JVM запускает код вашего приложения, она выполняет такие действия, как интерпретация, компиляция и оптимизация кода, чтобы ваше приложение работало как можно быстрее при заданной рабочей нагрузке. Это здорово, но может занять некоторое время, и особенно при запуске короткоживущих микросервисов, вы не хотите ждать, пока JVM создаст наиболее оптимизированный код.

В механизме восстановления контрольной точки (checkpoint-restore) нет ничего нового, и большинство из вас уже знают и используют его ежедневно. 

Если вы работаете на ноутбуке и закрываете крышку, операционная система обнаруживает это и сохраняет текущее состояние на диск. Как только вы снова открываете крышку, операционная система восстанавливает сохраненное состояние с диска.
CRaC предоставляет тот же механизм, но для JVM и вашего запущенного приложения.

Вы запускаете свое приложение, применяете к нему некоторую рабочую нагрузку (чтобы убедиться, что важные части вашего кода будут затронуты и оптимизированы JVM), а затем создаете контрольную точку. Это приведет к закрытию всех открытых ресурсов, таких как открытые файлы и сокетные соединения, а затем сохранит состояние JVM, включая ваше приложение, на диск.

После этого вы сможете восстанавливать состояние JVM, включая состояние вашего приложения, из этой сохраненной контрольной точки так часто, как вам захочется.

Таким образом, CRaC не только решает проблему времени запуска, но и может решить проблему времени разогрева приложения, поскольку вы можете создавать контрольную точку в любое время.

Микрофронтенд-архитектура - это подход к созданию приложений, в котором каждая часть приложения, отвечающая за определенную функциональность, представлена отдельным фронтенд-приложением. Такой подход позволяет достичь более высокой гибкости и масштабируемости приложения, так как каждый микрофронтенд может быть разработан и развернут независимо от остальных.

Как правило, микрофронтенды используются в комбинации с микросервисной архитектурой, в которой приложение состоит из набора независимых микросервисов, каждый из которых выполняет свою функцию. Микрофронтенды позволяют разработчикам разрабатывать интерфейсы для каждого микросервиса отдельно и объединять их в единое приложение, что облегчает поддержку, масштабирование и развертывание приложения.

Одним из ключевых преимуществ микрофронтендов является возможность быстрой разработки и доставки изменений пользовательского интерфейса без необходимости изменения всего приложения. Кроме того, микрофронтенды могут помочь упростить процесс разработки, улучшить переиспользуемость кода и уменьшить зависимость между различными частями фронтенд-приложения.

Полезная ссылка с подробным объяснением концепции микрофронтенда.

В этой статье вы прочитаете о лучших практиках запуска Java-приложений в Kubernetes. Большинство из этих рекомендаций будут справедливы и для других языков. 

Однако я рассматриваю все правила в рамках характеристик Java, а также показываю решения и инструменты, доступные для приложений на базе JVM. 

Некоторые из этих рекомендаций по Kubernetes навязаны дизайном при использовании самых популярных Java-фреймворков, таких, как Spring Boot или Quarkus. Я покажу вам, как эффективно использовать их для упрощения жизни разработчиков.

Unicode – это набор символов, целью которого является определение всех символов и глифов всех человеческих языков, живых и мертвых. Поскольку всё больше и больше программ должны поддерживать несколько языков или просто любой язык, юникод в последние годы приобретает всё большую популярность. Использование различных наборов символов для разных языков может быть слишком обременительным для программистов и пользователей.

К сожалению, юникод привносит свои требования и подводные камни, когда речь заходит о регулярных выражениях. Но в дополнение к сложностям, он также приносит и новые возможности.

❯ Когда взаимодействуют разработчики и операторы

С одной стороны, GraphQL схема однозначно определяет модель данных и доступные операции реализующего ее сервиса. С другой, Kotlin предоставляет потрясающие возможности для создания предметно-ориентированных языков (DSL). Таким образом, возможно написать предметно-ориентированный язык для взаимодействия с GraphQL сервисом в соответствии с опубликованной схемой. Но, написание такого кода вручную, это сизифов труд. Лучше его просто генерировать. И в этом нам поможет плагин Kobby. Он анализирует GraphQL схему и генерирует клиентский DSL.

Статей о работе с PostgreSQL и её преимуществах достаточно много, но не всегда из них понятно, как следить за состоянием базы и метриками, влияющими на её оптимальную работу. В статье подробно рассмотрим SQL-запросы, которые помогут вам отслеживать эти показатели и просто могут быть полезны как пользователю.