Ja, Nubank valgte Clojure pga Datomic

Det at datomic integrerer så godt og er så nært er en av de store fordelene. Native Clojure datatyper rett inn, ingen serialisering. Dataene kommer rett ut igjen fra en lazy collection. Helt nydelig.

Jeg har prøvd meg på datomic både fra Java og nodejs i tidligere prosjekter, og da forsvinner dette helt - og mye av magien faller bort.

Jeg delte nyheten om Datomic på jobb. Første feedback fra en seniorutvikler: > Datomic is indeed a cool database, but I would actually prefer to embrace eventsourcing. Just using eventsourcing would give you all the benefits you list. Another benefit is that you would make the events first class in your domain, resulting in a better understanding in what actually drives change of data rather that simple crud. There is a specialized db called eventstore, https://www.eventstore.com/, for eventsourcing that is pretty sweet, but you can also use https://martendb.io/ in .net which runs on top of postgres.

Datomic gir deg event sourcing med en relasjonell modell i én og samme pakke

Transaksjoner er førsteklasses data som kan annoteres - dette er eventene dine. Det er selvfølgelig en noe forenklet tilnærming, men den sparer deg for sykt mye kompleksitet, og gir deg de aller fleste fordelene.

@slipset snakket om at en grunn til å unngå Daromic, er at det er et krav å hardt skille på data på tvers av tenants i Ardoq. I postgres kan du skille på data på db/schema-nivå, easy peasy. Men @magnars, gjorde ikke dere noe sindige greier på Norled for at brukere bare skulle få se data de faktisk har tilgang til, hvor dere filtrerte på et eller annet generisk vis etter queries? Something something filtrering av facts?

Det er kanskje vanskeligere å selge inn Datomic i en bedrift som er all-in på Microsoft og C# .NET når en av de store vinningene er den sømløse "integrasjonen" og hele brukeropplevelsen i et språk med matchende "filosofi."

Ja, jeg tror du må ta med Clojure på kjøpet for å få glede av det

En mulig vinkling er jo å bygge en liten mikrotjeneste rundt datomic som øvrige tjenester kan kalle på. Når man så ser hvor flott det blir kan man bytte ut de andre i tur og orden 😅

Ja, jeg tror det blir planen. Hovedutfordringen er at vi har et relativt tynt men komplekst "rammeverk" for mikrotjenester som "vi" (egentlig en ekstern konsulent) har laget. Alle mikrotjenester "må" i utgangspunktet benytte det fordi det gjør registrering av tjenesten, kommunikasjon med andre tjenester (via Service Bus), secrets, databaser, autentisering, logging, etc. Jeg jobber på teamet som er ansvarlig for dette rammeverket og "core" tjenester (dvs. de som ikke får hente inn andre tjenester). En ulempe er at det er relativt restriktivt og man kan ikke bruke hele .NET helt fritt heller. Fordelen er at det er ganske raskt og enkelt å lage nye tjenester og forstå alle tjenestene fordi konseptet og strukturen er likt. Så lenge man bruker denne "malen" er alt "lett" i den forstand at man kun trenger å tenke på business logic og ikke alt "rundt." Vi har ca. 300 mikrotjenester som bygger på- og kommuniserer med hverandre gjennom dette rammeverket. For å lage en mikrotjeneste i Clojure må jeg antagelig enten porte hele eller deler av rammeverket vårt eller bruke det via ClojureCLR på en eller annen kreativ måte. Eller skite i hele greia og lage en helt frittstående tjeneste, men da gjør jeg meg selv svært upopulær 😅

hehe

Nest siste episode i dag 🙂 https://www.zombieclj.no/s02e50.html

altså, jeg synes livet ble hyggeligere, ikke kjipere, av å lage en liten sak med Groovy (!) som skrev alle bevegelser i togtrafikken til en datomic-base så vi kunne se “hvordan så egentlig tog-norge ut i natt 02:00 når vi sendte en melding vi ikke forstod helt hvorfor”

Det er nok fine måter å bruke det på også fra andre språk altså, ikke la meg svartmale helt!

Det som er positivt med rammeverket vårt for mikrotjenester, er at det er svært modulært. Det er bygget på konseptene "hexagonal architecture" og "CQRS," med frittstående "komponenter" som kan konsumeres enkeltvis via separate NuGet pakker. Fordi det er ikke alle mikrotjenestene vi bygger som behøver alle delene av rammeverket. Alt som har med databaser å gjøre er generalisert, slik at en kan velge forskjellige typer databaser relativt enkelt. Dermed er det betydelig enklere å bytte ut en del av rammeverket av gangen, eller "plugge inn" Datomic under den delen av rammeverket som styrer med databaser. Så det kan hende det finnes noen muligheter der også. Rammeverket er egentlig ganske godt bygget.

Så det kunne kanskje vært en idé å lage en C# .NET klient for Datomic, og legge til støtte for det i den delen av rammeverket som gjør databasegreier. Når Datomic er på plass, tror jeg det ville vært betydelig enklere å selge inn Clojure ved å vise det i sammenheng med Datomic på egne datasett.

Hvis du bygger et klientbibliotek som tar seg av mappingen mellom Clojure sine datatyper og noe som er ergonomisk på .NET så er mye gjort tror jeg

Da vi brukte Datomic fra Java så var det særlig her det smertet. Litt ironisk, for det er jo langt mer elegant enn “strenger” som i praksis er utvekslingsformatet du har med en tradisjonell database - men der har du klientbiblioteker som integrerer språkets datastrukturer mot databasen.

hvis man liker CQRS er forøvrig Datomic et bra innsalg. Jeg vet ikke om en database som gjør tydeligere CQR enn Datomic, egentlig 😄 Datomic sine trade-offs gjør at så godt som alt er helt ulikt mellom commands og queries

enig med Christian, hadde vært rått om det var enkelt å jobbe med Datomic fra andre språk, og at protokollen ikke var så Clojure-spesifikk ned til beinet. Typ at du må lage Clojure-symboler (`clojure.lang.Symbol.create("db", "add")` for å få det som tilsvarer :db/add) fra Java-kode for å lage queries som data. Rart med det egentlig, virker som Cognitect/Nubank ikke er spesielt interesserte i at Datomic skal “ta av”

er en stor dose “hva vet jeg” her da, kanskje det er kjempe upraktisk å få til det uten å samtidig gjøre det vanskeligere å bruke Datomic fra Clojure

.NET har for øvrig også https://learn.microsoft.com/en-us/ef/, som er en slags ORM. Det virker ganske komplekst, og ikke som en spesielt god idé egentlig. Men det er relativt utbredt, og jeg tror det er mulig å extende Entity Framework til å supportere andre typer databaser og query-språk, som f.eks. Datomic og Datalog. Men jeg vet ikke om det er en spesielt smart tilnærming.

Det er lett å abstrahere seg bort fra det som gjør Datomic bra hvis man ikke har inngående kjennskap til det. Jeg ramlet i den fella når jeg (som flink gutt) lagde storage-laget for http://www.adventur.no med en "pluggbar arkitektur" slik at man "lett" skulle kunne bytte ut databasen. Det hadde jeg jo lært at var viktig.

God morgen fra borti her.

Kjenner at jeg brygger på en blog post: “Loose coupling considered harmful” 🙂