const api = {
  url: "/v1",
  timeout: 5000
};

type User = {
  id: string;
  role: "admin";
};

async function
  fetch(url) {}

SELECT name
FROM users;

$ git push
✓ deployed

@Module({})
class App {}

const [state, setState]
  = useState(null);

FROM node:20
WORKDIR /app
CMD ["npm", "start"]

def main():
    print("Hello")
    return True

query {
  user(id: 1) {
    name
  }
}

fn main() {
    let x = 42;
    println!("{}", x);
}

.container {
  display: grid;
  gap: 1rem;
}

func handler(w http.
  ResponseWriter) {}

{
  "name": "app",
  "version": "1.0"
}

#!/bin/bash
npm run build
echo "Done ✓"

interface Props {
  children: ReactNode;
  onClick?: () => void;
}

apiVersion: v1
kind: Service
metadata:
  name: api

struct App: View {
  var body: some View
}

</>{ }=>||[ ]::// todo!=&&

✦

✡

→

∞

↔

Caricamento...

Torna al blog

Architettura

10 Dic 2024•8 min di lettura

Architettura microservizi: quando ha senso?

Un'analisi obiettiva su quando i microservizi sono la scelta giusta e quando invece un monolite ben strutturato è preferibile.

Il mito dei microservizi

I microservizi sono diventati il "santo graal" dell'architettura software. Ma la realtà è più sfumata di quanto l'hype suggerisca.

Quando i microservizi hanno senso

1. Team grandi e indipendenti

Se hai più team che devono lavorare in parallelo senza pestarsi i piedi, i microservizi possono aiutare. Ogni team può deployare indipendentemente.

2. Scaling selettivo

Quando solo alcune parti del sistema richiedono scaling aggressivo, i microservizi permettono di scalare solo ciò che serve.

3. Tecnologie diverse

Se parti del sistema beneficiano di tecnologie diverse (es. ML in Python, API in Node.js), i microservizi offrono questa flessibilità.

Quando il monolite vince

1. Startup e MVP

Per validare un'idea, un monolite ben strutturato ti permette di muoverti velocemente. Potrai sempre estrarre microservizi dopo.

2. Team piccoli

Con meno di 5-6 sviluppatori, l'overhead dei microservizi raramente si giustifica.

3. Domini accoppiati

Se le funzionalità sono fortemente correlate, separarle in microservizi crea solo complessità artificiale.

Il compromesso: modular monolith

La mia raccomandazione? Inizia con un monolite modulare. Struttura il codice come se fossero microservizi, ma deployali insieme. Quando e se sarà necessario, la separazione sarà naturale.

Conclusione

Non seguire l'hype. Scegli l'architettura che risolve i tuoi problemi reali, non quelli che potresti avere in un futuro ipotetico.

#backend#javascript#performance#best-practices

Condividi questo articolo:

PrecedenteIl futuro del backend: da Node.js a Bun, cosa cambia davvero?

SuccessivoTypeScript: pattern avanzati per backend robusti

Ti è piaciuto questo articolo?

Iscriviti alla newsletter per ricevere nuovi contenuti direttamente nella tua inbox.

Torna al blog

Architettura

10 Dic 2024•8 min di lettura

Architettura microservizi: quando ha senso?

Un'analisi obiettiva su quando i microservizi sono la scelta giusta e quando invece un monolite ben strutturato è preferibile.

Il mito dei microservizi

I microservizi sono diventati il "santo graal" dell'architettura software. Ma la realtà è più sfumata di quanto l'hype suggerisca.

Quando i microservizi hanno senso

1. Team grandi e indipendenti

Se hai più team che devono lavorare in parallelo senza pestarsi i piedi, i microservizi possono aiutare. Ogni team può deployare indipendentemente.

2. Scaling selettivo

Quando solo alcune parti del sistema richiedono scaling aggressivo, i microservizi permettono di scalare solo ciò che serve.

3. Tecnologie diverse

Se parti del sistema beneficiano di tecnologie diverse (es. ML in Python, API in Node.js), i microservizi offrono questa flessibilità.

Quando il monolite vince

1. Startup e MVP

Per validare un'idea, un monolite ben strutturato ti permette di muoverti velocemente. Potrai sempre estrarre microservizi dopo.

2. Team piccoli

Con meno di 5-6 sviluppatori, l'overhead dei microservizi raramente si giustifica.

3. Domini accoppiati

Se le funzionalità sono fortemente correlate, separarle in microservizi crea solo complessità artificiale.

Il compromesso: modular monolith

La mia raccomandazione? Inizia con un monolite modulare. Struttura il codice come se fossero microservizi, ma deployali insieme. Quando e se sarà necessario, la separazione sarà naturale.

Conclusione

Non seguire l'hype. Scegli l'architettura che risolve i tuoi problemi reali, non quelli che potresti avere in un futuro ipotetico.

#backend#javascript#performance#best-practices

Condividi questo articolo:

PrecedenteIl futuro del backend: da Node.js a Bun, cosa cambia davvero?

SuccessivoTypeScript: pattern avanzati per backend robusti

Ti è piaciuto questo articolo?

Iscriviti alla newsletter per ricevere nuovi contenuti direttamente nella tua inbox.

Luca Frattini | Software Developer

Architettura microservizi: quando ha senso?

Il mito dei microservizi

Quando i microservizi hanno senso

1. Team grandi e indipendenti

2. Scaling selettivo

3. Tecnologie diverse

Quando il monolite vince

1. Startup e MVP

2. Team piccoli

3. Domini accoppiati

Il compromesso: modular monolith

Conclusione

Articoli correlati

Clean architecture: applicarla senza sovra-ingegnerizzare

Il futuro del backend: da Node.js a Bun, cosa cambia davvero?

Ti è piaciuto questo articolo?

Architettura microservizi: quando ha senso?

Il mito dei microservizi

Quando i microservizi hanno senso

1. Team grandi e indipendenti

2. Scaling selettivo

3. Tecnologie diverse

Quando il monolite vince

1. Startup e MVP

2. Team piccoli

3. Domini accoppiati

Il compromesso: modular monolith

Conclusione

Articoli correlati

Clean architecture: applicarla senza sovra-ingegnerizzare

Il futuro del backend: da Node.js a Bun, cosa cambia davvero?

Ti è piaciuto questo articolo?