Backend Driven UI (BDUI) — это подход, при котором сервер управляет не только данными приложения, но и формирует интерфейсы, включая экраны, верстку, реакции на действия пользователя и переходы между экранами. Клиентская часть сводится к рендерингу интерфейсов на основе полученных с сервера данных.

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

На бумаге такие идеи кажутся идеальными, иногда даже «серебряной пулей». Однако на практике всё не так однозначно, и многое зависит от конкретного кейса. В этой статье я поделюсь опытом нашей компании, расскажу о нюансах, которые позволили нам извлечь пользу из BDUI, и представлю рабочий инструмент. Мы использовали нестандартные подходы, которые, надеюсь, вдохновят вас. Похоже, что для нас BDUI — это скорее удовольствие, чем боль. Давайте разберёмся, как нам это удалось!

Понедельник. Постановка задачи

Expression Problem (EP) — это классическая задача в программировании на совмещение несовместимого.

Автор задачи (Philip Wadler) формулирует следующие цели: создать такую абстракцию, что позволяла бы расширять иерархию в двух направлениях: добавлять новые классы и добавлять новые методы для обработки иерархии, сохраняя при этом строгую статическую типизацию и не требуя изменений существующего кода.

В динамически типизируемых языках мы бы могли добавить или переопределить метод на лету с помощью трюка, ставшего известным под неказистым названием monkey patching (хоть первоначально речь шла совсем не про обезьян, а про партизан — guerrilla).

А вот какие трюки применяют в статически типизированных языках рассмотрим под катом.

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

В статье разберем особенности аутентификации применительно к протоколу WebSocket и технологии Server-Sent Events, обсудим, какие нюансы могут быть, когда клиентская часть находится в браузере, и на что еще стоит обратить внимание, чтобы избежать неочевидных проблем.

А еще заодно поговорим про уязвимость Cross-Site WebSocket Hijacking (CSWSH) и в целом посмотрим на многие вопросы через призму информационной безопасности.

Да вымереть не могут.

Откуда это всё пошло? Чем так условные «программисты» не угодили? И почему именно программисты?

В инкубаторе JEP-429 появилась новая альтернатива ThreadLocal под названием ScopedValue (в значительной степени как поддержка и развитие Virtual Threads). ScopedValue предназначен для того, чтобы предоставить более легкую альтернативу ThreadLocal, которая хорошо работает с виртуальными потоками, а также решает многочисленные недостатки, присущие API своего аналога двадцатипятилетней давности. В этой статье мы рассмотрим основные отличия ScopedValue, и за счет чего он может работать быстрее.

java.util.concurrent.CompletableFuture - класс не новый. Он предстал перед нами во всём своём величии в 2014-м году вместе с выпуском Java 8. Много лет с тех пор прошло, а проще он не стал.

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

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

В статье попробуем разобраться действительно ли роль архитектора незаменима, для чего она нужна, как возникла и работает в реальном мире?

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

В этой статье мы рассмотрим, как реализовать гексагональную архитектуру в Spring Boot приложении. Мы разделим бизнес-логику и инфраструктуру на отдельные модули и посмотрим, как можно изолированно реализовать и протестировать эти модули.

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

Я уже написал здесь много статей на тему прокси-протоколов и прокси-клиентов, которые очень сложно детектировать и заблокировать, и которые используют пользователи в Китае, Иране, Ираке, Туркменистане, и теперь вот в России (мы здесь в отличной компании, правда?). Но довольно часто мне в комментариях писали, мол, это все отлично, но мне нужен именно VPN для целей именно VPN - доступа в частные локальные сети, либо для соединения клиентов между собой, и желательно так, чтобы его не заблокировали обезьяны с гранатой. Поэтому сегодня мы поговорим именно о VPN.

Классические OpenVPN, Wireguard и IPSec отметаем сразу - их уже давно умеют блокировать и блокировали не раз. Модифицированный Wireguard от проекта Amnezia под названием AmneziaWG — отличная задумка, но есть одно но...

Добиться, чтобы приложение в равной степени могло управляться пользователями, программами, автоматизированными тестовыми или пакетными сценариями, а также разрабатываться и тестироваться в изоляции от устройств и баз данных, на которых оно впоследствии будет выполняться. — Алистер Кокберн, 2005 г.

В одном из своих предыдущих постов под названием "Эйлер, Чёрч и Мандельброт — этюд о красоте и математике" я немного затронул тему рассмотрения функционального программирования в качестве основы реальности. Под тем постом было оставлено множество интересных комментариев, один из которых, написанный @nickolaym, вдохновил меня на развитие мысли в данном направлении. Так появился этот пост, в котором прямо как во времена пифагорейской школы и платоновской академии философия переплелась с математикой, а математика с философией.

На собеседованиях на позицию middle/senior разработчика часто задают вопросы по распределенным транзакциям в микросервисной архитектуре.

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

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

Перед тем как начать, делюсь ссылкой на мой блог в телеграм, где я раньше всего публикую материалы по java разработке и личной эффективности.

В книге Криса Ричардсона «Микросервисы: паттерны разработки и рефакторинга», описывается что-то около 20 паттернов, использующихся в микросервисной архитектуре. Все они делятся на 5 больших групп: decomposition patterns, integration patterns, database patterns, observability patterns и cross-cutting concern patterns. Я, узнав про паттерны, которые могут быть применимы в микросервисной архитектуре, немного изучила их и попробовала реализовать один из них. Всем привет, меня зовут Екатерина Попкова, я Java/Kotlin-разработчик в Альфа-Банке, и хочу рассказать, как можно обеспечить консистентность данных в микросервисной архитектуре с помощью применения паттерна «Сага».

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

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

Поскольку наверняка не мы первые столкнулись с такой проблемой, то решили изучить существующие способы решения этой задачи.

У некоторых в команде уже был опыт работы с xa-транзакциями.
Довольно удобный способ, когда у вас есть несколько ACID СУБД. Процесс состоит из двух фаз.

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

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

Хотя это не история в чистом виде, а скорее ход размышлений во время работы над проектом - дальнейший рассказ раскроет наши метания на пути к цели. Запасайтесь попкорном!

В некотором царстве, в некотором государстве жил был царь. Как-то раз объявил царь всему народу - "Кто решит три моих задачки, тот сам сможет царём стать". И даже контракт метода опубликовал, всё честь по чести.

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