Jag har testat ut det lite grann. För små projekt så är det väldigt mycket overkill. Om du har ett större projekt, så är det helt klart intressant.

Men hva om du har et lite prosjekt som kan bli til et stort? Kanskje det lønner seg å bruke tidlig? 😅

Jeg tror du bør splitte ut i microservicer og få det deploya i et k8s cluster fortest mulig.

Fra spøk til alvor. Jeg tror jeg liker tankegangen bak polylith, men jeg er ikke sikker på om jeg liker implementasjonen av ideene.

Jeg synes det er fint med interfacer, men det er vanskelig å designe gode interfacer, polylith eller ei. Å kunne lage ulike artifakter fra samme kodebase? meh. Vi deployer backenden vår på et par ulike måter, via ulike main-funksjoner eller flagg eller noe, men genererer ikke opp ulike artifakter av den grun.

I det første teamet mitt i Nav hadde vi et monorepo med 10+ apper, og som også inneholdt et par commons-biblioteker. Det er vel i den typen scenario polylith er nyttig tenker jeg. Det kan jo diskuteres om vi trengte et monorepo i utgangspunktet; støtte på problemer med oppgradering av avhengigheter fordi vi brukte Spring (😫), og én av de 10 appene brukte et obskurt bibliotek som ikke var kompatibelt med nyeste versjon. Dermed kunne ikke resten av appene i monorepoet oppgraderes heller uten en del merarbeid for å løskoble monorepoet mer.

Der jeg jobber på har vi ~300 mikrotjenester som bygger på en haug typer og interfaces fra et "rammeverk" vi har laget. Det gjør ganske vondt til tider å forstå hva som egentlig foregår under parykken. Riktignok C# .NET, ikke Clojure.

Data er det beste interfacet. Design ting for å være datadrevet og vær sparsom og forsiktig med objekter og funksjoner og systemer for å lage biblioteker/rammeverk med dem. IMO, som det heter.

Du kan ”override” vilken version som ska användas för varje bibliotek, per projekt/artifakt i Polylith, så att man inte blir låst till vad ens komponenter använder.