Welcome to avro4k Discussions! #144
Replies: 2 comments 1 reply
-
Thanks for opening the discussion board. I just started using the avro4k lib and personally believe that sharing thoughts and ideas in an open discussion will help me to better understand your intentions and concepts for this lib, apply them to my expectations and needs and thus provide better Feature requests and provide sollutions. Let me start by introducing myself: I am Jan, close to 50y old and I work as an IT Consultant for Holisticon in Hamburg, Germany. My clients are mostly middle and large companies and my projects deal with custom enterprise solutions, focussed on logistics, supply change management and finance. My main tools are camunda (process automation platform) and axon (framework and server for event driven and event sourced microservices). My interest in avro started when I began working with event sourcing, because it could provide a compact, concise and schema proof (thus backward compatible) solution for storing business domain events in event sourced systems. So a couple of years ago, I started researching how avro could be supported, resulting in an axon serializer project and some supporting libs. I investigated avro4k back then, but the missing support for single object encoding made me back off and focus on the "standard" java tooling apache avro provides out of the box. We have now been using avro event serialization for over a year in my current customers project and really enjoy defining messages and events in avro json schemas (using the avsc (and avpr) defaults). What we do not enjoy are the generated, bloated SpecificRecordBase classes as they are hard to read and just don't feel right when interacting with our kotlin code base. I started working on a code generator that can create immutable kotlin data classes from schema specifications and reconsidered avro4k, as you have the required encodings and java interoperability solved already, and it seems (see #142) single object encoding was not that big of a blocker anyway. So I am willing to move forward with avro4k and kotlin data classes and maybe even refactor our existing code base to replace the java SpecificRecords. But: this would require me to go "all in" with the code generator, as we share only the schema definitions between services, not versioned message jars. And as I won't be able to start fresh, I would have to keep interoperability between our so far stored json events based on java and the avro4k data classes. To achieve this, we started our new pet project, the avro4k-generator (currently a private repo in my organization, but I would be happy to invite you to investigate it and discuss with you, as you have much more and longer experience working with avro and kotlin). Ok, sorry for this rather long initial post, I will try to keep my current questions and remarks shorter (and will open dedicated threads for them to keep focus). Anyway: Great library, thanks for building and maintaining this! Jan |
Beta Was this translation helpful? Give feedback.
-
It should also be great to do avro encoding/decoding natively, to not rely on a library at most, or at least use only field serializers to have better performance by not passing through the GenericRecord (that leads to lot of maps created) |
Beta Was this translation helpful? Give feedback.
-
👋 Welcome!
We’re using Discussions as a place to connect with other members of our community. We hope that you:
build together 💪.
Beta Was this translation helpful? Give feedback.
All reactions