C’est simplement un moyen d’organiser une grosse codebase clojure en de multiples projets déployables indépendamment, dans un monorepo. je prévois un blog post pour expliquer ce que ça nous a apporté plus concrètement.

La documentation du tool clojure est excellente pour bien comprendre https://github.com/polyfy/polylith

Bé justement, je trouve pas que la documentation de Polylith soit excellente pour justifier d'utiliser ça plutôt que tools.deps + des protocoles + quelques conventions d'organisation du code. Si ton blog post peut aborder cette question ça m'intéresse.

Notamment, la façon qu'a Polylith de définir des interfaces (via des fichiers qui définissent les mêmes Vars, comme C avec ses header files) me semble très douteuse comparé à l'utilisation de protocoles, qui est le mécanisme de polymorphisme par défaut en Clojure.

Pour moi ce n’est pas la même chose, tu vas découper ton code en des isolations logiques, plus ou mois grosses, les “components”, mais je vois plutôt ces components comme des librairies que tu utilises dans tes projets, par exemple tu aurais un component “store”, un “aws”, un “parser”, etc... qui peuvent s’utiliser mutuellement d’ailleurs, d’où l’image des legos. Le parallèle tient bien car dans une librairie tu ne vas exposer qu’une partie de ton code, la partie publique, tu n’exposes pas les détails d’implémentation => c’est ce que tu vas mettre dans le fichier interface.clj de chaque component, et la CLI Polylith va lever une erreur si tu require du code d’un component qui n’est pas dans l’interface. On utilise les protocoles dans notre code par exemple, à l’intérieur des components, peut-être que tu faisais référence à une partie de la doc où ils parlaient de comment switcher d’un composant à un autre en production ou en développement, mais j’ai l’impression que cette partie n’y est plus, et c’est tant mieux car c’était effectivement un peu confus.

l’avantage par rapport à le gérer soi-même avec deps.edn, c’est simplement que c’est ce que fait Polylith, c’est documenté, et je trouve ça bien fait 🙂 si tu as déjà quelque chose qui marche bien il n’y a pas forcément d’intérêt en effet, il y a quand même un gros plus c’est la détection do code qui a été modifié, polylith est capable de te dire les components et les projets qui sont impactés par tes changements de code, c’est un gros win pour optimiser le run des tests, la CI, et déclencher uniquement les déploiements nécessaires

La série de blogs de sean corfield ou il explique justement leur transition d’une gestion custom à Polylith est intéressante à lire, il était sceptique au début : https://corfield.org/blog/2021/04/21/deps-edn-monorepo-2/ (et les suivants)

@U0CL38MU1 merci pour l'explication. > je vois plutôt ces components comme des librairies que tu utilises dans tes projets, par exemple tu aurais un component “store”, un “aws”, un “parser”, etc... qui peuvent s’utiliser mutuellement d’ailleurs, d’où l’image des legos. Le parallèle tient bien car dans une librairie tu ne vas exposer qu’une partie de ton code, la partie publique, tu n’exposes pas les détails d’implémentation J'ai peut-être rien compris, mais je ne suis pas du tout convaincu 🙂 l'utilisation que tu décris me semble être le cas d'usage parfait pour des protocoles. À mes yeux le rôle d'une librairie n'est pas spécialement de cacher une implémentation derrière une interface, mais juste de rendre du code disponible - c'est une préoccupation orthogonale. Mais bref, n'en parlons pas plus ici - ce serait sans doute plus intéressant de lancer un débat sur ClojureVerse, comme ça d'autres personnes pourront participer ou en profiter.

yep, pour le coup je ne comprends pas pourquoi tu parles de protocole, Polylith ne propose pas une solution d’extensibilité du code, mais de découpage, il faudrait que tu testes sur un petit projet concret peut-être pour que ce soit plus clair.

et peut-être que ce n’était pas clair : Polylith n’a pas vraiment d’intérêt si tu n’as pas besoin de plusieurs déploiements différents (“projects”: par exemple une lambda aws, une api, un consumer de queue, une cli, ...) avec un packaging de certaines parties du code seulement (“components”) dedans

un exemple de projet : https://github.com/furkan3ayraktar/clojure-polylith-realworld-example-app

Oui, on utilise clojure pour tout le backend et clojurescript pour le front