Андрей Кулешов — Spring и Kotlin: работай с любым форматом!

Подробнее о Java-конференциях: — весной — JPoint: https://jrg.su/gTrwHx — осенью — Joker: https://jrg.su/h7yvG4 — — Скачать презентацию с сайта Joker — https://jrg.su/UxoSmo Поговорили о том, как можно организовать десериализацию данных в 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.