Separazione libreria condivisa tra microservizi in Java Spring Boot

[Giuseppe Coniglio]

Ciao :-)

ho il seguente quesito :  com'è possibile suddividere una libreria comune a più microservizi in modo tale che essi possano importarsi solo ciò che necessitano, evitando cosi di includere configurazioni e bean mai utilizzati?

Grazie :-D

[Marco Bartolini]

Ciao Giuseppe,

come al solito la risposta e' "dipende", non conosco la struttura/complessita' del tuo progetto, ma hai due opzioni a seconda di cosa ti conviene di più potresti:

• modularizzare la libreria comune e far consumare al tuo microservizio il modulo d'interesse, accettando il fatto che non avrai mai tutti i microservizi sulla stessa versione del modulo
• ridondare il codice in ogni microservizio, rompendo il concetto di DRY, ma rendendo ogni microservizio indipendente nel suo ciclo di sviluppo

se ti stai trovando con un libreria comune che contiene aspetti del tuo servizio diversi da cose come log/metrics/stats/etc dovresti riconsiderare cosa c'e' dentro la libreria comune, se hai un servizio o una serie di servizi usati da altri microservizi, probabilmente non e' una libreria comune, ma un servizio condiviso.  :) 

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "JUG Torino - JVM User Group Torino" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a jugtorino+...@googlegroups.com.
Per visualizzare questa discussione, visita https://groups.google.com/d/msgid/jugtorino/0d5a2a58-8f18-41fc-a1df-4a1c465a0f27n%40googlegroups.com.

[Matteo Vaccari]

In uno dei team che sto seguendo, abbiamo creato una dozzina di microlibrerie, proprio per fare in modo che ciascun microservizio si importi solo i pezzetti che gli servono.  Tanti piccoli repository, ognuno con la sua build.  Siamo facilitati perché in Gitlab è facile raggruppare i repo, mentre Github ha una struttura piatta

Per visualizzare questa discussione, visita https://groups.google.com/d/msgid/jugtorino/CAMYu_7PmGMMtCPDWP_%3DYqBgC%3D_0rh%3D_hsxD2AnUJhA3oi-gUMA%40mail.gmail.com.

[Giuseppe Coniglio]

Ciao Marco, si, hai ragione. 

E' più corretto definirlo come un servizio condiviso tra più microservizi che contiene funzioni e logiche comuni , il problema che sto riscontrando è che questa gestione, senza un particolare criterio, sta diventando un collo di bottiglia.

La mia idea iniziale era quella di sfruttare la gestione a moduli per farsì che i microservizi si possano portare solo la porzione di interesse, può essere funzionale?

Grazie ancora :-)

Il giorno ven 7 mar 2025 alle ore 15:23 Marco Bartolini <axle...@gmail.com> ha scritto:

[Marco Bartolini]

Ciao Giuseppe,

se accorpi troppe funzioni non correlate tra loro nello stesso servizio il collo di bottiglia si crea perche' stai rompendo un po' il concetto di single responsibility e ti stai avvicinando di piu' a un monolite distribuito per quanto generico esso sia.
Si modularizzare la libreria comune e la sua logica e' una delle possibili soluzioni come diceva anche Matteo, non conoscendo il tuo progetto non so nemmeno se vale di piu' la pena ridondare il codice, a volte produrre una libreria o una serie di librerie e distribuirle per stare dentro il DRY principle e' piu' oneroso che copiare qualche riga di codice che magari statisticamente non e' mai cambiata negli ultimi 5 anni e non cambiera' per i prossimi 5, ma questi sono ragionamenti che potete fare voi come team in base alla vostra esperienza/storia. Buona fortuna con la tua libreria condivisa! :)

[Giuseppe Coniglio]

uhmm si questo potrebbe essere un'alternativa 😊, un pó impegnativa ma va bene

Grazie