Introduced usage of kotlin-kafka

[kfh]

• Swapped out the plain old Kafka client with kotlin-kafka
• Use Hoplite types directly
• Streamlined code (slimmed down and removed redundant code)

[OleksandrChmyrNAV]

Siden emottak-utils vil bli brukt i nesten alle tjenestene, foreslår jeg å prøve å utføre Kafka klient med så få avhengigheter som mulig, altså ved hjelp av kafka-clients.
Hvis vi feiler i det så kan vi legge til ekstra biblioteker.

[kfh]

Siden emottak-utils vil bli brukt i nesten alle tjenestene, foreslår jeg å prøve å utføre Kafka klient med så få avhengigheter som mulig, altså ved hjelp av kafka-clients. Hvis vi feiler i det så kan vi legge til ekstra biblioteker.

I utgangspunktet er det helt greit, men i dette tilfellet får vi slimmere og OG bedre kode ved å bruke denne tynne wrapperen over kafka-clients. Vi kommer uansett til å bruke dette biblioteket flere steder i kodebasene våre.

Målet vårt er jo ikke og ha så få avhengigheter som mulig, men høyest mulig kvalitet på koden.

[OleksandrChmyrNAV]

Målet vårt er jo ikke og ha så få avhengigheter som mulig, men høyest mulig kvalitet på koden.

Kodekvalitet avgjøres av flere faktorer deriblant gjenbrukbarhet og vedlikeholdbarhet.
Gjenbrukbarhet av emottak-utils er direkte knyttet til antall avhengigheter i den.
kotlin-kafka har også problemer med vedlikeholdbarhet siden den er vedlikeholdt med en person.
Jeg foreslår å diskutere denne problemstillingen på fokusmøtet.

[kfh]

Målet vårt er jo ikke og ha så få avhengigheter som mulig, men høyest mulig kvalitet på koden.

Kodekvalitet avgjøres av flere faktorer deriblant gjenbrukbarhet og vedlikeholdbarhet. Gjenbrukbarhet av emottak-utils er direkte knyttet til antall avhengigheter i den. kotlin-kafka har også problemer med vedlikeholdbarhet siden den er vedlikeholdt med en person. Jeg foreslår å diskutere denne problemstillingen på fokusmøtet.

Som sagt, et fint utgangspunkt og ikke ville bloate fellesbiblioteker, men dette bør derimot ikke være en blokker for å benytte oss av biblioteker som gir en betydelig merverdi. I dette tilfeller er det noen åpenbare argumenter slik jeg ser det:

1. kotlin-kafka gir oss coroutine-støtte rett ut av boksen slik at klientene av biblioteket slipper å tenke på det. Funksjonene er suspendable by default.

2. Biblioteket tar bort mye boiler-plate og gir oss enklere og tydeligere kode. Spesielt er dette nyttig rundt feilhåndtering da vi kan returnere et kotlin Result sånn at vi slipper og try / catche ute i klientene.

3. Strengt tatt innfører vi ikke en ekstra avhengighet, vi bytter ut en med en annen. kafka-clients er ikke lenger en direkte avhengighet men blir en transitiv avhengighet til kotlin-kafka.

kotlin-kafka er bare en tynn wrapper over kafka-clients og gir oss som nevnt noen åpenbare fordeler. Open source prosjekter har stort sett alltid et par ildsjeler som er viktige for å drive de fremover, jeg ser ikke dette som noen grunn til å være skeptisk. Hvis det ikke fungerer eller ikke blir vedlikeholdt er det en relativt smal sak å ta det bort evt bare downgrade til standard kafka-clients

[terjenilssen]

Synes egentlig at dette feltet burde hete eventTopic i og med at denne Kafka-klassen er tenkt gjenbrukt i alle moduler som benytter Kafka, og som da gjerne har andre topics i tillegg til topic for hendelser.

[ivanskodje]

Har vi Kafka-topics som ikke er events? 🤔 Hvis vi følger samme tankegang, burde vi da kanskje også bruke navn som eventGroupId, eventTruststoreType, osv.?

Tenker at det allerede er tydelig at en topic er Kafka-relatert, siden den ligger i dataklassen Kafka.

[terjenilssen]

Dette Kafka-configobjektet med bootstrapServers, securityProtocol osv, og topic ligger i emottak-utils fordi dette er felles config som er mer eller mindre statisk (det samme i alle moduler). Det som skiller seg ut, er hvilke topics den enkelte modul skal skrive til.

Det jeg mente, var at vi f.eks. i smtp-transport har et eget config-objekt KafkaTopics som inneholder payloadInTopic, signalInTopic, payloadOutTopic og signalOutTopic. Disse navnene er jo ganske tydelige på hva de er, mens Kafka.topic er utydelig på hvilken kø den er.

Tanken her er altså at Kafka sin topic er den ene felles-topic'en som vi har: Køen for hendelser (events). I allefall slik jeg har oppfattet det. Og da burde feltet også hete eventTopic.

[kfh]

Jeg merger denne nå så vi får koden ut. Jeg har tatt på meg å flytte hele repoet ut av ebxml-processor til eget repo. Mindre oppgaver som dette kan vi løfte over til nytt repo. Ser for meg litt andre endringer også siden det nå blir et helt selvsetendig repo.

[ivanskodje]

LGTM 👍

Det er alltid fint å redusere boilerplate kode!