Spring и Kotlin: работай с любым форматом!

Поговорим о том, как можно организовать десериализацию данных в Spring-приложении, когда вам приходится работать с различными форматами данных.

Обычно при разработке очередного технического сервиса для получения данных мы используем JSON как основной формат передачи данных. Это просто и работает из коробки: берем Java, с помощью Spring достаточно создать контроллеры, а Jackson в нем под капотом будет автоматически десериализовать входящие данные.

Но что делать, если ваша система должна работать не только с JSON, но и с другими форматами данных? Например, с YAML, XML, TOML, Protobuf или CBOR. В этом случае возникает множество вопросов. Нужно ли писать отдельную логику для каждого формата? Как справляться с различными интерфейсами и API серилизационных библиотек? Что делать с разнообразными аннотациями и как в одном классе описывать схему данных? А может, необходимо определять отдельные классы для разных сериализаторов, дублируя логику приложения?

Представьте, что вы работаете с платформой, которая должна принимать данные в различных форматах. Если для каждого формата писать отдельную логику десериализации, это приведет к сложному и запутанному коду. Кроме того, вам придется добавлять множество аннотаций от различных библиотек на целевые классы, что также усложняет поддержку кода. Здесь на помощь приходит Kotlin, а точнее — библиотека kotlinx.serialization. Она представляет собой компиляторный плагин и набор интерфейсов, имплементируя которые вы можете создать свою собственную библиотеку сериализации. Дополнительное весомое преимущество: она работает без рефлекшена и строит ветви процессинга данных уже на этапе компиляции.

На базе kotlinx.serialization уже создано более 5 встроенных форматов и поддержано более 20 форматов от комьюнити (один из них создал я), которые покроют большинство базовых сценариев и потребностей. Используя общие методы интерфейсов, вы сможете легко объединить логику сериализации / десериализации для различных форматов данных. При этом достаточно будет описать целевой класс со схемой всего один раз. А для вашего Spring-приложения на Kotlin kotlinx.serialization уже интегрирована как встроенный десериализатор по умолчанию в дополнение к Jackson. Это фактически становится стандартом в экосистеме Spring-Kotlin.

В докладе расскажу, как работает эта библиотека с точки зрения обычного пользователя. На реальном примере покажу, как ей пользоваться и что происходит у нее под капотом. Бонусом станет пример необычной проблемы, которую мы решали: десериализация данных, приходящих в один контроллер из разных форматов в единый формат GenericRecord без явного описания схемы класса в коде. Для этого будет использована Avro-схема, передаваемая на runtime, и знакомая всем, кто активно работает с Kafka.